So many folks want to flip a switch and magically become agile. They want all the benefits without any of the hard work that comes along with really transforming the organization. People think that just because they read a book... or took a few days of training... that they can expect instant productivity. They don't realize that agile methods only show you your problems... it is still up to you to fix them.
I'll often see this thinking manifest in questions like "how many iterations until I can expect my team's velocity to start going up". There is so much underneath a question like that, it's hard to give a solid answer. Is there a prioritized product backlog? Is there a product owner grooming the backlog and available to the team? Is the team cross-functional? Are they dedicated to the project? Do they have everything they need to be successful? Are there external dependencies?
All those things matter... and right out of the gate.. you are not quite sure the kind of impact those answers will have on the team's ability to deliver.
My recommendation is generally to look at team performance in three phases. The first goal is to measure what is... to establish a performance baseline. Next start thinking about getting stable... stable performance is key to running a predictable agile project. Once you are stable... now you can start thinking about getting faster. Adopting agile is a learning process and you can't improve a system when you don't understand what is broken.
And that is really the key... it isn't about getting a better velocity. It's about fixing the broken parts of your organization. It's about looking at where you are and comparing it against where you would really like to be. It's about understanding the impediments standing in your way and dealing with them in a meaningful way... in a way that really, truly helps the team get better. It's about getting more efficient at creating value and really improving the processes that allow value to be created.
Those kinds of answers don't translate into a great marketing pitch. How long will it take to get agile? I don't know... how many iterations will it take to remove the organizational impediments that are slowing the team down? How many iterations will it take until you are willing to fix what is really broken? How many iterations until we are ready to stop applying labels and start REALLY transforming the organization?
Subscribe to Leading Agile
I totally agree with you... BUT...
ReplyDeleteI've always approached the "how many iterations" question with the following answer:
"6-12 iterations or 6 months, whichever is longer, but ONLY IF you have a dedicated/experienced coach. Otherwise, you can't predict it up front."
Why? Because I have confidence that MOST of the time this will be true... it will give the coach enough time to work through the issues you list. And, if they can't, it will be obvious long before you get to the end of the predicted time.
It's normally enough to get their interest and pursue the details of the conversation that you list above. Going your route (listing the issues and not answering) can leave people with a vague, "he doesn't have confidence in this" feeling and potentially undermine the confidence in the transformation pitch.
You described several requirements for success that are external to the team. Prioritized and groomed backlog, competent product owner available,external dependencies. I hope you will write more about these in you upcoming book.
ReplyDeleteKevin,
ReplyDeleteI have also heard people say three iterations. I almost jokingly said that it is always three... but my sense of humor wasn't working early this morning when I did the post.
I think that the 'ifs' you list can get worked out faster, it doesn't have to take 6-12.
Mike
Dean,
ReplyDeleteI've already written about many of them here... and I expect they will be in the book too. If I wasn't so lazy or had more time... I should dig up some links. Maybe we can chat at Pjs sometime or another.
Mike
Mike
ReplyDeleteThere's a way athletes train; try for control, repeat fast, go for control, repeat fast...
What do you reckon?
Craig... not much of an athlete myself... but control does need to come before speed. When I was teaching my boys to lift weights I emphasized form over pounds. Lifting a lot only counts if you do it with good form and don't get hurt in the process!
ReplyDeleteMike
Mike - Great post, and over the last 2 months I've been mentoring a series of Distributed Teams with the approach of stability first, then speed.
ReplyDeleteI find that focusing on the basics and being disciplined is laying the groundwork to increase our velocity.
Everyone wants to go faster, but if we press on the gas without good agile fundamentals in place it will not end well.
-David
I think you really sum up the issues in the statement you made:
ReplyDelete"it isn't about getting a better velocity. It's about fixing the broken parts of your organization. It's about looking at where you are and comparing it against where you would really like to be. It's about understanding the impediments standing in your way and dealing with them in a meaningful way... in a way that really, truly helps the team get better. It's about getting more efficient at creating value and really improving the processes that allow value to be created."
Agile adoption begins with a mental shift in the organization from the top down. See my blog post at: http://peterdeyoe.wordpress.com/2009/09/04/3/