What is the Elevator Pitch for Agile and Scrum?

Premise

Geoffrey Moore in "Crossing the Chasm" talks about an “elevator pitch” for what you are selling. The idea is that you get in the elevator with the CEO of the company and you have the length of that trip in the elevator to explain to him / her what you are doing and why it is important. A classic elevator pitch has the following components:

  • Your target audience
  • The market alternative
  • The new category that your idea/product fills
  • What problem solving capability this new thing provides
  • An alternative that is in the target audiences mind, and
  • The key product features

I won't stick strictly to this format but I will try to capture most of these ideas. There are a number of these pitches out there. I think there are differences based on the kind of people you are working with so here is a version that reflects my contacts.

Elevator Pitch

The simplest version of “Why Agile” comes from Jim Highsmith who says “Scrum / Agile is a risk mitigation technique when our assumptions about predictability do not hold.” He further elaborates “Scrum / Agile are used to provide customers with what they need at the end of the project, not what they thought they wanted at the beginning of the project.”

If you are more interested in Scrum then Bob Schatz of Agile Infusion says that “Scrum is a pattern of practice that helps product developers break complex problems into smaller pieces and then work collaboratively with users to create better solutions.”

The way I look at it “An agile approach to implementing software increases our effectiveness - our ability to deliver value, reduce risk, increase predictability and improve quality. The agile approach is a recognition that traditional software “upfront planning” approaches are not able to deal with the complex situation arising out of the need to evolve requirements, learn how to build the solution and cheaply address the changes that result from this situation.”

And if your elevator ride goes up many floors or you have a slow elevator, you might want to consider a slightly longer explanation …

For organizations that are not happy with the delivery of their software projects, Scrum / Agile is an approach made up of values, principles and specific practices that can help you deal with the constant need to change direction while still maintaining control, to dramatically decrease your time-to-market, to reduce the risk of working with complex projects, to improve the quality of delivery so your customers see fewer defects, while also increasing the engagement and morale of your people.

An Agile / Scrum approach achieves this by:

  • Ordering the delivery of functionality based on the “most important value first” principle, prioritizing our demand based on sound economic principles.
  • Organizing our system of delivery around the “delivery of value to the customer.”
  • Delivering value in short iterations (also called sprints - 1-4 week time-boxes) to a known quality standard so the decision to release can be made at any time (usually when it is determined that sufficient functionality is provided). In other words, “deliver on a cadence, release on demand”.
  • Delivering value piece by piece so that customers can provide feedback as the work is completed.
  • Ensuring there is transparency of progress and constant communication / collaboration especially between the people who need something and the people that can provide it but throughout the whole delivery system.
  • Ensuring that we build plans based on the real capacity of the organization to deliver.

Unlike the traditional development approach, which assumes that you plan a software project upfront and in detail, Agile / Scrum approaches understand that the real world of software is a place where:

  • The customer does not (and cannot specify) exactly what he / she wants, but rather will be able to provide solid feedback when they see a running system.
  • Our teams have potentially lots of ways to build a capability but it is when they start working on the capability, with the whole team (development, QA, documentation, BA, etc.), that they will really understand how to solve the problem and deliver the value.
  • That change will happen and, more importantly, that change is a good thing as it means we have learned something about the requirements or the approach we are taking, and we should leverage that knowledge. This means Agile / Scrum approaches work to make the cost of change low.

VersionOne's "State of Agile" Survey (9th Edition) lists a number of benefits as a result of a transition to Agile including the ability to manage changing priorities, increased team productivity, improved project visibility, increased team morale/motivation, better delivery predictability, enhanced software quality, faster time to market, reduced project risk, and the ability to manage remote teams.

These benefits can be quantified. The benefits that I have directly experienced through my work with organizations (after the first year of the transition) include:

  • Increased visibility and predictability of development projects through common “done”-based reporting.
  • Reduction in end-user defects by 50%.
  • Employee satisfaction at 78% in the new approach.
  • Increased throughput by 1.5X (average, all teams).

By far the biggest problem recorded by organization attempting to become more agile is the problem of changing the culture from a traditional “waterfall” oriented shop to one focused on an agile approach. This is because, more than anything else, a move to agile represents a different way of thinking about how to be successful with software development projects. More information can be found at:

As you do more and more of this work, you see a number of anti-patterns / smells / problems that organizations have when trying to change how they work. More information on this can be found at:

Thinking

Did a bit of research on this and here are some ideas that I came across that I liked:

Ken Schwaber, co-inventor of Scrum: “We'll help you fail in half the time!” (note: have to love this one, even if it is a little cryptic).

Steve Berczuk: “For organizations who are dissatisfied with the overhead and lack of flexibility of conventional software development methods, Agile Software Development is a software development process. Unlike traditional chaotic or document-heavy approaches, Agile Software Development is a lightweight, yet highly disciplined approach that delivers end to end value in frequent iterations, where the stakeholders can re-evaluate priorities based on the state of the application and current market needs at the end of an iteration.”

Subashish Bose: “Scrum is a way to ship products frequently. The most valuable part goes first, so you get the best returns. Quality is never compromised, so you get the best stuff in best quality. That way you get rapid ROI, as well as you can even change your plans based on customer behavior. Change is very easy. It's based on empirical methods and uses feedback loops and continuous learning. So you get to know the most reliable forecasts. Team and people are the focus, so they end up being happy and proud. We moved from waterfall to Scrum for a telecom solutions company and started shipping every four months instead of previous 2 years. We prioritized and shipped the most valuable part first to get the best ROI. It's highly empirical with feedback and learning, so we were pretty sure of where we are going. Guys loved that.”

Brad Appleton: “Agility is all about harnessing the power of collaborative people and frequent delivery to: learn & adapt to change, minimize risk & cycle-time, and maximize returns & customer-value in a volatile global marketplace.”

Use the following URL for manually sending trackbacks: http://www.hanssamios.com/dokuwiki/lib/plugins/linkback/exe/trackback.php/what_is_the_elevator_pitch_for_agile_and_scrum
You could leave a comment if you were logged in.
  • /home/hpsamios/hanssamios.com/dokuwiki/data/pages/what_is_the_elevator_pitch_for_agile_and_scrum.txt
  • Last modified: 2016/07/03 13:38
  • (external edit)