Building Your Business Case for Adopting Agile and Lean

  • 1

Building Your Business Case for Adopting Agile and Lean

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.

Customer Satisfaction:

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…
Robin Dymond

  • 2

Discipline Of Delivery, Practice Of Perfection

A recent conversation regarding Agile in a large company brought home (again) the challenge of building and maintaining a discipline. To be good at something requires both patience and practice. Patience to take the time to learn and understand, and practice practice practice to become good at it. And then more patience with yourself because learning means making mistakes, understanding them, improving, making more mistakes, getting help, trying again, etc. Getting great at Agile delivery is a multi-year undertaking. It requires everyone in the organization learn, change how they work, and embrace the discipline of delivery and the daily practice of reaching for perfection through regular improvement to how they deliver. How many people start martial arts? How many become black belts? Agile and Lean represent life long paths to businesses that want to maximize their worth to customers, shareholders and the staff who make that business what it is. If you do Scrum for 3 months, you may think you know Scrum. But just because you know the pattern doesn’t mean you have finished. In fact, you have just begun the journey of understanding a very different way of working. Toyota developed Lean and after 50 years they declare they are far from being done. The world’s best Lean manufacturing operations run at 50% Customer Value Add (CVA). Almost all knowledge work companies run at less than 10% CVA. We all have a very long way to go. So why are some companies struggling to sustain Agile in their business? Perhaps for the same reasons we do we not work out every day, pay every bill on time, take not enough time with family, or have that black belt? The basics are straight forward, we can learn those quickly and get immediate gratification and positive feedback. The intermediate and expert capabilities are much harder to learn, take more time, and the rewards come slower. That is when we need the discipline, that is when we will struggle with the difficulty, and that is the time we need to focus on the small improvements that keep us moving forward.

  • -

A software engineers view on the career benefits of working Agile

I recently came across this excellent post on why going Agile can be a big benefit for the people on teams. We regularly see morale increase and people enjoy themselves more at work once they are over the change curve and using Agile. In his blog post, Theodore explains in detail why he thinks working Agile is better for his career. His take is insightful, some of my favorite quotes are:

“You develop strong relationships and you are able to learn so much from other people’s experiences and perspectives. Pair programming has helped me develop a better understanding of what I don’t know and an even stronger understanding of what I already know. And it’s not only other developers you develop these relationships with. As requirements change, you interact with people from marketing, product, legal, qa, project managers, designers, and the list goes on.”

“Understanding requirements is often the most difficult part of developing software. As requirements change, with constant engagement from the customer you have a better chance at meeting those requirements. The other piece of this value has to do with deadlines. Contracts are hard deadlines. In the software development, with all its moving pieces, it’s pretty silly to commit to arbitrary dates six months from today. But if you engage stakeholders into your development process, they have clear visibility into the progress of the project. You don’t have to make excuses for why the project is late. They already know what you’re working on and where you are. How does this benefit you? Well, you get to deliver software that actually meets the customer’s needs. Who’s the rock star now?”

I won’t spoil the punchline, you’ll have to read on Theodore’s blog

  • -

Agile 2008 Toronto August 4-8

Agile 2008 is coming, and we’d like to invite you to participate. Deadlines are quickly approaching for participants to submit proposals. We encourage you to document and submit your agile experiences, training ideas, practices, and how you are succeeding with Agile and Lean. We also want to hear about development practices, organizational change, and how ideas from Lean, Six Sigma, and other process improvement initiatives compliment or conflict with Agile. Agile is a small but rapidly growing community and Agile 2008 promises to be the most innovative and successful Agile conference yet.

Innovel’s David Douglas is participating in Agile 2008 as a reviewer of the French language Stage. David is submitting proposals on Agile in non-IT projects and decision making in Lean and Agile environments.

Robin Dymond is participating in Agile 2008 as an Assistant Producer of the Learning and Education Stage, and a reviewer of the Agile User Experience and usability stage with colleague Jeff Patton. Robin is submitting proposals on Product Owner training, Integrating Lean and Agile, and other topics.

We look forward to seeing you at Agile 2008!

Agile 2008 Banner

  • 2

Core Principles Lost When Microsoft Solutions Framework Meets Agile

In discussion with a client last November I learned that MSFT was proposing a new, updated version of Agile, called MSF Agile. Intrigued that I had not heard about this, I did some research, and was very surprised! I posted my findings to the Scrum Development Group, where 4500 members discuss Scrum and Agile implementation, adoption, “how to” issues, tools, etc. OK, I admit that, by design, my initial post was provocative and generated some vigorous responses. Over 150 replies were posted on this topic, many from thought leaders in the Agile community. The discussion has revealed some very interesting points of contention between those who worked for Microsoft and the Scrum and Agile community, and many real grounded concerns.

As consultants we need to deliver a business goal when helping clients adopt Agile techniques – a faster, more productive team that consistently delivers valuable benefits to the customer and the business. Helping numerous large clients adopt Scrum and Agile techniques, we face on a day to day basis the challenge of change. Agile methods have some inherently difficult to implement principles for most organizations. Some of these include self organizing around the work, deemphasizing roles – asking team members to take on tasks not in their specialization, servant leadership, elimination of big design and planning efforts up front, direct and continuous involvement of the business in the delivery process, and early then continuous delivery of business value throughout a project, to name a few.

It turns out that Microsoft did some market research, and found out that some companies are struggling with these issues, and that implementing Agile methods is hard. This is not news. Microsoft’s response to this research however cuts to the core of the issue. With MSF for Agile Microsoft chose to re-define “Agile”, by adding numerous traditional phased/waterfall practices back into the process, presumably in order to make Microsoft’s “MSF for Agile” product more saleable,. What are the impacts of these changes? I would prefer to quote Ken Schwaber’s analysis:

“[MSF for Agile] defines roles within the development team, so it isn’t cross-functional. It tells the team what to do, so it misses self-management. It defines what steps to take, so it isn’t empirical. It has increments that aren’t potentially shippable, so it isn’t lean. Lots of artifacts and no emerging list of requirements and architecture, so it is wasteful and not lean/agile.”

Removing many of the core principles that make Agile the most effective way to work isn’t the only issue. Microsoft chose to roll this process into their tools and the marketplace without independent peer review, without testing it with real teams, and with no comparative analysis on this new software development process vs. proven Agile methods such as Scrum. Should we expect better from the world’s largest software development tool vendor? Microsoft has enormous market presence, and as such has the opportunity to influence many billions of dollars of IT projects. Microsoft had the opportunity to make proven Agile methods the centerpiece of a tool suite that could help customers make the transition to much improved productivity. Instead Microsoft co-opted an important brand (Agile), but delivered a process that is missing key Agile principles and practices, and cannot provide the business value seen by teams adopting Scrum, XP, or other market tested and proven methods.


  • -

The Scrum Development Mailing List

Ever had a question about scrum but you didn’t know who to ask? Ever wished you could discuss a burning issue with an author or thought leader in the Agile community? The Scrum development list is the most active forum for the Scrum community. Subscribers include authors, thought leaders, newbies, working scrum masters / agile coaches, project managers, and interested members of the agile community. Scrum Development is an Yahoo group email list. Subscribers receive emails sent to the list from other subscribers. This allows subscribers to post a topic, and reply to each other’s posts and carry on “public” conversations. The group has approximately 4,500 members, and membership is moderated, so spammers cannot access the list. The postings can also be read on the group’s website The topics on the list run the gamut, and include everything from beginner/newbie questions about how to do scrum on a first project to advanced topics on enterprise conversion, and everything in between. Authors such as Mary Poppendeick, Jeff Sutherland, Mike Cohn, and Ron Jeffries regularly contribute to discussions on the list.

Given the amount of traffic it can be hard to keep up with all of the topics. If you subscribe, scan topics quickly, and delete articles that have questionable topics. Long discussions with lots of contributors are good signs, it means that the topic is interesting to many, and
that there are some good debates/discussions in progress.

  • 1

Adopt Agile for Double Productivity, Happier People.

In adopting Agile methods, software development teams regularly double their productivity while increasing quality, customer satisfaction and morale. This article discusses my first application of Agile methods with a 15 person software team, and the benefits we achieved. – Robin Dymond.

I never really thought about productivity improvement the first time I used Agile methods. I was more concerned with helping the business get it’s product out the door. The team had been running for a year, had produced 125,000 lines of code, nothing could be released, and investors were nervous the startup was never going to get to market. I was hired in the fall of 2002 to turn the project around and get the product to market. Startups are often run by people who tend to be young and charismatic but not necessarily experienced. The challenge of getting the product to market was pretty straight forward – stop building buggy new features, and let’s get what we’ve got hardened (thoroughly tested and debugged), and into the hands of sales. Once this was done, the dilemma arose: Do we adopt a traditional waterfall process? We had a meeting with a large potential first client – they wanted some very different features from what we had so far, and were willing to fund that development. The week before we’d had a similar meeting with a different customer and a different set of change requests. Since I had just spent 2 years as the founder and CEO of a startup, I could completely sympathize with the business predicament. The company needed a large anchor customer, and the team had to be able to meet their needs as soon as they arrived. However the team could not wait for the customer to appear when there were so many additional features we could add.

We made the decision to put out a release every month, and not do “big” features that would prevent us from releasing for a few months. This would give sales time to land that big first customer and still keep the team busy and productive. However frequent releases would require a lot more builds, which were time consuming and kept Dave the dba away from doing database development. To solve the build issues we decommissioned Visual Source Safe and migrated to Borland (Starbase) Starteam. On advice from colleagues at Thoughtworks Canada (Servidium Inc.) we installed Cruise, a first outside of Thoughtworks at the time. Cruise control is a fantastic build automation tool. This productivity tool freed up Dave and gave everyone visibility into the health of the code base and builds.

Because we were releasing every month, we needed a better way to stay in sync as a team. The weekly developer meetings were stale and didn’t meet our needs, so we tried the daily morning stand up meeting. At first it was uncomfortable. I was trying to build a sense of self reliance in the team, and suddenly we had everyone telling me what they had done yesterday and planned to do today. So I asked the lead developer to run the meetings, and participated by giving updates on my day in the same way. The uncomfortable feeling quickly passed for everyone as we emphasized this was synchronization for the work and not a report out to management. The team grew to appreciate the transparency the stand up meeting gave into each other’s work, and so the team kept it.

Around the time we were trying out stand ups, Johnathan Rassmusson, a senior consultant at Thoughtworks told me about Scrum. It had a lot of the characteristics of what we were doing, but provided more formality around the customer interaction, prioritization, and cadence. I really liked what I found in Ken Schwaber’s book, it met all of my criteria for this team, project, and business case, so we adopted Scrum and began to get our requirements into a product backlog, with the CEO taking the customer role and the Product Manager/UI Designer becoming the Product Owner, while I, the VP Technology took the role of Scrum Master. When we met for our first product backlog session, the CEO’s priorities were A, A+, A++, A+++, A++++, and A+++++ and it was all needed immediately. We promised to work on the A priority items with 4 and 5 plusses first, and show them in one month. I think the CEO looked at me like I had tricked him into giving a priority. However 3 months and 2 releases later, with the team developing and releasing at a steady cadence, the CEO would readily negotiate on scope to get another release out, and the business team as a whole became much more engaged with the market and potential customers to determine the best priorities for new features.

We also started learning about and implementing test driven development. This was eye opening for the team. Microsoft’s recommendations (at the time) were to put business logic in stored procedures for application speed/response time and to use the ASP web controls to speed up UI development. Following these recommendations meant much of the application had only 2 tiers, and no easy way to write unit tests around small pieces of business logic. In this scenario unit tests required a test database with known (golden) data so stored procedures could be checked. For unit testing logic in the UI, session state, javascript, and other browser dependent variables were needed, making unit testing difficult and brittle.

As we continued to work on improvements to our development environment and our techniques, we embraced refactoring and the first C# refactoring plugin for visual studio. The team also began learning about patterns, and as more complex problems came up the team more frequently turned to patterns for solutions that had been proven, could be implemented in the business logic layer, were unit test friendly, and provided a path away from the 2 tier architecture that had grown in the first year of development.

The development team went from not delivering to delvering more than the sales team could sell. In the end the company’s investor’s drastically decreased funding, the business shrank, and many of us moved on. For many of us the experience was very valuable. For me, I had found a way to work that could meet the needs of fast moving businesses in competitive environments, removes the death march mentality endemic in IT, and provide an environment where transparency, safety, learning and continuous improvement are the norm.

We looked back at the 2 years and made some startling discoveries:

What Changed

Year 1

Year 2


Ad Hoc

Agile – Scrum and XP







Lines of code written





3 releases, 10 production updates




  • There was a dramatic increase in quality – from 1 buggy release to 13 production releases.
  • There was a 96% improvement in productivity based only on lines of code. While lines is often not the best metric, in combination with the above fact it shows a startling improvement.
  • A deathly quiet project room occasionally punctuated by teasing/sarcasm to a hive of collaborative activity that included laughter, engaging conversations, and of course an occasional 1 week crunch to get a big release out.

The improved results were driven by focusing on continuously improving our Agile implementation, making architecture changes to support Agile engineering practices, and experience gained with C# and .NET. All of these changes required a focus on learning, providing time for change, and creating a discipline of experimentation, of test and learn. As a leader my success is defined by how well I can help others succeed. With this turn around we had very few personnel changes, yet the success of the people was dramatically different. It is critical that leadership in the twenty first century realize that the systems and organizations in which we work can define our ultimate success or failure. Agile and Lean are two systems that help people succeed, and as such unleash far more productivity than ever envisioned. This is why I am making a career out of helping businesses adopt Lean and Agile.

For more information see the MSDN presentation on Agile and .NET in our articles section.

  • -

Growing an Agile Coach Community

The Growth of an Agile Coach Community
Adopting Agile takes courage, perseverance, and continued reinforcement. The growth of an Agile Coach community can add sustainability to your Agile adoption. Read an Experience Report from the Agile2007 conference about this very topic.

  • -

Four Weeks

Zara ModelThink delivering working software every 30 days is difficult? Got an idea for a great new outfit? How long would it take to see that idea become a piece of clothing available in 1000 stores? As we look to improve our businesses’ ability to respond quickly to its customer needs, its helpful to look at other businesses that have used speed to generate huge advantages and gain marketshare from much larger rivals. An unlikely place to look is fashion retailing.

When Madonna gave a series of concerts in Spain, teenage girls were wearing at her last performance the outfit she wore for her first concert. When Spain’s Crown Prince Felipe and Letizia Ortiz Rocasolano announced their engagement in 2003, the bride-to-be wore a stylish white pant suit. Within a few weeks, hundreds of European women were wearing something similar. All thanks to Zara, the pioneer of fast fashion. In April 2006, the company owned by the Inditex Group, took the lead in fast fashion apparel away from giant Swedish retailer, Hennes & Mauritz (H&M) by posting $8.15 billion in sales in 2005, compared to H&M’s $7.87 billion.

Zara Tokyo store

How can Inditex thrive when Europe’s entire textile industry is under threat from cheap imports from China? After all, labor costs in Europe are 17-20 times higher than in Asia. In a word – speed. It takes Zara four weeks to go from identified consumer need and fashion concept to clothes in its stores. Most of Zara’s inventory is sourced through this fast channel. To enable this speed Zara owns the complete supply chain, from manufacturing through distribution and retail. Some 300 designers work at the firm’s head office in La Coruña in Galicia in northern Spain, producing 1000 new styles per month. They are in daily contact with store managers to discover bestselling items. The remaining inventory is sourced through low cost off shore manufacturers, similar to other retailers.

Zara’s fast products are deliberately created in small batches to avoid oversupply. Most lines are replaced quickly with yet more new designs rather than with more of the same. This in turn generates scarcity of supply. Shoppers cannot be sure that something that has caught their eye will appear in the store again—or can be found at another Zara store, even in the same city. A higher average selling price is maintained.

Zara’s production cycles are much faster than those of its nearest rival, Sweden’s Hennes & Mauritz (H&M). While an entirely new Zara garment takes about four to five weeks from design to delivery; a new version of an existing model can be in the shops within two weeks. This process takes six to twelve months for an average retailer. In a typical year, Zara launches some 11,000 new items, compared with the 2,000-4,000 from companies like H&M or America’s giant casual-fashion chain, Gap.

Text box - reacting quickly Don’t try to predict, react.
The fast production chain at Zara removes a significant amount of risk that comes with fashion forecasting. So Zara finds itself in the “blessed” position of not really having to take a bet on fashion as much as follow it. A 2004 Bain & Co. study found that fast-fashion outlets in Spain and Britain posted average double-digit sales growth, compared with 4% growth in overall retail sales in those countries.

Zara Open Concept Work Space

Zara’s design work space is open concept and highly collaborative.

Fashion trend identification is a daily constant effort. All of Zara’s shops use point-of-sale terminals to report directly to La Coruña. On top of that, every evening store managers consult a personal digital assistant to check what new designs are available and to place their orders according to what they think will sell best to their customers. In this way, its store managers help shape designs. Zara does not employ star designers but often unknowns, many of whom are recruited directly from top design schools. Inditex is extremely clever in how it uses technology, says Andrew McAfee, a Harvard Business School specialist in the corporate use of information technology. The company keeps its technology simple—even a little old-fashioned—but as a result spends five to ten times less on information technology than its rivals.

Zara Toronto store Zara is also more parsimonious with advertising and discounts. It spends just 0.3% of sales on ads, compared with the 3-4% typically spent by rivals. “We try to avoid markdowns” says JM Castellano, Inditex’s deputy chairman. For many retailers 35-40 percent of total merchandise is sold at hefty discounts. “This business is all about reducing response time” says Castellano. “In fashion, stock is like food, it goes bad quick.”

    This article contains material from various internet business news sources including The Economist,, AMR Research, and others.

  • 1

The “W” Campaign

The “W” Campaign

Take a look at the cards on your team’s board. Which tasks your team does in this iteration actually add value for your Product Owner? How many are done to meet regulatory or end customer needs? How many are done that don’t add value to the customer? How many of the tasks are repetitious and manual? What tasks have artificial delays built into them?

We know there are many tasks in every team that are non value add. That’s why we are starting the W Campaign. We are asking teams, your teams, to identify waste (non value add activities) in the software development process, and help enable the company to remove it. So if you have a task on the board that is waste, grab a red marker, and write a red W on it. After your team has reviewed your board and put red W’s on the waste, invite your product owner, and team’s stakeholders to discuss the waste. Ask management to remove it, politely, but insistently. Removing waste and continually improving processes are highly effective value add activities managers are uniquely positioned to do. Teams go faster when waste is removed. Team members are happier when they can focus on adding value. Below are some ideas for recognizing the seven forms of waste in your software development process. If you are not sure it is waste, discuss it with your team members or product owner.

The seven wastes of software development1

Partially done work – Partially done development ties up resources in investment that has yet to yield a result. Minimizing work in process is a risk reduction as well as a waste reduction strategy.

Extra processes – Did you ever ask, is all that paperwork necessary? Do three groups really add value reviewing that report? A good test of the value of paperwork is to see if there is someone waiting to use what will be produced to add additional customer value. There should be a constant search for the most efficient, effective means to transmit the information.

Extra features – It may seem like a good idea to put some extra features into a system “just in case” however this is a serious addition of waste. Every bit of code in the system has to be tracked, compiled, integrated, and tested every time the system is changed. It increases complexity and is a potential failure point. It may become obsolete before its used, and may be removed or changed before it is ever used.

Task switching – Assigning people to multiple projects or teams is a source of waste. Every time a person switches between projects, there is significant loss of productive time as they get into the flow of the other work. The fastest time to complete projects is to do them one at a time.

Waiting – One of the biggest wastes in software development is usually waiting for things to happen. Delays in starting, staffing and onboarding, reviews and approvals, testing, and deployment are waste. When critical customer need, like a defect arrives in you’re your organization, the speed at which you can respond is directly related to the systemic delays in your development cycle.

MotionWhen a tester or analyst asks a question, how much motion does it take to find out the answer? Each hand off of artifacts: code, documentation, tests, etc. between team members is full of waste. Moving artifacts from one team or project to another is a huge source of waste. The waste is that handoffs and their artifacts don’t, and can’t contain all of the information a person needs to know. Documents are low bandwidth, and require lots of interpretation, which takes time and generates assumptions and errors. Face to face communication is high bandwidth, the interaction allows assumptions to be checked and greatly reduces the amount of interpretation required.

Defects – The amount of waste caused by a defect is the product of the defect impact and the time it goes undetected. The way to reduce the impact of defects is to find them as soon as they occur. To reduce defect waste, the team must test immediately, integrate often, and release to production as soon as possible.


Learning to see waste is an ongoing process of changing the way you think about what is really necessary.

1. Lean software development, Tom and Mary Poppendieck, pp. 4-8.