This is an excerpt from the book Scrum Your Jira: Your Waterfall Organization Transformed into Multidisciplinary Teams.
A common argument in favor of Scrum is that, once established, the process will produce numbers for business to use in calculations and planning. This is true, and this is the goal: a well-run Scrum process can give you excellent feedback about the “health” of your organization as well as the progress of your projects. But, especially with automated tools like Jira in the background, you can lose perspective. Here, I want to explain statistical, mathematical, and process-related connections to give you reasons for many of the ideas implemented in Scrum.
I remember a question from my math classes: if five workers build a house in 30 days, how many days do 10 workers need? From a project management point of view, this question is of course laughable, as the answer would probably be 30 days because of all the phases involved. Maybe the critical path is 30 days, no matter how many people you throw at the project. From an Agile point of view, the question is very different. Here, it is not about managing cost, quality, or time to fulfill a pre-planned project. Instead, it is about the generated business value per time unit.
The workers could start with the garage so that the family moving into the house could park their car. Maybe they could set up the a mailbox so the family could move their postal address. Maybe they could start by planting the grass early so that when the family moves in, the garden already looks pretty and won’t need another month to grow.
Let’s say we have a test team and a development team of five people each. Both teams follow every piece of advice inherent in Scrum, except for the fact that they are two teams working on the same thing. When the development team completes a sprint, it delivers the product to the test team for QA. Let us further suppose developing and testing both take the same amount of time on average, and that one sprint takes one week.
Upper management then assumes that they have a product ready every two weeks. Compared to what they had before, namely no numbers or release cycle, this system is celebrated as a success. Everyone pats each other on the back.
At the end of the year, the actual numbers are compared with prior year’s numbers (without any “controlling,” as they had numbers only at the end of each year). Then management will find that the situation has not improved by much. Likewise, nobody wants to lose face and they just continue as it is and find excuses. It might be said that it was a bad year, it is difficult to find talented people, the lead programmer has quit (but why?), people got sick a lot (but why?), etc., and management leaves things as they are. New Scrum Master hirees are told that the company uses its own version of Scrum and that their proposals to change the process rock the boat too much.
“Agile.”
What happened?
Imagine you have an empty bottle and a full bottle. How do you fill the empty bottle with the water from the full bottle without making a mess? Of course, you use a funnel! But what is a funnel actually? It is a buffer with a limited capacity that ensures a steady flow of water into the other bottle. Having phases with specialized teams is just that: trying to pour water from one into the other, making a huge mess. And there is no funnel to fix that, except to pour so slowly and steadily that no air bubble can form.
What is the “air bubble” in the case of project management? When the first team works faster than the second, work piles up at the second team. When the second team works faster than the first, the second will be idle.
What to do about it? Do you smooth things out by having individual features drop from one team to the next? That helps, but slows things down, and work could still pile up. Do you send your testers to the developers to help out or have developers start testing? You can’t do that, can you? Imagine your top software architect using her time for testing the UI. Or imagine an inexperienced tester taking four times as long as your average programmer to fix a bug in the code. Is there no way but to make a big mess?
What is missing in this evaluation is the business value of things—that is, the value, over time using the product, that the consumer gets. That is a much better indicator of evaluating someone’s work than individual speed or efficiency. It doesn’t matter if one part of the whole business works four times faster than the rest; the only thing that matters is how early the final product (or feature) can be used by the customer. So, instead of focusing on local optimization, look at the global picture. No business value is created as long as no customer can use your feature. The goal should be to get one feature through your complete pipeline as quickly as possible, even if that means that some of your resources are under-utilized and not working at 100 percent efficiency.
Scrum solves this by building multidisciplinary teams. But even when you merge two teams (or create two feature teams), you usually end up with each person working on one story, doing everything including programming, writing tests, releasing, etc. While you certainly have solved the problem of idleness of teams—one person is 100 percent involved in the whole chain of production—each story still takes a long time to be developed. In addition, there is little communication between the team members; knowledge management, additional testing (simply by having additional people looking at the work), and additional ideas are excluded.
So, are we back at square one with Agile? Let us first draw an example situation into a graph. The challenge is bringing high-value tasks quickly to market (but is that really the challenge in your company…another question to ask yourself!). Figure 7.1 shows the accumulated business value of three features if worked on independently by three people, and the accumulated business value of the three features if implemented one after the other by the whole team (first with 75 percent productivity, then with 33 percent productivity). As you can see, if the productivity is still high enough despite the necessary overhead, focusing on finishing individual tasks as a team as fast as possible ultimately shows higher business value returns on top of advantages like team building and knowledge sharing!
To summarize, throw the whole team on a task, even if their “productivity” (completed tasks per day) suffers. If it speeds up the delivery of that single crucial feature, you might ultimately end up with higher productivity. Obviously, some calculations are required. But it is important to unlearn the idea of putting individual people on individual tasks simply because they are the ones who can implement them most quickly individually. And we have not even taken into account the internal value of knowledge sharing, more testing, and ultimately higher quality!
Speaking of throwing people on a task: if your team is involved enough in business (a multidisciplinary team involved from design to sales), the team will understand the value of a multidisciplinary team. If it does not, you have another indication that the team is disconnected from the product as a whole, doing local optimizations on their own work without having the larger picture in mind.
How does your team share work among themselves? Do you have specialists, like a “super-programmer”? What is their approach to work optimization?
