Do most programmers hate Scrum?
Note: the original title of this post was “Do most programmers hate Agile?” but actually the problems discussed here are about applying Scrum blindly. And, of course, Agile ≠ Scrum.
Agile disciplines are usually sold as the modern and innovative way for developing software. Companies and recruiters are actively using the word “agile” in their job descriptions to attract developers, using this term in contrast to “waterfall” or other more or less heavily structured processes.
If this is true, why the Web is so surprisingly full of articles about programmers hating agile? A quick search on Google shows pages and pages about this topic: we should suspect there is something real behind it, but what is that?
The problem
In my experience, the term “Agile”, as soon as it became widespread, was hijacked by Ceremony Professionals. These are people (and organizations) once thriving with traditional project management techniques.
For instance, some “well-known, big system integrators”, which are by now famous more for printing paper than working software, who embraced Agile not because they have grown a productive experience with it, but just because it’s fashionable and maybe some customers started asking questions about it. Suddenly, not knowing even a bit about this stuff was perceived as shameful.
Walking on this buzzword-oriented minefield, many implementations of self-proclaimed “agile development process” simply has become one of the most blatant case of putting lipstick on a pig our industry has ever experienced. Hundreds of project managers without any actual field experience with agile implementations, rushed to recycle themselves as “agile coaches”.
But let’s go back on the main topic: why so many developers seems to be not at ease with Agile, or at least with some parts of it?
Managing knowledge workers
In reality, what it’s happening in a lot of organizations embracing Agile is that they are instead creating an additional layer of micro-management on top of regular development activities. This poor-man version of the process is exactly what skilled developers refuse.
Just nail this sentence down in you mind: smart people don’t like to be micro-managed, they hate it with soul and hart.
In my opinion, the principal responsible for these negative feelings is uncritical Scrum adoption. Scrum was succinctly defined by The Scrum Alliance in the below paragraph.
The Scrum framework in 30 seconds
- A product owner creates a prioritized wish list called a product backlog.
- During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.
- The team has a certain amount of time — a sprint (usually two to four weeks) — to complete its work, but it meets each day to assess its progress (daily Scrum).
- Along the way, the ScrumMaster keeps the team focused on its goal.
- At the end of the sprint, the work should be potentially shippable: ready to hand to a customer, put on a store shelf, or show to a stakeholder.
- The sprint ends with a sprint review and retrospective.
- As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.
Nothing wrong with the above definitions: simple and clear, those are the good parts.
Unfortunately, many Scrum implementations tend to be too much focused on standup meetings because if a Scrum Master doesn’t have enough understanding of the technical and business objectives, he or she naturally focus on just managing people: it seems to give more control.
This management style transforms standup meetings, a ten minutes morning meeting which should have the main target of letting communication flow, to micro-management sessions where each individual behavior is passed under x-ray in the open. No wonder developers quickly become pissed-off and defensive. No wonder that more sensitive people, like junior developers and a majority of women could feel this kind of public trial too intrusive.
How can it be fixed?
First of all, if some part of any standardized process creates more harm than good, it must be promptly removed. For example, no need for standup meetings if they are perceived as a waste of time or too intrusive from developers. Even if something can be useful, a good manager should prioritize on people feelings instead of blindly following the book, because people are not gears than you can spin at your own wishes. Experiment and gather feedback instead: there are plenty of alternatives for improving communication, and trivial one to one chats are usually much more effective when dealing with introvert people.
Second: Agile development should be handled by people with real experience on the field, so invest on good coaches with a demonstrable record of successful implementations, not on last-minute survivors desperately looking for a career change. Yes, real experts can be (initially) more expensive, like anything of value.
Third, but perhaps the most important point: shift the team’s focus from isolated technical tasks toward the continuous delivery of integrated business services. Work should be focused around delivering business value and Agile iterations are a very good methodology for that. Each time-boxed sprint must be focused on delivering a verifiable working set of business functionalities, so it is necessary to create teams around that and let them self-organize and work solutions out of it: don’t fall in love with the process, love the results.
In conclusion
Software development is a very complex human activity dealing with a lot of hard thinking. Because, you know, Taylorism doesn’t mix well with knowledge workers.
People should be accountable for the development of working software delivering real business value, so during a standup a perfectly acceptable answer to the classical standup question “What will you do today?” could be “I’m thinking”.
For these reasons, maybe you don’t really need boring, daily meetings but you should constantly define and communicate what is measurable business value for your organization and adapt accordingly.
