It was a great evening (I guess around 100 people) with a good presentation and discussions - plus of course, since we are in Texas, BBQ!
I had a pleasure to talk to Jim before the meeting at our ThoughtWorks office here in Dallas discussing on various topics which was complemented by his talk later in the day.
After all the information collected and some thinking, here are some of the top points:
It is not simple to come with a simple way of measuring ROI when it comes to organization transformation moving from typical Waterfall (or other old techniques) project management/implementation to Agile.
I have seen numbers/stats that can justify it, but numbers is just a way of looking at the problem and they can be manipulated in the end.
There are arguments that can better support and justify an Agile transformation.
Jim gave 2 examples - which I think are excellent:
1.a. In a certain project (Agile), there was a list of 100 features to be implemented. A fictional conversation between the Agile Team (AT) and the Product Owner (PO) would go like this:
(AT) - Mr. Owner, can you give us a list of the 3 most important features?
(PO) - No, all my features are important. I want them all.
(AT) - We understand but let's begin with 3 for our first Sprint.
(PO) - Ok, let's pick features A, G, K.
During the planning of Sprint 2, the conversation continues:
(AT) - Ok Mr. 'O. First features almost there. Can you give us 3 more to implement?
(PO) - Well, now I think all of them are important.
(AT) - Right, but then again, we need the most wanted from the 97 remaining features.
(PO) - Let's do B, C and W.
After few iterations and around 25 top features implemented, the conversation would continue like this:
(AT) - Howdy Mr. Owner. Again, we need few more top features to be picked from the list.
(PO) - Oh well, I think we can stop here. The project has already the core functionalities. The remaining features are nice to have but we can live with as is for now. I have other projects that I can invest and that can bring me more return than implementing the remaining 75 features for this product.
Bang! That's your ROI. Now you can incrementally see your product and you'll stop once you reached the point where you want to stop. Plus, with Agile you'll be able to put your product in production much earlier than in a typical Waterfall (or RUP) project because at the end of each Sprint (typically 2 weeks) you'd have a working software, specially if you use Continuous Delivery (see Flickr exem ples) and you don't have to wait 6 months or a year before you have your entire book of 100 features implemented.
But maybe this still doesn't convince your CFO. Knocking the door of the finance team can be challenging if you don't have the right arguments. So...
1.b. Ask your finance team if they want 100% of the value for 100% of the cost or 80% of the value for 60% of the cost. Needless to say, the second option will be more palatable.
Also, negotiating incremental investment can be a better approach. Ask for a reserved budget but say you'll take it in parts. Then after some few Sprints, show the results and get the other part of the project financing and so on. Probably this will be much easier.
Financial responsibility is everybody's job so, collaborating and giving the right reasons to implement your project will help you and your organization.
One of the most interesting measurements collected from empirical data shows something very interesting while comparing typical project to the one executed using agile.
In a typical project, when adding more devs to the team the number of defects spikes - it can attributed to the chaotic code.
In an Agile project, the number of defects does not spike... it is kept under control. This gives more reasons to run projects using agile as if you need more velocity on features implementations, adding more team members properly will not crash your project.
3. Technical debt
This is a somewhat 'hidden' topic, which I don't see discussed very often but I lived it before.
As your software is developed, it needs refactoring, adjustments and bug corrections along the way.
Without Agile and Continuous Integration, one can be blind on the actual software state.
If I have a project that will run for a long time, I dedicate one Sprint after 'X' number of Sprints to deal with the Technical debt including old minor bugs, refactoring and general adjustments.
Using Waterfall or other similar approach, you won't be able to see through the implementation and the technical deficit will be accumulating until the end of the project and it is very likely that you'll have in your hands a typical "Software Monster"(I just defined this :-D ) that can be easily identified:
- Nobody wants to do maintenance on this beast.
- Needs major refactoring.
- Many features are useless, unwanted or outdated.
- If you are a dev and you're assigned to "re-factor" the Software Monster, you know it is a career sink.
So, avoid the Software Monster and technical deficit by implementing what will be useful and will bring value using Agile.
4. Features implementation and Outcome performance
Agile teams will deliver more value (working useful software) sooner. You can give the software to your customers to use as soon as you reach the minimum amount of features.
Delivering the value and the most wanted (working) features will give you the possibility to get users sooner, "test the water", get feedback and improve your product in a much more efficient way.
Perhaps you'll find that the next 'N' features to be implemented look very important to you but based on the current product usage, the main focus should be in another set of features or area that were not important to you.
Many organizations are still considering migrating their project teams to Agile and are stuck in slow, costly and old approaches.
The value of Agile is clear to me but I also recognize that there might be resistance to change because of many organizational reasons.
Overcoming this resistance and correctly implementing Agile will not come in a snap. It will take time and maybe the best way of getting beyond the chasm is taking a pilot project with proper guidance :-)