I originally published this blog on Medium and am reposting it here. You can read the original post here.
When I saw the book “Art of Doing Twice the Work in Half the Time,” written by Dr. Jeff Sutherland, my reaction was, How can someone claim that? What will be an effective measure to have such a comparison? I went through the book and loved it. It is not just because the book is good; I also felt a connection to 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. Does productivity mean the amount of work completed within a specific timeframe? Can we get individual productivity up by teaching them how to work efficiently? Alternatively, we need to consider how to remove constraints, provide them with better resources, and guide them on what constitutes meaningful work, enabling them to perform well. I have listed the top 5 reasons that prevent the team from achieving 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 rather about choosing what makes the most sense for my customers. Scrum doesn’t help complete the product faster, but rather how quickly a team can release a product. The release does not necessarily need to include all the features the business has envisioned. I worked as a product owner for my first product in 2007–08, managing 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 reinstating 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, you have some bad news: you'll need to invest a lot to compete with startups. I have been mainly coaching in large organizations that have been in existence for a long time. A longer presence means a more complex organization design. It is not always right, especially for organizations that have been refactoring and facilitating continuous change. Traditionally, Staff are organized around expertise areas, and supervisors have been managing their work. Self-organization is hard to imagine for many, and they struggle to visualize how they could operate without supervisors. Collective ownership and end-to-end delivery accountability are still beyond imagination. They received training on Scrum, grasped the concepts, and formed teams, but struggled 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 ones, but teams need support to facilitate this change. Ideally, Scrum Masters and the management team could handle this, but challenges arise when Scrum Masters struggle. I have been promoting the coach-the-coach program for a long time to support 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 the estimated time for a task vs. the 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 as 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, usage 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 seen teams complete a significant number of stories within a sprint, but the time spent transitioning to production was very high. Many things were not part of a sprint, like security testing, performance testing, regulatory requirements, and deployment. Measuring and fixing those issues will definitely help improve time to market.
Bad technical practices
We wanted people to reach faster by driving faster. We taught them how to drive and manage traffic effectively, and we've put instructions everywhere, but people are still not going above 40 KM an hour. However, it has improved the overall time, as there are fewer troubles while driving. Upon inspection, people complained about a 20-year-old car that they have been driving. We have a similar story to our team. The team is autonomous and self-organized, with a Scrum master to clear impediments. Scrum values are displayed prominently on the wall. Management is available to assist with organization, yet the team still hasn’t achieved significant improvement. Upon closer inspection, we discovered that continuous integration is absent, along with no build automation. Additionally, pair programming and mob programming are not in place. Furthermore, teams are unfamiliar with concepts such as Behavior-Driven Development (BDD), Test-Driven Development (TDD), and emergent design. We still have a Requirement->Design->Development->Testing->Deploy/Release cycle and are 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
In many organizations, there is a culture where I refrain from speaking about others, and I expect the same from them. I can assess the dullness of your retrospective, understand why people avoid daily Scrum, and evaluate the unproductivity of sprint planning within 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.