BeanStalk

Everybody is interested in improving productivity. It’s in the title of the book from one of the creators of Scrum – boost your productivity by a factor of 4!

productivity

Yet, when I reflect on the work I’ve done helping organizations in their Agile transformations, I realize I’ve had a somewhat conflicted relationship with the topic of productivity. Of course, I see the importance in being productive and reducing waste. The benefits are clear. However, when I reflect on my experience with teams and tribes at the start of transformations, I started recognizing a pattern – focusing on productivity early on slows down the actual progress of the transformation.

First of all, what is productivity?

First of all, what is productivity? When I talk about productivity, I’m referring to a team’s ability to deliver output given a specific input. Essentially, productivity can be improved by one of two means:

  • increase the rate of output given the same input (example: a stable, 100% dedicated Scrum team improves and can now deliver more “stuff” at the end of each Sprint)
  • decrease the amount of input and keep delivering the same amount of “stuff” (example: a Scrum team that has implemented improvements and is able to reduce their team size while maintaining a constant output)

Yes, I’m using the word “stuff” on purpose. I think this is important for this conversation. When I talk about productivity, I am not talking about the team’s ability to deliver actual business value (outcome). I’m only interested here in the team’s ability to deliver output.

With this in mind, let me explain why I was struggling with the topic of productivity in my coaching work early on. While I was helping organizations experiment and introduce Agile ways of working for some of their products or services, invariably the question would come from leadership, “is Agile making us more productive?”. It was a valid question, of course, and it triggered discussions about how we could measure this. I remember that in many of those discussions I was advocating caution. Why? Change is already difficult. If on top of that leadership is focused on productivity, then people’s willingness to learn, experiment, and adapt decreases. My job became harder and the improvements we achieved in the end were smaller.

I was confident that caution was the right advice regarding productivity in those cases. But I was also aware that I wasn’t addressing their question fully. If productivity is so important, why not just focus on improving it from the start?

Later on, I started noticing a lot of similarities between growing winning sports teams and kicking-off Agile transformations. And that metaphor helped me articulate more clearly the reasoning behind my resistance to the productivity discussion in organizations with a low level of Agile maturity. So let’s think about what it takes to learn a new sport and be good at it.


What does it take to learn a new sport?

Basketball was my sport when I was growing up in Brazil, and when I was eleven I decided to join the team in my school. We were pretty bad, so basically showing up to practice was all it took to join the team. I had always played with friends in the playground, but had no real technique or understanding of the game. In the first practice, the coach spent the first 30 minutes teaching us how to pass the ball. A little theory, and then a lot of practice. The next 30 minutes were dribbling. A little theory, and a lot of practice. We never shot the ball in the basket. When we complained, “Come on coach, this isn’t fair! When are we going to practice shooting?”, he just laughed and said, “Guys, don’t worry. If we can’t pass or dribble the ball, we’re never going to find ourselves with an opportunity to take a shot. See you tomorrow.”

productivity

A couple of guys quit the team during those first 2 weeks. They just wanted to shoot the ball. The rest of us learned how to play basketball. And some of us, like me, grew to love the game. A couple of years later my coach at school recommended I join a club since I was enjoying it so much, and there we practiced every day. I spent countless hours doing a lot of silly looking individual exercises, such as laying down on the floor to practice shooting the ball with one hand – it has to go straight up and back down on your one hand. Do that for 5 minutes and then switch hands. Focus on your form. Take 200 jump shots a day to develop muscle memory. Practice with the same guys, week in, week out, until you start to understand their individual preferences and anticipate their moves. And then, before you know it, you’re a basketball player playing in a basketball team. No, I didn’t make it to the NBA, but I was playing competitive club basketball throughout my high school years.

And it was then, when I had fallen in love with the game and was part of a team that I trusted that I also began to understand how to look at my productivity numbers (rebounds, shooting %, turnovers, assists, blocked shots, etc.). I had enough basketball maturity to start to understand what those numbers meant in the bigger picture. It’s not only about scoring points. Somebody has to grab the rebound, somebody has to set up a play, somebody else has to set the right screen, and still somebody else has to make a good pass before the last player in the chain gets the chance to score. And all of that has to happen in harmony.

Some of my best games were not particularly impressive on the stat sheet. We had learned as a team to adapt to the opportunities presented by different opponents, and sometimes this meant sacrificing your individual productivity. Why? Because we understood the game and what value meant. That’s why the team sports metaphor is helpful here, because in sports, value is easy to understand – it’s wins. You either won the game or you lost it. You either won the championship or you didn’t. There are no trophies for style, efficiency, or complexity. And once we understood the different tools we had available to win games, it was easy for us to prioritize wins over individual and team productivity (value > productivity).

If I (and my teammates) had from the beginning focused on our shooting % instead of our shooting form, on our assist totals instead of our passing techniques, our individual productivity instead of our greater impact on the team and the game, we would have never become a winning team. Instead, our coach made us focus first on understanding the game, its intricacies, and the beauty of the “games within the game”. He built us up as a team of passionate players who genuinely enjoyed the game and trusted each others’ abilities. Then we were ready to start talking about productivity and commitment in a meaningful way.

The fact that we did end up winning the state championship was the consequence of those habits and that passion.

So what does this mean for organizations?

Concretely, organizations approaching the productivity discussion in the early stages of a transformation, will likely focus on measuring the Scrum team in isolation to try to establish productivity benchmarks. They will focus on the output the team can produce, with no real understanding of lead time, dependencies, and technical debt. The value stream takes a back seat to the teams, because the assumption is that if the individual teams can deliver more output, the value stream will logically benefit.

The problem with this approach is that continuous improvement is a long-term game. The return-on-investment for most improvement areas usually takes a bit longer to materialize. Think about code bases that need refactoring, the knowledge that needs to be shared, standards that need to be aligned, or teams that need to learn how to collaborate to deliver real value – none of these improvements make sense if you’re only looking 2-4 weeks ahead. They make sense if you’re looking 6-18 months ahead. So, forcing the productivity discussion early on in a transformation, means that teams will be spending less time on those improvement activities that don’t generate immediate benefit. Or at least it will take a lot of courage to do so. Safer to deliver as much “stuff” as possible to keep those productivity metrics up.

This is not how you build a winning team.

Just like when learning a new sport, you need to learn the basics first, before you can even start thinking about productivity. If you’re not willing to re-learn your entire shooting mechanics and instead try to just tweak your existing poor one, your potential will always be limited by that lack of fundamentals. “You have to be bad before you’re good,” is something I remember our coach telling us back when I was eleven. “Don’t worry about hitting your shot, worry about keeping your elbow in and having your middle and index fingers be the last fingers that touch the ball before it leaves your hand. Make sure you’re getting a good backspin on the ball and enough of an arc to give it a chance. You’re going to miss badly at first, don’t worry, just focus on doing those things well and under control.”

Similarly with organizations, they should first learn things such as how to be customer-centric, collaborate as a product team, reduce lead time, simplify their org design, and implement the changes necessary to do real iterative & incremental development (iterative is easy, it’s the incremental part that takes a while…). And what I’ve learned with experience is that yes, after we reach that maturity, let’s have a real discussion about how we measure productivity and how we will use that data. We need some numbers to help us make deeper reflections on how to improve. And at that point, we’re ready to approach it with the correct mindset, and will be able to unlock even higher levels of productivity.

Therefore, avoid the anti-pattern, trust the process, and be patient. First learn how to walk properly, then try to see how fast you can run.

Remember, you have to be bad, before you’re good.

If you want to learn more about Agile and how to improve your team or organization, contact us and talk to an Agile coach.