Being one of the people that participated in the creation of the Agile Manifesto, I find myself very disappointed by the reaction of engineers to the question “Are you practicing Agile?” Their shoulders drop. They start to slowly shake their heads. They mumble; they grumble. They tell me agile is horrible. I ask why. Reasons I head most often are:
- We’re being micromanaged
- The pressure is constantly on, these two-week delivery are too short
- All they care about is the date
- We only have time for cr**py code, we can’t do it right!
None of those management behaviors are part of Agile (read the Agile Manifesto and its related principles for yourself). Unfortunately, the dysfunction the authors of the Agile Manifesto were rebelling against are alive and well today in most places that claim to be Agile.
How do we find ourselves here? An all too common starting starting point is one of mistrust (note they above), where things are not going so well. Someone hears about agile and deliveries every two weeks. Sounds pretty good to a manager that is used to long lead times, delays, and defects. Someone is sent to two days of Scrum Master training to get the sprints started. Managers are updated everyday at the daily meeting; engineers no doubt get the idea they are micromanaged, and that they are the Scrum slaves.
I dig a little deeper, to understand “why do you feel micromanaged?” They say “We have to update the boss every morning instead of once a week.” “There is continuous pressure in these two week sprints!” “No time to document or to think”
GET UP, Time for another Sprint
Why is there so much pressure in the two week iterations? I don’t use the ‘S’ (sprint) word. It is a completely wrong metaphor. In sports, sprints don’t happen back to back. Sprinting leads to exhaustion. Sure there will be times when we sprint, but those sprints happen in the context of a marathon where you won’t finish if you do not have a sustainable pace.
Engineers tell me “The stories we are assigned are so huge there is no way to get the work done with any quality. We have to rush everything. The Product Owner says it’s priority one. We have to do what the PO says, right? No documentation; no thought; just do it! That’s Agile! Right?”
No, that’s not Agile; thought I agree that is a demoralizing way to work. As one manager told me when In the early days of coaching and training Extreme Programming “This all sounds great, but instead of being beat up once every six months now I get beat up every two weeks!” (His VP was definitely not quite on board with the realities and values of Agile, yet.) We had some more coaching to do it seems.
Too many supposedly Agile shops are missing a lot. They are not even doing plain old Scrum. If they were, programmers would be better off, for example by:
- Self-organizing teams manage themselves
- Choosing your work lets you follow your interest (sometime you have to take less desirable work)
- Committing to how much can be done in an iteration
- Updating each other in the stand up. (It’s not a manager update, though they participate.)
- Talking responsibility for design and other technical decisions (being professionals)
- Facilitate continuous improvement by doing meaningful retrospectives (being honest with yourself)
The motions of Scrum can help, but they are not enough. With Scrum, you change the cadence of delivery. Have you changed how you engineer your products? The practices of Extreme Programming are designed to help skilled engineers create software with a long useful life.
Managers, Scrum Master, POs does your engineering team use the technical practices of Extreme Programming to deliver high quality working software every iteration? Do you give them the resources and time to learn the skills they need to be successful in Agile?
Now it sounds like I am one of those anti-management types. I’m not. I spent a decade in management and leadership in a fortune 500 company. I know a bit about the job and can relate to the problems and pressures. The problem is not all in management.
Engineers, programmers, developers! We need to build trust. When we ask for three months to deliver, what happens after 2.5 months? We give the bad news that we’ll need an extra month. Bad news late is the worst kind of bad news. Your trust takes a hit. Then it happens again as you near the new deadline. Your reputation is weakened further. It looks like you are really busy now! You claim to be done and then the bugs start rolling in. You fix the bugs and unknowingly break previously working features your customer relies on. Your trust and reputation is in the trash.
Can we get out of this mess? If you got good at delivering meaningful valuable progress every iteration, delivering features that continue to work rather than randomly break as new changes are made, you can build a trusting relationship. Management will applaud you.
How do we do that? We’ve been trying to do that all along.
With Agile, the delivery cycle fundamentally changed. Have you changed how you develop software? As a senior developer, are you programming the same way you did that first year out of school? Do you have 10 years experience, repeating the cycle of code, test and fix that is too common in our industry? Have you read any books on iterative development, Test-Driven Development, Extreme Programming, or Design? Have you read any books on development at all? Are those crickets I am hearing? (you are reading this article, so probably you said yes).
The cadence of delivery is changed, so must your practices change. Kent Beck told me long ago (paraphrasing): “You’ll never be able to figure it all out up-front. You’ll never be able to stop changes even with a signed requirements document and contract defined penalties. Things will change. That’s the world. If you can’t beat ’em, join ’em. Get good at dealing with change.”
As it turns out, Agile as practiced is dominated with management in 2016. Most the people that were involved with the Agile Manifesto were programmers, doing what they could to make the world better for programmers and the people that need programs.
Programmers, you have a professional responsibility to improve how you work. We (programmers) better get our act together; we’re just a few more software caused problems away from having the lawyers and government in our business. We better learn to be professional, or some lawyer or government bureaucrat will tell us what professional is. Agile might not be the whole answer, but it does advance the state of the art. It introduces the two week cycle and we can and should use that cycle for continuous improvement. Serious technical improvement, not lip service.
Managers, Scrum masters, and POs do you encourage your team to learn the technical practices of Agile? Do you even know what they are and why they are important? Here are two key areas you cannot afford to ignore if you want your team be more successful and make your customers happier:
These are only a start. But they are foundational.
That is up to you.
This article is based on my answer to a Quora question: In a nutshell, why do a lot of developers dislike Agile?