Many companies are interested in Agile, staff members often read a book and then get started on adopting Scrum, XP, or other Agile methods. What is curious to us is that while these organizations want the benefits, most have not spent the time to figure out what the business case is. If you are planning to adopt Agile, or are doing Agile but want to make improvements, I urge you to think about your outcomes. Where do you hope to be in 3, 6, 12, 18 months, and what investment are you willing to make to get there? Here is a simple framework for thinking about the business case for adopting Agile and Lean in your organization. The business case should help clarify what are the one or two key metrics you will want to measure to benchmark your Agile and Lean adoption against. If you are building a business case it is important to measure the current state so you know where you are starting from. Tracking these metrics should provide transparency into both the investment and the return your business is getting from adopting Agile. Finally a business case for Agile and Lean is a business friendly way of conveying the goals of these changes outside of IT, and helps the sponsors understand both the benefits, the costs, and timeframe. Your Agile and Lean adoption will go much smoother if you make the personal investment of effort to determine your goals and think about what it will take to get there.
The Agile and Lean Business Case Framework.
When determining the Agile and Lean business case, we need to look at internal and external costs, and the benefits we expect to achieve. The case and measuring future performance will rest on data. These are the metrics we recommend capturing:
Time To Market:
How long in your current environment does it take to go from customer need identified by the customer, to their need fulfilled by your business? Agile and Lean drive major improvements in time to market, however if you cannot measure these currently, those improvements will be anecdotal instead of consequential. Time To Market (TTM) in a project is the time required to go from project inception to release into production, and then the time between releases. For a traditional project that runs 8 months, TTM = 8 months. For an eXtreme programming project that take 6 weeks to deliver the first release, and then does weekly releases that deliver business value TTM = 1 week. As you can see TTM will fluctuate depending on the projects underway.
What is the cost per project in your current environments, from the day someone starts working on the project, the first meeting of stakeholders, to the final close out of the project budget? This includes all of the people who put time against that project, be they stakeholders, performers, managers etc? What are the hidden costs in your current environment? (External support groups, etc.) The true cost of running a project includes all of the people and all of the hours put in. Many times in big companies there are stakeholders who contribute time to a project but they are not included in the budget, there funding comes from elsewhere. Having a clear cost picture will create a solid baseline to measure savings.
Delays and wait time:
Where are long waiting periods experienced in your current projects? Does it take months to get hardware, weeks to deploy releases, weeks to get system accesses, months to get personnel assigned to the project, weeks to get feedback from a customer? Wait time is the single largest source of waste in traditional IT environments. Understanding how much wait time occurs requires a bit of work, but it is usually a large cause of frustration, so talking with project teams, project managers and customers will provide a wealth of data on delays and wait time in the current environment. HINT: When looking for delays are wait time, start wherever there is a hand off in your current project process. Every hand off will have delay and wait time associated with it. Capture the number of delays and the amount of wait time with each delay.
Return on investment:
For companies that start projects based on who and how loudly they are asking, this may be a tough one. However a key benefit of Agile and Lean is that ROI occurs early and often. What is the ROI on projects in the portfolio? Do they require a two year pay back period and generate a 20% return? How are your project investments linked to the bottom line on the company? Are they simply considered a cost of business? If you don’t have this data, someone does, and you will need it to show how speed, continual customer and market feedback, increased collaboration, and continuous improvement flow wealth back into the business. Project sponsors should know: how much the project cost, and what financial benefits were derived.
Gather baseline data on how your department is doing from an employee perspective. We are specifically interested in work related morale, not how they feel about the parties or the daycare. Masking poor work environments with parties and celebrations is common. This data could come from confidential surveys run by third parties. The HR department may have this data, if not, then do a survey and get a baseline, this is a fairly well understood process in HR.
Gather data on how your department is doing from a customer perspective. This also could be confidential surveys run by third parties. The customer data should be gathered from the consumers of the output of the project – the people who needed ‘it.’
There is lots of other data that could be baselined, usability, defects in production, etc. However these are less important.
At the end of the day we want to deliver only what the customer wants as quickly as possible, for the least cost.
I’ll continue the Agile and Lean Business Case in following posts…