So, your team has been practicing Agile for a while, but it's not making a whole lot of difference.
Excessive planning sucks up weeks of time before the work even starts. Releases still take forever to accomplish, and you are not delivering value to the customer but once every few months. Iterations don't stay inside their time box but straggle all over the place. Has anything really changed?
Maybe not. Because maybe you are using Fake Agile.
In the big and overlapping world of The Agiles and their ilk, teams can adopt and fine tune a combination methods—team roles from Scrum, user stories from Lean, project boards from Kanban, pair programming from Extreme.
But that does not mean you can borrow one or two techniques and call yourself Agile. You absolutely need to put in place the following:
Excessive planning sucks up weeks of time before the work even starts. Releases still take forever to accomplish, and you are not delivering value to the customer but once every few months. Iterations don't stay inside their time box but straggle all over the place. Has anything really changed?
Maybe not. Because maybe you are using Fake Agile.
In the big and overlapping world of The Agiles and their ilk, teams can adopt and fine tune a combination methods—team roles from Scrum, user stories from Lean, project boards from Kanban, pair programming from Extreme.
But that does not mean you can borrow one or two techniques and call yourself Agile. You absolutely need to put in place the following:
- An iterative process in which the customer is an integral part of the team. Base changes and enhancements on customer feedback. Then do it again. And again.
- A team environment in which information is shared regularly and readily, cooperation and collaboration are the norm, and work is transparent. This must take precedence over feeding precious time and energy into extensive planning processes and the unwieldy tools thereof. In fact, do away with the latter altogether.
- A process in which releases delivering business value happen early and often. Stop messing around with long-range plans and milestones and start providing your customers with working software. Or magazine issues. Or new websites. Or bicycles. Whatever your team's raison d'être is, it is not creating milestones. This is important. Repeat after me: A milestone is not a product.
- Enough discipline and backbone to stick with the Agile process. When politics and whims threaten your team's velocity, when somebody asks you to start writing lengthy weekly progress reports, when a team member turns cowboy, be strong. Push back.
So, if Agile isn't working for you, ask yourself if what you are really practicing is AgileBut.
"We're practicing Agile, but no, we don't really have anybody in the Product Owner role."
"We're using Agile, but we're still putting a lot of time into planning documents and progress reports."
"We're practicing Agile, but management frequently pulls us off onto other projects in the middle of iterations."
"We're doing Agile, but we actually haven't gotten around to changing our coding practices."
"We're an Agile team, but some of us work outside iterations or skip ahead to future iteration work when we get bored."
"We're doing Agile. In combination with Waterfall."
You get the idea.
"We're practicing Agile, but no, we don't really have anybody in the Product Owner role."
"We're using Agile, but we're still putting a lot of time into planning documents and progress reports."
"We're practicing Agile, but management frequently pulls us off onto other projects in the middle of iterations."
"We're doing Agile, but we actually haven't gotten around to changing our coding practices."
"We're an Agile team, but some of us work outside iterations or skip ahead to future iteration work when we get bored."
"We're doing Agile. In combination with Waterfall."
You get the idea.