Agile's worst enemy is not waterfall - is bad agile. For the past couple of months I’ve had the opportunity of sharing and debating a lot about Agile practices within my organization and others in this sector and also other industries. And this is clear to me: Agile is being mistreated.
Let’s consider for a moment the agile manifesto (http://agilemanifesto.org/). At its heart we can identify two things: forming hypotheses (e.g., what is a feature supposed to accomplish) and collaborating across domains of expertise on experiments. However for the last three years we have been listening to its very authors saying that Agile might as well be dead, e.g.:
“Agile community seems to be largely an arena for consultants and vendors to hawk services and products.” Dave Thomas
Why is that? Because in practice the right side of the manifesto has been valued over its left side, so much that’s becoming not the right side but the BAD side, or as I call it, the dark side (of agile’s force, of course). Ron Jeffries often refers to it as "Dark Agile", or specifically "Dark Scrum". Even well-intended people are being dominated by this dark side!
For example, processes and tools have become the driver of work, not individuals and interactions. In one large Fortune 100 company, the head of digital products says, “we’re not allowed to question the Agile process.” In another example, product managers and engineers communicate exclusively through their tools, which are used primarily for the former to issue commands to the latter.
Similarly, documentation often trumps working software. Or the process becomes the sum of many small waterfalls, which is exactly what Agile was meant to eliminate.
When it comes to “responding to change over following a plan,” this often gets misinterpreted to mean “don’t have a plan.” This leads to teams not even trying to understand the broader strategy or even laying out a roadmap. Without a plan, teams won’t know how to prioritize actions, and how to invest in those actions responsibly, staying on a path of low-value improvements.
Agile, when practiced as described above, reduces the motivation of teams. Because they’re not allowed to experiment, manage their own work, acquire the right competencies, they feel little sense of mastery, autonomy, and purpose; instead they feel emotional and economic pressure to succeed, or inertia. They stop adapting, learning, and putting their best efforts into their work.
In fact, that’s what bad agile is about: no trust environment, not safe to fail, command-and-control structures, tight performance metrics. That’s why you must let your team decide on the how, allow them to experiment and don’t focus solely on your profit. Businesses that focus on profit without valuing purpose will end up with poor customer service and unhappy employees. There’s no point in having a fun room when you have a crappy boss. Or to pay loads when the job sucks or you don’t feel valued, or developed, or even challenged. In the end it’s all about value: to your customers, to your employees, to your shareholders.
What does good agile look like, then?
Good people interacting
1. Requirements and development are a collaborative process. Rather than a process where one person writes requirements (even small ones) while another executes them, all without a guiding strategic north-star, a team striving for true agility should have a way where leaders explain what needs to be done, then stand back and let the people self-organize to do it.
2. The team should not just choose the process that they follow, but they should be actively encouraged to continue to evolve it and change it as they go. Because if you don't take charge and you don't alter things to fit your circumstance, then you are missing the key part of it. To our team for instance, retrospectives play a crucial role in identifying and implementing changes that will help us leap forward.
Good, clean working software
1. There is no one-size-fits-all in software development. Even the agile advocates wouldn't say that agile is necessarily the best thing to use everywhere. However, having a tested, integrated, working, shippable increment of the product at the end of every Sprint is the very best way to avoid fear taking over. Containing all the backlog items we’ve undertaken to do. The more true and real our product increment is, the more it will influence people to look at reality and base their management on it.
Ron Jeffries says: “Contrary to what we often think, our leaders are not stupid. They’re doing the best they can with the information they have. If we can give them better information, in the form of working software, they’ll begin to use that information”
2. So now the software is working but is it doing what the PO and the team agreed? That’s where acceptance tests have their show. When the PO and the developers agree on concrete, executable acceptance tests for each story, it is not done until all the tests run. And when they do, that’s because the team delivered what was asked for. Even if the PO is not happy, that’s not because it wasn’t delivered but maybe because it won’t work as well as they thought and adjustments are needed. And it’s fine because acceptance tests help us all refine our understanding and have the best product in place. Acceptance tests work best when good technical tests are in place (BDD helps a lot here).
3. Incremental design is also very important. We cannot have the design ready when we start, we need to grow the design as we grow the product. And yes, refactoring plays a key role here – when well done.
4. An automated build process is in place, running the system’s test suite as frequently as possible (that’s why it’s called continuous delivery). The more frequent, the better things go. One thing we’ve learnt is that we must run the builds more often when it hurts.
Collaborating with the customer
1. Firstly, the concept of “internal customer” must be eradicated. There is only one kind of customer, the one that buys our products/services and, therefore, contributes to our salaries. When we understand that, we tear down the walls that separate developers from testers, from users, from whoever.
2. Then, as you organize into small teams you think of business capabilities and not systems or platforms. If each small team is focused on some piece of customer experience, some way of making the customer do what they do better, then that tells us how we should draw lines between our small teams. each of those teams needs to connect through to the customer and understand what is happening. There has to be an ongoing conversation between software developers, business people, and anybody involved in making that customer experience better.
Responding to change
1. Even software has to respond quickly to changes, so it must be built in a way that it can change easily. Again, we need techniques like refactoring here, to make sure we change without breaking anything.
2. Secondly, don't add features to the software until you need them because if you do, it bloats the software and makes it harder to understand. But that strategy is totally hopeless without good refactoring techniques. And then refactoring relies on testing, and refactoring also relies on continuous integration as described above.
Let’s empower the teams so they can self-organize. Let’s keep the bar raised in technical excellence. Let’s understand who our customer is and how we make them happier. And let’s be keen on questioning, improving all the time and be quick responders to change. And finally, hold the teams accountable for outcomes (such as growth, profitability, and customer loyalty), not outputs (such as lines of code or number of new products).