Agile 2.0 & The Evolution of its Methods
The way we understand Agile needs to evolve.
Remember that our higher order objective is to validate our ideas the fastest, cheapest way possible. Actually building and launching a product idea is generally the slowest, most expensive way to validate the idea. — Marty Cagan
Even though organizations are adopting more modern and efficient Agile software development methods (like SCRUM and Kanban), they are still having trouble delivering what customers actually want or need. Although we’ve experienced many benefits to the modern methods and practices, we’re also experiencing a long list of issues as well.
For example:
- Customer or market needs are not fully understood
- Envisioning a big picture is difficult when building incrementally
- Velocity is prioritized over product value
- Fuzzy or missing requirements
- Single voice for backlog prioritization
- Scope Creep
- Buildup of UX and technical debt
- Infrequent collection of customer input and feedback
Misunderstanding Agile
We all know that these and many other complaints about Agile based processes aren’t new. In fact, I’ve had lengthy discussions with various professionals on how Agile is “bad” for over a decade now. But from the very beginning, each conversation I’ve had contains the same basic themes on how people view and misunderstand Agile:
Theme 1: Agile is fundamentally flawed
The individuals that have had this point of view represent a wide variety of disciplines within product development teams. They typically believe that Agile only advocates delivering solutions and that velocity is the key metric for success.
Theme 2: Agile focuses on development and not the user
Most of the people that have had this viewpoint are research or design professionals. They believe the majority of the Agile based activities that are practiced treat research and design as secondary or unnecessary.
Theme 3: Agile and SCRUM are the same thing
Almost all of the development professionals I have spoken to believe Agile is SCRUM. They were either taught by an Agile coach or learned on their own about Agile based processes and now have a tight association with understanding Agile and it actually being the SCRUM framework.
For me, all of these misunderstandings sum up to a single issue of not really knowing what Agile is.
So what is Agile…really?
There are a lot of definitions of “Agile” out there and most of them are defining either a set of processes, a workflow or a framework. All of these definitions confuse the intent of what Agile really is and unfortunately, they keep getting referenced and reinforced.
Here’s the most basic definition:
Agile is a set of values and principles
That’s it. Well, sort of. It also helps to understand the values and principles of Agile that were originally created:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
To learn more about the values and principles, the original members that created it, and the thousands of people that support it, please visit the Agile Manifesto website.
So if this is really what Agile is, then why do people have so many issues and say that Agile is bad? My theory is, everything they’ve probably heard or have been taught is either a specific method, process, or iterative frameworks that support these values and principles. For example:
- Scrum
- Kanban
- Lean
- Adaptive software development (ASD)
- Agile modeling
- Agile Unified Process (AUP)
- Disciplined agile delivery
- Dynamic systems development method (DSDM)
- Extreme programming (XP)
- Feature-driven development (FDD)
- Rapid application development (RAD)
With all of these development methods being taught as Agile instead of these as being Agile, it’s no real surprise that people get frustrated.
Now what?
Beyond helping to spread the word of what Agile really is, we need to conduct an honest retrospective of Agile and its most popular methods, identify and isolate the core problems, define potential improvements, and then implement solutions.
Fortunately, it has already started.
In 2007, only six years after the Agile Manifesto was first created, Desiree Sy published an article describing issues she and her team at Alias (now Autodesk) had experienced when first adopting Agile methodologies. This article also outlines how the team embraced the Agile values and principles, and eventually adapted their processes in order to adopt a development methodology that worked for them.
This article, among others, helped inspire Agile thought leaders like Kent Beck, Jeff Patton, and Marty Cagan to think differently about Agile in order to improve the definition and spread the word on how to augment some of the core methods.
Agile 2.0
At the Startup Lessons Learned Conference hosted by Eric Ries in 2010, Kent Beck talked about Agile programming and how the Agile Manifesto should evolve for startups. You should check out the video, but here is the basic overview of the update he proposed:
Team vision and discipline over individuals and interactions
Validated learning over working software
Customer discovery over customer collaboration
Initiating change over responding to change
Even though the updated version he proposed was originally meant for startups, I believe these evolved values hold true for mature organizations too.
The Evolution of Agile Methods
Taking the insights from Desiree’s article and years of experience working with and consulting Agile teams, Jeff Patton and Marty Cagan have evangelized an evolution to the core methods and call it Dual Track Scrum; or also known as Dual Track Agile, Dual Track Development, Product Discovery and many others.
To break it down simply, Dual Track Scrum is a parallel process that supports two components (or tracks) inside of a single development model:
Continuous Discovery
- A process that helps us understand and decide what is valuable*
- Focused on learning and validation
Continuous Delivery
- A process that allows us to develop and deliver value*
- Focused on speed
(*value is for the customer, company and the user)
These evolutions paired together are powerful and I believe the majority of the issues we all experience with implementing current Agile methods could potentially be resolved if we updated our understanding and implementation.
Summary
Now I know there is no single silver bullet or panacea for creating good products or services. There are a lot of things that need to fall into place, and most of it starts with the culture of the organization. But in the spirit of Lean methodologies, we can choose to learn, measure, and build upon what we already find valuable in order to evolve.
Have thoughts you’d like to share? Post them below!
— — —
