Agile Speeds Delivery Of Value Not Code
In the agile community we love fast. Fast feedback, fast delivery. Fast is good. Slow is bad. Why then is the most common complaint I get about agile - "All this team stuff distracts me from writing code. We can't deliver fast if I can't write code". That's a good point. We are taking our devs away from coding to some extent. In an agile team they can’t just sit down in a corner with their headphones on and just cut code solidly for a week. There's a lot of team interaction that has to go on to make the team run smoothly.
So are we, by doing agile, slowing down delivery of code? Quite possibly yes. But what about fast delivery? How can we say we are about delivering fast but slow down the people who are actually delivering the code? The thing is, we don't actually deliver code. If we just delivered code we would go out of business. What we deliver is working, tested, fit for purpose code. More fundamentally than that, what we deliver is business value, not code. Agile is all about speeding the delivery of value, not the delivery of code.
This is a classic example of global vs local optimisation. The aim here is to globally optimise the delivery of value, not locally optimise the delivery of code. A locally optimised system will almost never be optimised at the global level. Waterfall is a system built around local optimisation - designers sit down and design in isolation with no interruptions, then coders code as efficiently as they can, then testers test. Everyone is locally very efficient but the process as a whole delivers value very inefficiently.
Looked at globally, there is a huge amount of inefficient work done in a waterfall project. I don't think I ever worked on a waterfall project where the carefully designed designs didn't need major re-work mid project due to issues discovered during coding. And there has definitely never, ever been a waterfall project where code didn't need to be reworked due to issues found in testing. Even during development, integration issues are a major cause for project delay - individual coders working in isolation (locally optimising) produce code that doesn't work with the code written by other locally optimised coders.
Even the re-work is done in a locally optimised way - the designers will go back into isolation and re-design. The coders will go back into isolation and re-code. They feel nice and efficient because they can focus on getting "their" work done but in reality they are creating more of the same problems. Everything is done in a locally optimised way, so every individual feels nice and productive, but the system as a whole suffers.
Agile takes a different view. Designers don't produce designs. Coders don't produce code. Testers don't produce tests. The team produces value. The focus is on delivery of value not on individual components. A design is worthless unless it is expressed in code. Code is worthless unless it has been tested and so on. What counts is the combined results of the whole team's effort. What we need is global, not local optimisation.
To globally optimise we will almost certainly make individual steps within the process less efficient. Yes, coders will have to stop coding and talk to stakeholders, they will have to attend standups and refinement sessions and planning sessions and reviews and retros. Yes that will make them less efficient at sitting down and cranking out code.
We will also de-optimise the testers. Yes, they will have to run the same tests over and over as the code changes. Yes, they will have to attend all the agile ceremonies. Yes, this isn’t efficient for them. Far better for them to just test once at the end, but by doing that we hurt the coder’s ability to write solid code. Likewise the designers, and the architects and everyone else on the team. They will all take a hit in personal productivity.
Personal productivity isn’t the point. Individuals don’t deliver value, teams do. By de-optimising people’s personal productivity, what we get is a team optimised around delivering value. If you look at a football team, you will notice that the defenders don’t score many goals. Their personal goal scoring productivity would increase if they grabbed the ball and charged towards the goal with it (have a look at a video of an under 6 soccer match if you want to know what that really looks like), but the team wouldn't win many matches that way.
What we want are winning teams, not efficient individuals. Sometimes we have to sacrifice personal productivity for the good of the overall team goal. Our overall team goal is to deliver value. We win if we deliver value. Keep focused on the bigger picture. Help the team to win.
The same applies at higher levels of scaling as well. If you have many teams, you may well end up slowing down the individual teams in order to produce value at the project or program or portfolio level. When we scale it's no longer about the output of the individual teams, it's about the output of the system as a whole. The output of the individual teams don't matter if they don't fit with the output of all the other teams.
Focus on the big picture. Optimise for the overall goal.