What’s Your “Size” of Agile?
I spoke with a potential client the other day. He said, “I want all the teams to use Scrum, and I want it yesterday!”
Okay. I asked him, “Are the teams all collocated and cross-functional, with all the capabilities and roles they need to finish work?”
“Almost all of them.”
I asked, “Do the teams work on one project at a time, or do they have interruptions with support needs from other releases?”
“Almost all of them.”
I suggested that Scrum might not be right for his organization, but that working in a cadence and asking teams to see their flow might be better. We had a lovely discussion about why that was, and he is rethinking his approach of mandating one kind of agile for all his teams.
There Is No One-Size-Fits-All Agile
Some teams use iterations and love them. They love planning in advance for a couple of weeks, they love the rituals (especially if they use Scrum), and they love the predictability of when they will do what.
Other people and teams use flow. They love seeing what’s where on a more detailed board. They want to manage their work in progress (WIP) and to see their bottlenecks. They want to be able to react faster to interruptions.
Some people like flow inside iterations, or to use a cadence of planning and retrospectives for their work as well as seeing their flow and WIP.
When people and teams choose their form of agility (and yes, not every workgroup is a team, so people might need their own forms, too), they are often more successful.
Avoid Pigeonholing People and Teams
This well-meaning manager wanted to pigeonhole everyone into an approach that sounds terrific when you read about it. But when I asked more questions about his teams, I discovered they often had people more than four time zones apart.
Can you have meetings with people that far apart? Of course, but why make things difficult? Why not either create the environment that works better for each team or create an approach that works better for each team?
Create Your Successful Agile Approach
Instead of standardizing on any form of agile, think about the results you want. Maybe there are specific measures you want each team or person to report on. Standardize that. Don’t think there is just one way to do agile.
One of the things I love about agile is the idea that we incorporate continuous improvement as we deliver value. That means we’re constantly reflecting, changing, and experimenting with our agile approach. That’s a great thing.
The next time someone tells you to standardize on the “one right way” to do agile, ask them if they want continual improvement. I bet they say yes. That’s your entry to decide on your kind of agile.
