Still running waterfall projects or development initiatives and need the push to go agile? Contemplating agile but you need some easy to explain reasons to go to your senior management with in order to get them to say “yes” to the conversion? Don't mention completing projects on budget because the whole concept with even estimating development costs on an agile project is a tricky one – we will cover that in another discussion soon. Right now I want to help those project or dev leaders through the negotiation process of getting agile in your organization.
Try going to your leadership with these five reasons...
Small teams more efficient than large teams. Smaller and more efficient teams can help reduce costs. Believe me, I've managed development teams of more than 25 app developers in size on large government projects and there was nothing inexpensive nor efficient about it. And I was only managing one of three such teams on the project. Our vice president at the time said we couldn't lose money faster if he was driving down the street with a car full of cash and all the windows open. And he was right. But we wanted to win the project badly and we did so we were faced with a huge system conversion project and felt we had no choice. Hindsight may be 20-20.
Less re-work. Agile dev teams are usually smaller and run more efficiently because they are focused on a smaller set of requirements during each sprint and focused on rolling out a new functionality in a very short period of time. Not much can fall through the cracks that way. By focusing on a smaller set of requirements, there is less chance to screw up and, therefore, much less chance for costly re-work. Plus, anything that does get overlooked can just be included in the next new functional roll-out.
Perfection is not required to stay on track. As just mentioned, if something is overlooked, it isn't the end of the world. I ran a $1.2 million software implementation project for a large government entity while at a professional services organization. The dev manager overlooked something very critical which resulted in a large amount of rework which used up all of the budget when we were only 60% through the engagement. It ultimately resulted in the cancellation of the entire engagement. What a waste. This is an extreme example and agile would not have saved that project, but in the agile world, if something is omitted from a sprint, it can go in the next functional rollout. No high costs, no big rework.
Better customer engagement. Because things are happening rapidly, you will often find you have better customer engagement in the project activities. Review and rollout is happening in short bursts so your customer can ill-afford to disappear for days on end as they sometimes do on waterfall projects where their other day job gets in the way.
Progress is obvious very early. Customers like this one. During long waterfall projects some project clients get uneasy as they see budget being expended while planning is happening – long before the “real work” starts and very long before they see any tangible fruits from that effort. Not so with agile – they see progress and functionality early and often. As long as it's done right, agile can keep customer satisfaction very high.
Summary / call for input
There...you now have five decent arguments. The weight each of these will have in your organization will, of course, depend somewhat on the complexity of your projects, the customers you are involved with and the type organization and industry you are in. Good luck.
How about our readers – have you ever had to go to management to justify a change like this? What additional reasons would you give for wanting to change your organization into an agile one? We all know that going to management with good arguments will help you with your case so for those of you who feel strongly about agile vs. waterfall please share your thoughts. Thanks!
Try going to your leadership with these five reasons...
Small teams more efficient than large teams. Smaller and more efficient teams can help reduce costs. Believe me, I've managed development teams of more than 25 app developers in size on large government projects and there was nothing inexpensive nor efficient about it. And I was only managing one of three such teams on the project. Our vice president at the time said we couldn't lose money faster if he was driving down the street with a car full of cash and all the windows open. And he was right. But we wanted to win the project badly and we did so we were faced with a huge system conversion project and felt we had no choice. Hindsight may be 20-20.
Less re-work. Agile dev teams are usually smaller and run more efficiently because they are focused on a smaller set of requirements during each sprint and focused on rolling out a new functionality in a very short period of time. Not much can fall through the cracks that way. By focusing on a smaller set of requirements, there is less chance to screw up and, therefore, much less chance for costly re-work. Plus, anything that does get overlooked can just be included in the next new functional roll-out.
Perfection is not required to stay on track. As just mentioned, if something is overlooked, it isn't the end of the world. I ran a $1.2 million software implementation project for a large government entity while at a professional services organization. The dev manager overlooked something very critical which resulted in a large amount of rework which used up all of the budget when we were only 60% through the engagement. It ultimately resulted in the cancellation of the entire engagement. What a waste. This is an extreme example and agile would not have saved that project, but in the agile world, if something is omitted from a sprint, it can go in the next functional rollout. No high costs, no big rework.
Better customer engagement. Because things are happening rapidly, you will often find you have better customer engagement in the project activities. Review and rollout is happening in short bursts so your customer can ill-afford to disappear for days on end as they sometimes do on waterfall projects where their other day job gets in the way.
Progress is obvious very early. Customers like this one. During long waterfall projects some project clients get uneasy as they see budget being expended while planning is happening – long before the “real work” starts and very long before they see any tangible fruits from that effort. Not so with agile – they see progress and functionality early and often. As long as it's done right, agile can keep customer satisfaction very high.
Summary / call for input
There...you now have five decent arguments. The weight each of these will have in your organization will, of course, depend somewhat on the complexity of your projects, the customers you are involved with and the type organization and industry you are in. Good luck.
How about our readers – have you ever had to go to management to justify a change like this? What additional reasons would you give for wanting to change your organization into an agile one? We all know that going to management with good arguments will help you with your case so for those of you who feel strongly about agile vs. waterfall please share your thoughts. Thanks!
RSS Feed
