Some days ago I have been at Norwegian Development Conference in Oslo city (http://www.ndcoslo.com/). There were a couple of very good sessions about Scrum. I talked to people after those sessions, talked to Scrum Masters, developers, product owners about they experiences with Scrum. I figured out some typical mistakes that Scrum teams make. All these mistakes have actually the same root: Scrum practitioners forget about the reasons why we do Scrum.
The reason why Scrum invented in Toyota is to implement some principle of Toyota Production System.
Mistake 1. Lack of Kaizen
Kaizen 改善 is a Japanese word means “continues improvement”. It is a fundamental principle of Toyota Production System. Kaizen methodology includes making changes and monitoring results, then adjusting.
Scrum has 5 ceremonies: sprint planning, sprint review, sprint retrospective, daily scrum meeting and backlog refinement meeting. At least 2 of these ceremonies: sprint retrospective and daily scrum must be focused on continues improvement of production process. If team and Scrum Master does not do this, they miss a chance to be become better. They actually lose the main point of Scrum – agility.
Scrum Master must think about how to make production process better all the time. And should use Scrum ceremonies to share these thoughts with team, implement changes in working processes and continuously monitor the results.
Mistake 2. Lack of Genchi Genbutsu
Genchi Genbutsu 現地現物 means “go and see” and it is a another key principle of the Toyota Production System. It suggests that in order to truly understand a situation a manager needs to go to the ‘real place’ – where work is done.
To effectively improve production process Scrum Master must have a deep knowledge about it. Without this knowledge even Scrum Msater tries to practice Kaizen he will not succeed. If we are talking about software production then Scrum Master must understand all the phases of it: programming, testing, deployment, documenting etc.
A development team should give messages to Scrum Master how they think the working process can be improved. This is right. But if team is not experienced with self analysis it can be not enough. Then it is a big advantage if Scrum Master has software development background.
Mistake 3. Lack of 5 Whys
The 5 Whys is an iterative question-asking technique used to explore the cause-and-effect relationships underlying a particular problem. The technique was originally developed by Sakichi Toyoda. A key phrase to keep in mind in any 5 Why exercise is “people do not fail, processes do“.
Example:
Team produced a twice more buggy software release then a previous one. (the problem)
- Why? – Team started to use new underlying open sourced software library and it is bad documented.
- Why? – We did not buy a well documented commercial library for the same purpose.
- Why? – Internal purchase routines in our company are too bureaucratic and developers have no time to deal with it.
- Why? – Personnel responsible for purchasing uses outdated software.
- Why? – Personnel responsible for purchasing need to upgrade their competence. (fifth why, a root cause)
Even if a Scrum Master tries to continuously improve production process and has a good understanding of technology but the problem-solving analysis is not deep enough then Scrum team will not succeed. “5 Whys” is a simple method that helps Scrum Master to identify the problem cause.
Read more about Toyota Production System, Kaizen, Genchi Genbutsu and other Toyota production principles in “The Toyota Way” book by Jeffrey Liker.
Mistake 4. Wrong team building
I found that some Scrum Masters try to build a NON-cross functional teams. They want to build teams of developers with equal competence. And say if they have fron-end developer, back-end developer and DBA in a team they mix tasks and give fron-end tasks to DBA, back-end to front-end developer and so on. The reason they do it is to rise the “bus-factor“.
Guys, this is stupid. If you want to force your DBA to program JavaScript the best result will be bad JavaScript code. The worse result will be if your DBA leaves the team.
Team members can not be copies of each other. Software engineers love to become experts in the areas they like.
What we should do instead is to build teams with T-shaped competence.
T-shaped skills mean that a team member has deep skills in some preferred area. However that team member can also work outside of specialty area. This member is probably not very good with areas outside of preferred specialty but can help out with them if team is experiencing a bottleneck and needs to swarm people to get the job done.
How to build such T-competent team? Do not force anyone to pick foreign tasks. Organize knowledge transfer instead, document the work is done. Say DBA must document the database scheme, replication setup etc. DBA should organize a seminar or better a workshop for knowledge transfer purpose. Then other team members will be able to replace main DBA on simple tasks with help of knowledge they got on seminars and workshops and documentation. If this will be needed. But not as a rule.
Read more about team building in “Essential Scrum” book by Kenneth Rubin.