schedule
For several years now, Agile has taken center stage. Yet even though Agile offers several well-established benefits, there's still room for adapting and improving practices.
Outputs vs Outcomes
Agile is neither a new word nor a new paradigm. The 17 people who signed the Agile Manifesto in 2001 were "uncovering better ways of developing software," which they were doing for a long time before that 2001 gathering in Utah. And some Agile methods, such as Extreme Programming, Scrum, Crystal and FDD, existed for a long time before that.
Although we still find a few companies working with Waterfall methodologies, Agile has, over the years, assumed a mainstream status, and it's easy to see why. There are several clearly-identifiable Agile benefits: working in smaller pieces, releasing more often, gathering feedback, estimating better, improving efficiency and meeting all deadlines. It would be great if these always translated into better outcomes.
But a new problem has been born. In most implementations of Agile, companies do not receive the results they were looking for when they accepted a transition to Agile: they gave up command and control, and sometimes all they receive in return are outputs.
- We released 48 points this sprint! It's our best sprint!
- Our average lead time is 5 days - Yay!
- We closed 12 stories this week! Wow!
The problem with these statements is that they only talk about outputs. Outputs, by definition, are what's created at the end of a process. That might be classes taught, hamburgers served or, in our case, the amount of software delivered. Yet measuring outputs doesn't take into account the value or impact of your product or your services. These--the consequences of the work you did--are the outcomes.
The most ignored value of the Agile manifesto is the third: "Customer collaboration over contract negotiation." The first principle is also often neglected: "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." Apparently, another principle received much more attention: "Working software is the primary measure of progress." This last principle might be true for software factories, but most of the time, this is not good enough.
Don't get me wrong. Agile is not bad by any means. It has helped to create unbelievable value. Now, however, Agile is 17 years old, and we can't be limited only to those values and principles that were created in a three-day gathering. As with almost everything, Agile must follow one of its own values: "Respond to change instead of following a plan."
With this in mind, some people are starting to figure out ways to expand and evolve the values and principles recorded in the Agile Manifesto. They are looking for more valuable ways to work with Agile, even beyond software development. The following models were created with this idea in mind.
Modern Agile
"Over the past decade, innovative companies, software industry thought leaders and lean/agile pioneers have discovered simpler, sturdier, more streamlined ways to be agile. These modern approaches share a focus on producing exceptional outcomes and growing an outstanding culture. Today, it makes far more sense to bypass antiquated agility in favor of modern approaches". - Modern Agile
Image from Modern Agile
Modern Agile was created by Joshua Kerievsky to be extremely lightweight. There is no such thing as 4 values extended by 12 principles, and neither are there roles, responsibilities or practices. Instead, Modern Agile is defined by four guiding principles, and these are full of purpose:
- Make people awesome: The idea here is to make everyone in a company's ecosystem awesome. Some companies focus on making the user/customer awesome, but in the long run, if we don't care about everyone related to the company (staff, partners, investors, etc.), we will probably be unsuccessful;
- Make safety a prerequisite: It is not possible to make people awesome if they are not safe. Part of making people safe means not blaming them for mistakes, which happen to everyone. At the same time, part of making businesses safe from suffering the consequences of mistakes is to discuss what happened to ensure they won't happen again. Additionally, it's important to remember that safety extends to how users interact with products, so products should be consciously designed so that users don't make mistakes while interacting with them. For example, instead of asking for a user e-mail and password to log into a product, businesses can offer the possibility of using another account (like Facebook or Google) to log in. This way, users avoid the frustrating "mistake" of typing an incorrect password.
- Experiment and learn rapidly: To make people awesome and to make safety a prerequisite, we must learn as quickly and as safely as possible. Making sure that experiments can fail safely can guarantee that nobody will be afraid to fail. When we are not learning fast, we must run more experiments. What we don't want is to wait a long time to see that something is not working well;
- Deliver value continuously: Instead of focusing on working software as the major sign of success, Modern Agile focuses on delivering value - this way, instead of measuring outputs, we are measuring outcomes. And you don't need to ship an entire product to make sure that you delivered value. If we have anything valuable, we should deliver it right away to make sure that we are helping someone as soon as possible.
Heart of Agile
"Agile has become overly decorated. Let’s scrape away those decorations for a minute, and get back to the center of agile." - Alistair Cockburn
One of the original signatories of the Agile Manifesto, Alistair Cockburn, has tried to refocus on what Agile is all about. And he just focused on four words: Collaborate, Deliver, Reflect and Improve. Those words are known by everyone, but there are different shapes, profiles and ways to live by them. Instead of focusing only on those four words, Cockburn, creator of Heart of Agile, expanded its diagram, admitting that this expansion is just one of countless possibilities. This is his expansion:
Image from Heart of Agile
The idea behind Heart of Agile is to admit that complexities do exist in the real world, but restarting over and over can break these complexities down.
So, would you rather have an Agile process focused on outputs or an Agile product focused on outcomes? Stay tuned for the next article, where we will explain a few strategies to help you stay focused on outcomes instead of outputs.
