Project management methodologies, and Agile’s poisonous effect on them
Table of Contents
· Introduction
· Scrum
∘ Pitfall 1: Intimidating or unpleasant stand-ups
∘ Pitfall 2: “All scrum members are equal, but some scrum members are more equal than others”
∘ Pitfall 3: Taking the term ‘sprint’ to heart
∘ Pitfall 4: Mutable sprints
∘ Pitfall 5: The illusion of ‘self-managing teams’
· Conclusions
Introduction
This article is to try and give my views on some popular project management methodologies, and to explain their unpleasant relationship with Agile. This article can therefore be seen as a follow up to my previous article explaining why Agile is a terrible concept.
Unlike Agile and its manifesto, which I argue is almost always implemented a manner that doesn’t promote good software development, project management methodologies such as Scrum and Kanban are fine in themselves and can be very effective. It’s generally only the influence of Agile that gives them any downsides.
Scrum and Kanban, while often associated with Agile teams, don’t have anything to do with Agile: you can use them in any industry, irrespective of whether you practice “Agile” or not. They don’t work with traditional Waterfall, as both require relatively small project sizes (i.e. being able to split projects into smaller ones, for example Scrum sprints need to be reasonably short), but they work with pretty much anything else.
In order to explain why this is, let’s go into them a bit: but first, it’s important to note that unlike Agile, Scrum and Kanban don’t dictate priorities via a manifesto. This makes a huge difference, because it changes how they are interpreted and used.
For the purposes of this article, we’ll just look at Scrum, as many of the same potential pitfalls apply to both. I may expand it later if I have time.
Scrum
Scrum is a framework for managing teamwork, which generally involves daily stand-up meetings (brief meetings, often in the morning), sprints and sprint planning (planning out the next few weeks of work), and other things. It often involves a scrum master responsible for managing how Scrum is done for the team.
Frankly, it’s a very good idea when implemented well (and I believe it often is). It’s an efficient framework for making sure members of a team communicate well with each other, ensuring everybody knows the status of each project on the team, and also does a lot to help foster a more communal, friendly atmosphere in teams. Sprints are designed to be quite short, so that they do not become unmanageably big or difficult to analyse in retrospective meetings at the end of a sprint.
That said, there’s definitely a lot of unnecessary crap regarding Scrum, such as this:
However, Scrum does not have quite the same religious following that Agile does, at least not in the same way — and its priorities and principles don’t have anything like the harmful things that Agile does. I am not using this image to imply that Scrum is bad, because it isn’t, but simply to highlight some bad points.
Almost all of Scrum’s potential weaknesses — if they exist in a particular team — are caused not by Scrum itself, but caused or directly encouraged by priorities that Agile encourages. What are these potential weaknesses?
Scrum Pitfalls
Pitfall 1: Intimidating or unpleasant stand-ups
A lot of us have been there: stand-ups where you feel much less like a team member, and more like a subordinate reporting yesterday’s results and hoping not to be smited by a bolt of lightning, because commercial pressure is high and time is of the essence.
Scrum itself is not to blame for this. The idea of stand-ups has always been for short, informal meetings that are for information’s sake — not as something to be measured, or a reporting session in which progress must be satisfactory. If team members feel they must report satisfactory ‘results’ in a standup, they won’t speak their mind as they should, leading to communication failure.
This problem comes from bad Scrum management — which in turn often, but not always, comes from Agile. A manager who believes in Agile principles of ‘customer collaboration over contract negotiation’ and ‘working software over comprehensive documentation’ — when the commercial reality chips are down — is more likely to put higher pressure on their devs in meetings, to achieve deadlines that turned out to be too short than a manager who doesn’t follow Agile in that way. It’s this rush to please customers at any cost that leads to unpleasant stand-ups of this nature, as devs feel pressured to report results rather than give an objective overview of current status.
Given that stand-ups in Scrum generally occur every day, are frequently the first thing of the day, and can take anything from 30 minutes to an hour and a half a week of each member’s time, bad standups have a gigantic negative impact on the experience of working in a company. As such this is easily the most impactful and most problematic pitfall to fall into.
Pitfall 2: “All scrum members are equal, but some scrum members are more equal than others”
One of the primary ideas of any meeting where you want people to be honest, and not be afraid to speak out, is the concept of the round table: where, for the duration of the meeting, everybody is on equal terms.
This is generally how daily stand-ups are done: after all, the point of the scrum meeting is to facilitate communication about the state of projects, not report on it.
This can fail if scrum meetings — for a variety of reasons — fall victim to having some members be of “higher status” in the meeting than others. This can be caused by a few things:
- Authority bleeding over into the meeting (e.g. a senior dev, while still technically equal in the meeting, seems to get preferential treatment from the scrum master or others, allowing them to speak above or silence others, even unintentionally).
- A bad Scrum Master. While there is nothing wrong with the concept of the Scrum Master, said person must be careful not to prioritise any member of the team or give undue favour to anyone in the meeting, or they risk creating an unequal meeting. In addition, the Scrum Master has to be careful not to accidentally be too authoritative and give such status to themselves to avoid the same problem.
- Overly informal standups. While standups are supposed to be informal, if it becomes a kind of “morning chat” between senior devs where others are left out — even if this is intended as a friendly, positive thing, it can have negative effects on junior members of a team or those who are less social, who may feel less like talking. It should be informal, yes, but there’s still a level of process to be followed.
This particular pitfall is not Agile’s fault, nor Scrum’s fault; it’s just a management issue in and of itself that isn’t specific to any methodology.
Pitfall 3: Taking the term ‘sprint’ to heart
One slight problem with the word ‘sprint’ for scrum planning is that while it is intended to mean “short” — i.e. the sprint should not cover too long a length of time to prevent scope creep and difficulty of retrospective meetings — it can be taken too literally.
It is my belief that most who practice Scrum genuinely take sprints to just mean short periods, and not anything else. However, in some Agile environments it becomes exactly what it says: sprinting the entire time to finish the sprint.
This is far less to do with Scrum and more to do with Agile’s putting customer satisfaction over any other considerations. Believing in “working software over comprehensive documentation” tends to result in a short-term mindset of getting the current sprint done, whatever the cost, and cleaning up later if need be. Unfortunately… there is always a new sprint. The time you hope will exist for fixing problems later will never exist, because lo and behold, your customers will have new requests. This same problem also leads to overcrowding sprints with too many projects, making it impossible for anything other than coerced ‘voluntary’ dev overtime to finish it.
It is, of course, possible for this to happen without Agile; it’s just more likely with Agile, given the priorities it sets out.
Pitfall 4: Mutable sprints
One of Scrum’s core concepts is that the work contained within a sprint generally shouldn’t change mid-way through the sprint — once it’s been decided, it should stay that way. Anything else that crops up in the meantime should wait for the next sprint cycle. While there is of course some discretion with this, the concept is to avoid changing sprint mid-cycle as much as possible.
Unfortunately, Agile — or an incompetent or malicious manager — can frequently cause sprints to change halfway through, in order to please customers who suddenly turn up with last minute requests or other situations. This can’t be said to be solely caused by Agile, but it directly encourages it; Agile principles are in contradiction to sprints, as sprints which don’t change after starting require you not to be flexible with the customer beyond a point.
That isn’t simply ‘poorly-implemented Agile’. Agile directly encourages mid-sprint changes; that’s what customer collaboration and responding to change are often interpreted to mean, when it means the difference between pleasing the customer and not pleasing them.
Pitfall 5: The illusion of ‘self-managing teams’
It should not take a genius to figure out that self-managing teams, in a nutshell, do not exist unless you own the company. That’s not to say that teams cannot run without some higher authority giving them instructions every ten minutes, but rather that the idea of a team with no leading authority figure is an illusion at best and a malicious lie at worst.
Scrum teams can, in theory, be leaderless. This rarely actually happens in practice, because it’s very hard to separate scrum roles from company roles: the most senior person or persons in the team become and act as the de facto leaders, that there is no de jure leader makes no difference whatsoever.
Even in teams that genuinely do ‘self-manage’, they are still accountable to higher management. This leaves them in a position where pressure from higher management forces their hand, and this pressure frequently comes from Agile ideas of putting pleasing customers above formal contract negotiation for changes and ‘responding to change’, to quote the Manifesto itself.
Conclusions
The primary point of this article is to state that Scrum and Kanban, among other management methodologies, are fine. It is the influence of Agile that tends to damage them.
The solution I propose is simple: get rid of the Agile Manifesto and ‘Agile’ as a concept. We don’t need Agile to split projects into small pieces; aside from the Manifesto, that’s literally all it is.
