- Increased Visibility – We can see our work, define clear priorities and we can more easily identify bottlenecks and measure productivity.
- Team Continuous Improvement – By implementing a rhythm of retrospectives, self-organizing teams have taken ownership of how they can improve their delivery process.
- Predictability – By limiting WIP and getting consistent in delivery, businesses can make better decisions. When priorities change, leaders can make informed decisions about the impact of making a change.
- Faster Time to Market – By forming feature teams, investing in test automation and continuously integrating, we can optimize to delivering value quicker.
These gains have gotten us much closer to delighting our customers. However, the world has introduced factors to the environment that have impacted development, even Agile development. These key impactful advances include:
- DevOps – Beyond Test Automation and Continuous Integration we now have the tools and environments to deploy continuously.
- SaaS/Cloud – Cloud technology has led organizations to transition away from packaged software to online versions and SaaS models. This allows us to deploy more often and to have access to real-time analytics on product usage.
- Smart Phones – Almost all of our customers and stakeholders have a smart phone. This gadget has made our market more tech savvy, even tethered to tech.
What does this all mean? We can now push software out quickly, even daily, and see how our actual users are maneuvering our product instantly. It also means that a tech-hungry, tech-reliant general population combined with the ability to deploy commercial software continuously means a much faster pace of production and response.
Agile Manifesto 2.0
While the Agile Manifesto helps companies keep up, it’s time for a new Manifesto to stretch the goals and see beyond the curve of market demand.
Here is how I would write the Agile 2.0 Manifesto:
Value over Delivery
Too often I see agile teams still focused on optimizing the output of delivery to a set of requirements as opposed to focusing on delivering value early and often.
Validated Market Feedback over Quick Stakeholder Feedback
Most Scrum teams are focused on shortening the feedback loop to their stakeholders. This isn’t good enough. We need to be getting feedback from the market as fast as possible and letting this feedback drive our product decisions.
Continuous Delivery over Incremental Development
It is no longer just about getting potentially shippable product every sprint, but getting value in the hands of a customer even faster.
Business Agility over Team Level Agility
We need the whole organization working with agility. All departments (marketing, finance, Ops, HR, Strategy, etc.) need to be able to quickly adapt to change, not just the technology group.
Agile Manifesto 2.0 Key Practices
In order to live the values of the new manifesto, key practices need to happen.
1. Discovery vs Delivery
Our priority should not be on delivering a product built on shaky assumptions but disproving false assumptions as fast as possible.
2. Feature Teams vs Component Teams
Component teams are optimized for efficiency of delivering output while feature teams are aligned to delivering value.
3. DevOps vs Test Automation
Keep automating in the pursuit of getting code all the way to production as fast as possible, not just working in the test environment.
4. Release Continuously vs Integrate Continuously
We won’t get true feedback until the code hits the customer. Push the finish line as far as possible.
5. Goal Driven Investment vs Budget/Plan Driven
Budgets assume our upfront assumptions are correct and typically have an upfront approval. How about we focus on a continuous investment model where the team has to continually make the business case to get additional funding? This will encourage early value delivery, which will in turn fund the initiative.
6. Objective Decision Making vs Subjective Prioritization
Most of the prioritization is done today based on opinion, hunch, and guessing. What if we based our decisions on data-driven market validation?
7. Measure Value vs Velocity
Are we productive if we are delivering a bunch of features but the wrong ones?
8. Serve Customers vs Stakeholders
Most teams have been good at shortening the feedback loop by adding stakeholders into their sprint reviews, but how long is your feedback loop with your customers?
9. Hypotheses vs Requirements
The word requirement invokes a thought of a fixed factual thing. However, it is nothing more than an educated guess. We should treat every feature request as a hypothesis that we need to prove true.
It took decades of building the wrong products in the wrong way to create the first set of Agile values and principles. Today, we’re getting better at building in the right way and better at guessing the right product, but it’s probably not enough to keep pace or beat the competition. It’s time to iterate and evolve Agile. What do you think? Is there anything missing? Please share your thoughts in the comments below.
