I originally published this blog on Medium and reposting it here again. You can read the original post here.

Introduction

When I saw the book “Art of doing twice the work in the half time,” Dr. Jeff Sutherland wrote, my reaction was like how someone can claim that? What will be an effective measure to have such a comparison? I went through the book and loved it. It is not only because the book is good, but I felt connected with one of the case studies. I know that project as I have worked on an extended version of the same project called SAR. His book is available on many of CXO’s desks, and it seems many companies wish to gain the same level of productivity. Is productivity means the amount of work getting completed within a specific timeframe? Can we get individual productivity up by teaching them how to work efficiently? Or we have to look at how to remove constraints, provide them better resources, and guide them about what meaningful work is so they can perform well. I have listed the top 5 reasons that don’t allow the team to gain such productivity but feel free to suggest more.

Saying YES to everything

Check with your product owner how she brings simplicity by maximizing the amount of work not done? It is essential. Correct? It is not about producing features faster, but choosing what makes more sense for my customers. Scrum doesn’t help complete the product faster, rather than how quickly a team can release a product. The release is not necessarily required to have all the features that the business has envisioned. I worked as a product owner for my first product in 2007–08 to manage the insurance lifecycle for a major insurance company in America. Still remember the kind of pressure I had to deal with to accommodate requirements from various sources. We managed to deliver our first release to the customer in just over two months. Still, We had to say NO to too many things, and the discussion was simple like why we need renewal and reinstate features now when these are required only at the first cycle of the insurance term. I know how difficult it is to say NO, but it is easy to say NOT as of now 🙂

Old habit but the new game

Good news for the startup; this doesn’t apply to you. If you are an old establishment, bad news for you, you have to invest a lot to be like a startup. I have been coaching mostly in large organizations that have been in existence for a long. Longer presence means more complex organization design. It is not always right, and especially if an organization has been refactoring and facilitating continuous change. Traditionally, Staff organizes around expertise areas, and supervisors have been managing their work. Self-organization is hard to imagine for many, and struggled to visualize how they could operate without supervisors. Collective ownership and end-to-end delivery accountability are still beyond imagination. They got training on Scrum, understood concepts, and formed teams, but struggle to commit. They got the idea of increasing the complexity of dependency management and longer lead time due to the handoffs having individual accountability.

It is a fight to let go of old habits and adopt new, but teams need support to facilitate this change. Ideally, scrum masters and the management team could do that, but challenges come when Scrum Masters struggle. I have been promoting the coach-the-coach program for a long time to supports the management team to help in adopting a better version of Scrum to develop products.

Measuring resource utilization

Do you measure the velocity of the team?

Do you calculate how long a person was busy doing something?

Do you measure estimated time for a task vs. actual time spent?

Or measuring things like defects per story, defect removal efficiency and code coverage, etc.

It is not that the above is harmful as long it is used for the right purposes like velocity for forecasting and code coverage for quality of code.

But it makes more sense to measure time to market, customer satisfaction, NPS, usages index, response time, and innovation rate. If you were releasing once a year and now releasing every quarter, you have already improved by 400%, but would you like to stick here? Look at how much time your team takes from development to deployment in production? I have experienced where teams could complete a significant amount of stories within the sprint, but the time taken to move in production was very high. Many things were not part of a sprint like security testing, performance testing, regulatory requirement, and deployment. Measuring those and fixing them will help in improving time to market for sure.

Bad technical practices

We wanted people to reach faster by driving faster. We taught them how to drive, manage traffic well, and put instructions everywhere, but people are still not going above 40 KM an hour. Although it has improved the overall time as there are fewer troubles while driving. When checked, people complained about 20 years old car that they have been driving. We have a similar story to our team. The team is autonomous self-organized, has Scrum master to clear impediments, Scrum values are everywhere on the wall, and management is there to help them organized but still doesn’t have significant improvement. When looked closely, we found out that continuous integration is missing, no build automation, and pair programming and mob programming are complete NO. Teams haven’t heard about Behavior-Driven Development (BDD), Test-Driven Development (TDD), and emergent design. We still have Requirement->Design->Development->Testing->Deploy/Release cycle and heavily guarded through CAB (change approval board). Adopting Extreme Programming Practices, separating release from deployment, and embracing modern software engineering practices will speed up team performance. Just processes will not improve speed on the road, and we also need a better car with a newer engine.

Complete harmony at work

It is a culture in many organizations where I will not say anything about others, so others should not say anything about me. I can check how dull your retrospective is, why people avoid daily Scrum, and how unproductive sprint planning is in your team. I will not write more about it as it is a sensitive topic, and I will leave it for you to guess and find a solution.

What Can I do?

Nothing besides showing you a mirror through teaching and coaching a better version of Scrum, but you still have to fix problems and not me.