The (financial) Return of Agile
•Download as PPTX, PDF•
0 likes•802 views
This document discusses calculating the financial return of agile software development practices. It notes that introducing agile practices can increase productivity by 34% while decreasing costs by 27%. However, the biggest benefits of agile may be non-financial, including increased business value, teamwork, customer collaboration, and embracing change. True financial return is maximizing these benefits. The document advocates for smart trust between organizations using agile, with contracts incentivizing customer satisfaction and business outcomes rather than detailed plans.
Recommended
More Related Content
What's hot
What's hot (19)
Similar to The (financial) Return of Agile
Similar to The (financial) Return of Agile (20)
More from Frank Vogelezang
More from Frank Vogelezang (20)
Recently uploaded
Recently uploaded (20)
The (financial) Return of Agile
- 1. The ƒinancial Return of Agile Frank Vogelezang Manager Pricing Office
- 2. Who is Frank Vogelezang Manager Pricing Office Ordina What IT services may cost in order to be competitive What IT services should cost with a healthy financial return President COSMIC Measurement Practices Committee Functional Size of Software Counting Practices Committee Nesma Functional Size of Software IWSM Mensura conference Conference Chair Software Measurement @IWSMMensura 6-8 October in Rotterdam www.iwsm-mensura.org 2
- 3. How to reach the drinks COST MISTAKE shift RETURN DRINKS
- 4. Calculating the Cost of Agile 4 Cost
- 5. Calculating the Cost of Agile is simple 5 Cost 47
- 6. The Cost of (Agile) Software Development 6 € 0 € 500,000 € 1,000,000 € 1,500,000 € 2,000,000 € 2,500,000 Maintenance Development Capers Jones Evaluating Agile and Scrum with Other Software Methodologies 1.000 Function Points 5 years of maintenance
- 7. The Impact of introducing Agile 7 Cost Productivity Agile Waterfall +34% -27%
- 8. Proof for good Agile practices 8 Hennie Huijgens How to build a good software portfolio h.k.m.huijgens@tudelft.nl Steady heartbeat Fixed team Single application
- 9. Mistake of the Century COST MISTAKE shift RETURN DRINKS
- 10. It’s not about Cost 10 ƒinancial Return Benefit Cost
- 12. Whose Benefit? 12 Benefit ? Purchasing IT department Business User Customer
- 13. Benefit for everyone? 13
- 14. What about ƒinancial Return? 14 ƒinancial Return Purchasing IT department Business User Customer
- 15. Cost Benefit ƒinancial Return is maximizing Benefit 15 More Benefit
- 16. Cost pressure and Benefit 16 ƒinancial Return Benefit Cost
- 18. Change the picture 18 ƒinancial Return Benefit Cost ƒinancial Return Benefit Cost
- 19. What Benefit? 19 Benefit ? Purchasing IT department Business User Customer Business Value Teamwork & Responsibility Partnership Elaboration Embrace Change ! TRUST
- 20. MoreAgile Manifesto 2.1 We encounter possibilities to focus more on effectiveness by working Agile and learning from that. Based upon our experience we value: Teamwork & responsibility over Individuals and Interaction over processes and tools Deliver Value over Working software over comprehensive documentation Partnership elaboration over Customer collaboration over contract negotiation Embrace change over Respond to Change over following a plan 20
- 21. Truly Rely on Utilizing STrenghts 21 Benefit ? Purchasing IT department Business User Customer Business Value Teamwork & Responsibility Partnership Elaboration Embrace Change ! TRUST
- 22. The ƒinancial Return of Trust COST MISTAKE shift RETURN DRINKS
- 23. In God we trust 23
- 24. The ƒinancial Return of Trust 24 SMART TRUST BLIND FAITH DISTRUST
- 25. Smart Trust 25 Team Lease Storypoints per sprint Productivity Business value Virtue #1
- 26. Smart Trust ► Agile contracting 26 Period/Conditions/Non-disclosure Definition of Done/Right Incentive on Customer satisfaction Incentive on Business KPI’s
- 27. Focus on ƒinancial return, the Agile wayIf your biggest value is cost reduction 27 Cost Cost Cost More Benefit Don’t go Agile If your biggest value is cost reduction
- 28. Time for a drink COST MISTAKE shift RETURN DRINKS
Editor's Notes
- Van tevoren aangeven dat je de vragen achteraf wilt.
- If you are worried that this will be a presentation with a lot of these bulletpoint slides . . there is only one other slide with so many words in it, and that’s your own Manifesto. Who’s the audience: A : Managers, responsible to get things done B : Consultants, helping to get things done C : Engineers, who get things done
- I regularly meet people who are convinced that calculating the cost of Agile is a difficult thing With my background in costing that is something that took me a while to grasp, because the cost of Agile is rather simple You have a team of superheroes and you know their price You know the length of an iteration and the number of iterations, let’s say four Simple arithmatic will tell you the cost of Agile software development
- But is it really that simple? Suppose you were promised a superhero team that could do a certain software development in four iterations But the superheroes were no longer available and you get a team of leftovers, for a lower price though It turns out these losers will take 7 iterations to produce comparable functionality What does that do to your cost This seems ridiculous because you don’t get what you were promised . . and if this is a bid for a contract you’re right But if you start working Agile this is what happens. People who have not been used to an Agile way of working will not become super Agilistas overnight.
- We have heard the stories of Ben and Larry about what Agile can bring to the team and how the team can improve In my reality people who say they want to know the cost of Agile, actually mean how much they get for their money And there it becomes a difficult question because Agile is more concerned about getting the right software at the right moment then how much product you get for your money. You got what you wanted when you wanted it, isn’t that enough value? Many have tried to compare different ways of software development. Capers Jones has produced this data. He normalized on function points and if you compare it with waterfall development that would be around 3 million. That is data in the order of magnitude that I have witnessed myself. But also in this case I believe the data may be flawed because it is combined from different sources.
- The best research to compare cost is from Hennie Huijgens. He used data from two companies that transitioned to Agile, so he had data on Agile and non-Agile projects.
- He is now working on the data to find proof for good Agile practices. He normalized project cost and duration and plotted this in a quadrant picture where projects that scored better than the mean on both cost and duration are considered a good practice.
- The big mistake we make in IT for decades now is that we talk about Cost. Cost is an inevitable hurdle we have to take to realize a certain benefit. The net effect of the Cost and the Benefit should always be positive. The only thing we’re interested in is the financial return of software development. If it’s not there, why do we need that software development?
- When you make the mistake of only talking about cost, there is always the danger of cost pressure. Cost pressure leads to all sorts of things we have declared of low value in the Agile Manifesto If we focus on cost reduction, what will happen to the benefit? Ben has already said something about that. But let’s explore that a little further.
- Whose benefit lies in cost reduction: Purchasing department is always looking for the best value for money, but translates that to cost pressure. IT departments quite often have a focus on cost reduction, due to the fact that we see IT in terms of cost. Business is already changing their habits towards cost pressure and are looking for benefits. The internal user is not interested in cost, he only sees that improvements take longer and come in smaller steps of less functionality. The customer is just looking for the most appealing functionality, no matter if it’s from you or your competitor.
- This is for most people the current paradigm. If you want to have benefits for all the stakeholders, you get an impossible Escherian picture. Translated into the service we can deliver you get this result.
- If we change our paradigm from cost to financial benefit, will that help? For purchasing department, probably not, although I see some change in the growth of the Best Value approach there The IT departments are becoming more and more business oriented and learn to take this perspective. Business is looking more towards the customer and sees them moving away if they get better service elsewhere. Internal users generally don’t care about financial return, but welcome anything that will speed up service innovation. Service innovation is one of the main drivers for the customer to use your service . . and they are the ones that generate the financial return. So you better keep them satisfied. Where should your focus be? On the customer.
- So the focus should not be on Cost. Cost is the necessary hurdle. Looking at Cost is an inside view that will not generate financial benefit. The focus should be on generating Benefits. And preferrably more of that.
- What will happen if we focus on Cost pressure. Part of the effort we used to generate Benefit will be wasted on overhead related to the cost reduction and will lead to a decrease in Benefit.
- With that in mind we go back to the picture I showed earlier on the financial return. What will happen if we focus on Benefit instead of Cost?
- But how can we change that view? The purchasing department should be looking for the most Business Value for their money. That’s where the Best Value approach is based on. Find the best expert and he will deliver the most value at the lowest cost if you let him do his expert job. That means: no control That’s also one of the new values for the IT department. They can maximize benefit by taking responsibility as IT experts and team up with the business and the users to deliver maximum business value to the customers. The business should learn to think in partnership towards IT. They are the experts in what is the best way forward to technically create the business value you want. Business should be only concerned about what should be delivered, not how. The user must be prepared to take part in this partnership, because it means to him changes will be faster than ever. The customer is usually very happy with this, because change is what he wanted all along. What we need for that is trust. Trust that the other will play his role. Trust that you can let the other do what he’s best at.
- Trust that the other will play his role. Trust that you can let the other do what he’s best at.
- This quote of mister Deming is very hard to fight, although his intent was on the learning cycle, this was used to create a lot of Control.
- Trust has different dimensions, and each dimension has a different effect on the financial return. On the most optimistic – or naive – side of the specturm we have blind faith. The financial return is uncertain. It can be very good or very bad, depending on the one you follow blindly. On the most pessimistic – or controlling – edge of the spectrum we have distrust. This has proven to be not very productive, but still used in the majority of organizations. So trust, but do it in a smart way.
- Build up the trust level, especially in client-supplier relations. Start with a team lease construction, where you contract on the quality of a team but where you can control what they’re doing. If the team has the trust to do Agile development the right way, you can look at the storypoints burndown per iteration. Is it stable, is it improving. Ben can tell you all about that. It should always be done in retrospective with a focus on how the team can deliver more benefits. This can be done at iteration level and is about predictability. A step beyond that is not only to look at the work done, but also to the amount of product or functionality that has been delivered. This is something that is very difficult to do at iteration level, but is something that is typically done every quarter or twice a year. This focusses at the amount of “value for money” or productivity. The ultimate step is to do this on business value. The previous step is an assumption that more functionality means more business value. This is not always the case. This one is the hardest, because how do you measure business value? If it is about a digital channel you could measure it quantitatively.
- Building up your smart trust in an agreement should also be done in a smart way. Build up your contract clauses in an Agile way. Start with the minimum. Then move on to define the deifinition of done / right for contract purposes
- If you can’t step out of the old paradigm of cost reduction, don’t go Agile! But if you really want to be profitable, focus on maximizing the benefits to improve financial return. Then you put the teams in their strength and they will want to improve.