Productivity in software development: the lean perspective

In a long tradition of consultants imposing cookie-cutter solutions, McKinsey introduced a framework to measure developer productivity, which has triggered strong reactions in the software community (from Dan North, Kent Beck, or Gergely Orosz).

I am a developer too, and the McKinsey take is giving me the ick. In this article, I introduce three key lean insights that, I hope, can take the debate in a direction where productivity becomes one of several tools to develop exceptional software developers.

Measuring productivity is managing learning curves

Yes, we can measure software development productivity, and it is a simple calculation. The lean definition of team productivity is the number of value units delivered to clients per full-time equivalent (FTE) per day. This does not include developer satisfaction. This does not include a measure of quality—at least not strictly, even though better quality reflects into higher productivity because non-quality is not a delivered value unit. In a lean frame, they are all measured as part of a team’s normal activities. Teams use these measures to check that their work environment is improving, not as a reporting or command-and-control tool.

This cannot be more different from McKinsey’s approach. Their intent is clear: provide top management with clear measures of productivity to make top-level decisions. After all, if we can do it for sales (dollars signed over FTEs) and customer operations (tickets over FTEs), why not do it for development as well? Interestingly, their framework includes measures such as the time spent coding (do we measure “time spent on calls” for sales?), quality of documentation (is “having a clear runbook” a measure of productivity for customer operations?), which not only fails at providing high-level metrics as the aforementioned functions but also will completely alienate developers.

A lean measure of productivity, on the other hand, emphasizes the team’s autonomy: the team self-measures productivity, and regularly discusses what value means for them (the number of fine-grained user stories are a good starting point; story points are not because customers don’t care about how much effort went into coding a user story), continuously improves. They can then check what impact their improvements have on their productivity. Teams then share their knowledge not through best practices (“You will increase your productivity by 15% if you do this and that”), but through learning curves (“We improved our team productivity by 15%, here was our starting point, here is what we’ve tried, here’s what worked and what did not”).

Using measures of productivity like reporting or a tool to intimidate, punish, or reward, will never guide improvement in the long run.

Team productivity, not individual productivity

Lean productivity is about the team, not the individual. This is first because individual productivity has too many confounding factors: mood, skill level, etc. The intent of measuring individual productivity also has roots into the command-and-control management that McKinsey fosters: they want to know where the good and bad apples are. What this actually encourages is a culture of looking good and shooting down everyone else. And this destroys teamwork.

Lean focuses on teams because teams are making the magic happen. In this model, a team leader drives the team to common goals to enhance team cohesion and learning. Senior developers support juniors, engage in code reviews, and contribute to a collective success rather than individual accomplishments. The team invests time in improving their quality through better design, a clearer codebase, mastery over their skills and third-party tools and services.

Some agilists suggest that individuals measure their individual productivity to self-improve. I agree that self-improvement is important and should be encouraged, but a measure of productivity is not a good guide. Instead, self-improvement can start from a more granular challenge (“practice TDD and take a note every time the build or tests have been “red” more than 10 minutes” would be one) with coaching from the team leader. Also the team as a whole should experiment new things, daily, together. Team leaders in the lean sense are the cornerstone of this approach. A lean team leader drives this continuous improvement culture in the team.

A framework for change

The real debate on productivity isn't "How do we measure it?" but "What can managers change, both in their management style and their department’s capabilities, to improve team performance?"

In a lean frame, the role of the manager is to be a coach to the team leaders. A good coach clarifies what they expect from the team and why, develops people themselves in the field, and is there to support their teams. A great coach practices continuous improvement to continue learning. The lean response to managers looking to improve the teams’ performance is no different: to make productivity soar, work on improving product quality and people’s work conditions.

The framework McKinsey proposes to managers in their “Getting Started” section is:

1. Measure everything (DORA, SPACE, lead time, developer index, time spent coding)
2. Build a plan, “starting with one area that you know will result in a clear path of improvement”
3. ?
4. Success
   

McKinsey assumes that if the good robot-employees follow the plan, everything will eventually improve. In this perspective, the process is seen as the solution, while people are viewed as the problem.

In the lean approach, the perspective is reversed: the process is consistently viewed as the area needing improvement, while people are seen as the key to solutions. This means placing trust in individuals and teams to enhance the process and giving them the means to do so. Practically, this means providing them with the space and support to assess their own productivity, encouraging them to periodically step back from daily deliverables to suggest new process improvements, evaluating the effects on productivity, and iteratively refining the process by resolving one problem at a time. A lean (engineering) manager’s approach is then:

1. Go and see teams, encourage people to solve small problems and look for new ways of doing the work. This creates a collective hands-on experience on what value is and improves psychological safety.
2. Develop a learning culture at the team level with team leaders by having them display on the wall (physical or virtual) their daily performance (quality, productivity, safety) and problem-solving exercises (one problem per day).
3. Visit teams regularly, listen to their problems, help remove roadblocks, and say thank you.
4. Encourage teams to try new things in their environment—and come up with their own plans and initiatives.
5. Improve the main enablers within your department, to eliminate the persistent problems faced by teams
6. Repeat

This mentoring system goes all the way up to the CEO of the company. Companies that function this way report higher levels of customer satisfaction, employee satisfaction, and return on assets (i.e. the ratio of money the company makes over its assets) as evidenced in books such as The Lean Strategy and Raise The Bar.

Conclusion

The problem with productivity is not measuring it, but why we measure it in the first place. When we decide to measure something, it is because we have recognized a gap of knowledge we need to fill to improve our chances of making the business numbers. Halve the bad, double the good, the lean mantra goes. Reduce the number of bugs by half, reduce the delivery lead time by half, double the number of zero bug features, double the number of experts in the team, double the positive customer feedback, and so on. Productivity only measures how fast and efficient we are at learning and improving to reach those ambitious goals.