BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Don't Optimize Team-level Performance

Don't Optimize Team-level Performance

This item in japanese

Klaus Leopold gave a talk at the GOTO Berlin 2015 conference in which he elaborated why focusing on team-level performance often leads to local suboptimization and doesn’t increase agility across the team. InfoQ interviewed him about why installing agile frameworks does not help to increase agility, how kanban can be used to increase collaboration, and the benefits that teams can get from kanban.

InfoQ: I hear more and more teams that are adopting kanban to work in an agile way. Can you give some examples of how teams that you have worked with are using kanban?

Leopold: I work with Kanban in many different areas. From classic hardware development to marketing, controlling, human resource departments and agencies, there is virtually no field that I have not come across. I know companies running the recruitment processes with Kanban or in the automotive industry where companies are running the development process with Kanban or even the reclamation process with multiple factories involved. Software development is of course one of the areas, however, it only makes up 30% of my work at the moment. In every environment it is always about better understanding one’s own work context and implementing improvements based on this understanding in order to increase customer satisfaction.

InfoQ: What are the benefits that teams are getting from using kanban?

Leopold: In the beginning a lot of teams are seeking visibility. "Seeing what’s going on" is probably the goal that I hear most often when it comes to starting Kanban. However, I think visibility is not a goal. Visibility is a means to an end when it comes to understanding your work system. And I think that’s the greatest benefit one achieves by working the Kanban way. In its very root, Kanban simply means understanding what’s going on and performing the right improvements based on this understanding. That sounds perhaps quite easy but believe me it’s totally not because knowledge work is not really intuitive. Some examples: Work is finished faster when we are not working all the time. We don’t serve our customers well when we start their work immediately. Working faster has nothing to do with finishing work faster. Starting work earlier leads to finishing work later, etc. This is by no means intuitive, however, understanding these aspects of work systems is essential when it comes to improving. The point is you need to know what levers to pull in order to optimize for your business or your customers, respectively. If you are aiming for a system with high due date performance you will take different actions and design different systems than when it comes to optimizing time to market.

InfoQ: What if we have multiple teams, or larger organizations with hundreds of people involved? Can agile frameworks help us organize the work, or do we need something else?

Leopold: I’m not a big fan of "installing" frameworks, no matter whether they are Agile, Lean or any other currently fashionable flavor. One thing is clear, if you want to survive in today’s business reality, agility is highly important. And another thing is also crystal clear: installing a method or framework won’t give you the desired agility. Let me tell you why.

What does agility mean? For me, agility means that a company adapts to the constantly changing world or is even the one step ahead that is needed to become a thematic leader and to innovate. The most important prerequisite for this is that companies constantly change and improve. If you install frameworks, the central idea is to copy random practices. Continuous change and agility, however, cannot be reached by copying practices. The opposite is true; in many cases frameworks hinder continuous improvement because their installation is viewed as the achievement of a target state: As prescribed by the framework, the organization is restructured, the employees are trained for the new way of working and they execute the new processes and practices. Done! No, this is completely wrong! You are never done, if the true goal is continuous change or agility, respectively.

InfoQ: Can you elaborate on how you can use kanban to understand how teams are working together in larger organizations, and look for ways to improve collaboration?

Leopold: I believe the most important point is that Kanban does not focus on organizational structures such as for example teams, departments, etc. Kanban puts the services of a company and thus the generation of value into the focus of attention and wants to improve upon them. So, the first question is: "How can a value be generated for the customer?" Once you have the answer to this question, you can focus on the second question: "Who do we need for this?" So, the approach is not to implement Kanban within 100 teams of a company and then ask the question: "how can these teams now work together?" You start with the service or the generation of value, respectively. If you need multiple teams to ensure this value generation of the services, then the answer is not to implement Kanban at a team level but rather across teams. And I believe that this is the great thing about Kanban: there are absolutely no limits to scaling Kanban. This means a team with 3 people can improve using Kanban but also organizations with hundreds of people. The only thing you need is to do real Kanban.

InfoQ: In the InfoQ article can you scale kanban you gave an example of how you can use kanban to manage work in progress across the full delivery cycle. Can you explain how kanban helped to optimize the whole thing and prevent sub optimization?

Leopold: Sub optimization for me means that only a part of a system is optimized without taking the entire system into consideration. If we are not talking about a company with just 10 employees then it is almost certain that several teams will be needed to develop a product or to fulfill a service. For example, in software development multiple teams might be needed to develop a product. If, in this constellation, only individual teams of a service are "optimized" or agilized instead of the entire service then you should not be surprised if the overall performance does not move an inch – even despite being agile and costing a lot. Let me give you one example: I once worked with a company which introduced Scrum with their software development teams. They were really successful – they managed to increase throughput and lowered lead times for their product features. After the team finished development they through the work over the fence to the staff training team who’s job it was to train employees who were working with the application in shops. As development increased their performance, the staff training team could not keep up with the pace and as a consequence the training quality dropped. The shop staff used the software to consult end customers in their buying process. However, as the shop staff wasn’t trained properly with the latest offers and promotions they couldn’t serve the customer well which led to an increase in customer complaints which in the end costed a lot of money. The development teams did a really great job, however this "agilization" was one big sub optimization because the end customer was unhappy in the end. We then introduced Kanban on Flight Level 3 where we optimized the entire value chain, starting from the product owners over software development until the shop staff. The result was a joint improvement journey of all parties that are needed to make the end customer happy. The point is not to agilize or improve organizational structures like teams – improve value creation!

If Kanban is understood and done right, these effects do not happen because, as described in the previous question, the services of a company and the generation of value are in the focus of attention and not individual, isolated parts of an entire system.

At this point it is important to mention one thing: It is of course possible to start Kanban locally. If the system is modeled correctly, then the sub optimization will be quickly discovered and the untapped potential can be quantified economically. This is often the starting point for the initial discussions which often result in scaling – economic arguments are quite persuasive.

Rate this Article

Adoption
Style

BT