System optimization: Upgrading Team Competencies
When developing complex innovative products, the Development Team will have different a workload for each one of their members. The speed of the entire Development Team is often limited by the speed of the specialist with peak loads. To overcome this problem, employees need to expand their competencies and help each other. In this case, it will be possible to switch from local to system optimization.
Narrow specialists — unoptimized system
Meet a Development Team in which John, Nick and Mike are working. They are narrow specialists. Nick works with the green technology only. John specializes in blue technology, and Mike – in yellow technology. The Development Team is cross-functional because it has all the necessary skills to develop an Increment.
The Development Team gets features from the Product Owner. Most of them require all three technologies: green, blue and yellow. Imagine the Development Team pulled three features during the Sprint Planning, and here’s a shot of their Scrum Board somewhere in the middle of the Sprint:
John and Nick are still working on the first feature, because there is lots of work to do on the green and blue technologies. Mike has finished working on his part of the work in the first and second features and now has started the third one. What is he going to do next when it’s done? Most likely, he will ask the Product Owner if he can pull the next feature from the Product Backlog and work on it. The result of the Sprint is a large amount of unfinished work in progress (WIP), and only one feature is Done during the Sprint.
Many Scrum Teams work the same way. The number of completed features in the Sprint is determined by the developer with the peak workload. In our example Sprint, this is John.
Note that in the example above, all the developers worked, as they thought, very efficiently, and diligently exploited their competencies. But the whole system was sub-optimized - and only one feature is Done.
Expanding competencies make the whole system more effective.
Imagine that our guys have upgraded their skills and the matrix of competences now looks better:
Let's make a thought experiment and see if the Development Team became more effective. For the simplicity let's assume they got the same features again.
Nick could help John who would have had the peak load with the blue technology. The team would have been able to complete two business tasks instead of one. Paul would have been ahead anyway, but he would have been now working on the green and yellow parts of the last task, waiting for help from the two other guys working on the blue part.
The result of the Sprint is that two features are Done and the workload is distributed more evenly between Development Team members.
It is important that we have not added any new "resources" to the team, because it would have increased the cost of the team and the number communication channels. We’ve just started to use existing resources more effectively. When developing complex products, system optimization is closely related to the need for learning. Team learning is a continuous activity in Scrum and in learning organizations.
Team learning is vital because teams, not individuals, are the fundamental learning unit in modern organizations. This is where the rubber meets the road; unless teams can learn, the organization cannot learn (Senge, Peter M.. The Fifth Discipline).
We are forced not to learn
We have been raised in the paradigm of classical management which assumes that people should maximally exploit their current expertise. Just have a look at any service dedicated to job searching and you will find a lot of vacancies like: Senior Java Developer, Middle .NET developer and so on.
For decades, we have been building functional fragmented companies in which people were destined to become soulless cogs that need to be lubricated from time to time. You have to put them into the necessary place of the organizational mechanism. You can also discard them at anytime. As a result, in large organizations, employees often do not want to learn. They resist attempts to expand their competencies and even consider it a waste of time.
The industrial paradigm makes us so focused on using our present skills that we forget we can learn something else. You need to create conditions in your organization which will make people want to get new knowledge.
Our prevailing system of management has destroyed our people. People are born with intrinsic motivation, self-respect, dignity, curiosity to learn, joy in learning. (Senge, Peter M.. The Fifth Discipline).
How to help people to learn
If you want the Development Team to learn and become more flexible and responsive, you need to create certain conditions for learning and change the system. People stop actively learning and mastering new skills for a reason. It is necessary to change the structure to activate people's desire to grasp knowledge again.
Helps learning
- Product paradigm, focus on long-term goals
- Co-located teams
- The team is 100% dedicated and works on one product
- Stable team
- All-at-once management (ROI, Сycle Time)
- The Development Team is loyal to the Product Owner and works on one product
- Developers get a salary increase when they upgrade their competencies (T-shaped people)
- Cross-functional cross-component teams
Impedes learning
- Project paradigm, focus on short-term goals
- Distributed teams
- Team members assigned to several projects
- Resource pool: after the end of the project, people are distributed between new projects
- Focus on individual productivity (number of closed tasks, man-hours), which stimulates people to exploit their current expertise
- The Development Team has functional managers influencing their career paths
- Developers get a salary increase when they become more skillful in their major competency
- Component teams
I want to draw more conclusions. Let's say you have a few narrow specialists on your team and you understand that the Team could be more effective.
First, it’s a long-term investment. You will need a lot of patience. I start with me drawing the team's attention to the fact that narrow specialization make them less flexible.
Secondly, we often inspect and adapt a competency matrix.
Third, almost all the teams I have worked with start using Kanban sooner or later. It is a great tool that can be used within a Sprint. Kanban limits the amount of unfinished work, makes queues painfully visible and encourages employees to help each other.
Key thoughts of this article:
-
Pay attention to the system optimization.
-
When creating complex products the team needs to learn.
-
Learning is a part of the work in Scrum.
-
There are a number of system factors that can drive or impede learning.
Scrum ON!