Why are you Failing with Agile?

Okay... you're a few months into your agile roll-out. You did all the right stuff before you got started. Got sign-off from the execs... check... got team members trained... check... identified a pilot project... check... hired an agile coach... check. Why then... after all this time, effort, and money... are we still struggling with the fundamentals? Why can't we seem to get over the hump?

It seems that there is always someone... sometimes there are a lot of someones... that just don't seem to get it. They just can't let go of their trusted MRD... they can't seem to get past the idea that agile teams don't do Gantt charts. These folks want to know exactly when their project is going to be done... what it is going to cost... and what they are going to get for their money.

How do we respond to these people? Hey... agile can't be any worse that what we are doing now? Agile is all about trust... you just need to trust that this new way of doing things is better. Just give us a few sprints and we'll prove to you that this new way works. I promise, you'll like it.

Put yourself in that other person's shoes for a moment... your Product Manager was promoted and given big fat raises based on the insight and detailed analysis she put in those MR docs. The VP of Engineering got where he is today by making sure systems were designed fully up front. The Director of the PMO has built his entire career around applying the processes found in the PMBOK...not to mention the bonus he got for becoming a PMP in the first place.

These folks know something is broken... they know that we are making product development too hard...that is whey they let the team give this agile stuff a try in the first place. The problem is that... at the end of day... these folks are on the hook for making sure the organization delivers. When they are under pressure they fall back to what they know. They dance with the girl they came with.

It's important when we introduce something new that we spend some time figuring out what the people around us need to be successful. These folks have families... they have kids in college... they have financial obligations. You are not just asking them to change... you are asking them to put their livelihood at risk. People don't resist change because they are bad people or because they just don't get it. Chances are... at some level... they are afraid.

More than likely... there is some fundamental concern that you have not addressed. Until you understand what your detractors need to be successful... and work to satisfy that need... on their terms... they are going to continue to stand in your way. They will continue to hold you back and resist the changes you are trying to implement. If you had so much to lose... you'd probably do the same thing.

Trust me doesn't cut it until you have earned that trust. Agile will help you get there... but you know what... you might have to let them have their Gantt chart... you might have to let them have their MRD... until you can make it safe for them to let it go.

Comments

[Craig Fitzpatrick]

I would love to see more talk in the Agile community about answering those tough questions like "How much is this going to cost me?" and "When will it be done?".

I think Agile has a lot of merit but until it can have credible answers to some of those questions, it won't become main stream. Those questions and answers are too important to businesses.

I think Agile's biggest weakness right now is a community of people trying avoid those tough questions by poking fun at people that want (need) those answers. If doing a bunch of planning up front in order to try and estimate time & cost isn't the right answer, fine, but I have yet to see a better way to answer those tough questions come out of the Agile community yet.

Suggesting the executives are silly for wanting those questions answered demonstrates a lack of understanding of the very real needs of businesses that fund these projects. It's just naive.

I'm not picking on Agile, just that it would be stronger and more popular if the community could figure out how to answer those questions instead of shluffing them off as unimportant or unanswerable.

Thoughts?

[Mike Cottmeyer]

It is an interesting challenge and both sides have to take some responsibility. On the one hand... agilists should recognize that business leaders need these answers. On the other... business leaders need to realize that much of what they are asking for can't be answered and what they get is total fiction.

At the end of the day agile is calling for a greater partnership between IT and the business. We are all in this together and demanding certainty in an uncertain world is expensive and can lead to failure.

Thanks for your comment!

[Tony]

The problem is that tech development cycles are often misunderstood by levels higher than tech management.

Heres an analogy, if I ask a plumber to do work on my house. I am only interested in the cost of the repair and the time it will done. How the plumber does his/her thing is of no real interest to me. My experience is that the business world thinks like this when it comes to tech development