Agile Adoption Trends

By Mike Bailey

As I sit here ruminating on the Agile adoption trends I have noticed a pattern. I think that in the traditional bell curve of adoption that Agile is somewhere near the top. It is not completely clear if we are just before the top or just after.

With this trend I have also noticed some concerning traits of large company adoption. As a large company moves from waterfall to agile in major mode, they often carry forward some or a lot of their waterfall metrics into the agile process. Let me explain what I mean by that.

Take a company that has traditionally had a 12 to 18 month development cycle which often resulted in a 15 to 24 month delivery cycle with waterfall. This company will have built a lot of sales forecasting and metrics around this development cycle. The sales team and the executives will predict the next year of revenue based on the promise of delivery in 12 to 18 months. They will need to know if the development team is on track for delivery as they will have had delays regularly and need to ensure the customer that this time it is different. To get this information there has been a lot of metrics built into the process. The full design is completed up front, then there is the development and then an attempt to bolt on quality at the end.

Now take this same organization as they move to Agile. The sales team will not know when to expect the new software as the normal Agile process gives a range of dates and does not have a full design up front. To provide the sales team the comfort level of knowing when something will be done a release plan is done up front which has most of the Agile stories estimated so that you can predict when the project will be done. The one advantage of Agile is that with frequent iterations, the sales team, and others, will know quicker that you are off track. As with any project of 12 plus months it is nearly impossible to estimate an accurate end date.

In addition to the requirement to have the stories estimated up front there are additional metrics built in so that project management can track more accurately the progress of the team. These additional metrics are often added work for the team which will cause them to spend time updating metrics and less time developing. This also has an impact to the team in that they may feel they are not trusted.

Why is there such a focus on 12 months? Companies do annual (12 month) financial planning. Part of that is often an estimation of new revenue based on the promise of new sales of software that has not yet been developed. Would it make more sense to have the financial planning based more on what exists now and less on what we hope to deliver?

I have read where a few companies that have gone to a full ROWE model and sales is based on what exists and not on what is being promised. If there is incremental new sales based on something delivered during the year, it will likely be only a small incremental and set the base for more accurate predictions for the following year of planning.

Back to the initial topic, I think that Agile is near the top and the true value is being reduced by the addition of metrics and an annual mindset. There are companies going to a ROWE model and other models which can use more traditional Agile or other variations for development. I watched a presentation by Fred George at the 0redev conference about ‘programmer anarchy’ which I see as a reaction to a metrics burdened Agile process.

As software development cycles change I think we are seeing several new models that are in their early stages and will soon begin to grow in replacing Agile at least for some early adopters.

Mike Bailey is a Product Manager at CA Technologies.

Article source:


Powered by Facebook Comments

Leave a Reply

Your email address will not be published. Required fields are marked *