The software developers in a well-known Scrum team have undergone a transition from generalists to specialists in former times. They have been responsible for no specific parts of the software system. Every developer was assigned to the next high priority tasks regardless of knowledge and experience. Combined with classical waterfall project management, solo programming, missing code reviews, and missing unit testing, the resulting quality of the system was extremely low. There was a vast lack of knowledge of the old legacy code the team was working with. To compensate that knowledge all parts of the system were assigned to specific developers - a step that turned them from generalists to specialists.
Instead of moving out of the waterfall into Scrum and introducing pair programming and unit testing it was decided to go the pretended easy way and transforming generalists to specialists. Now single persons were assigned to specific parts of the system but unfortunately there still was a vast lack of knowledge of the old system. The major disadvantage of assigned specialists is the "not my job" syndrome: there always is another guy responsible for the task on my table so work can easily be pushed away. The next disadvantage is the "don't touch my baby" syndrome which instantly blames developers who dared to touch code not in their area of responsibility.
The team resulted in a hypoproductive group of developers, controlled by waterfall processes, solo programming, missing code reviews, missing unit testing, vast lack of knowledge, and individual code ownership: the worst of all worlds finally was born.
Productivity raised instantly after installing a working Scrum with that team. Bug rates dropped rapidly simply by applying the definition of done: code reviews and unit testing now are mandatory. As a next step single team members were asked to spread their knowledge via pair programming. This opened the way to collective code ownership.
The team has to improve a lot more and it will find out all those issues as impediments in the next retrospective meetings. Well, if they don't, the Scrum Master will give some hints by defining appropriate retrospective goals.
In the end, the team will become hyperproductive and will finally re-generelize their specialized generalists.
Instead of moving out of the waterfall into Scrum and introducing pair programming and unit testing it was decided to go the pretended easy way and transforming generalists to specialists. Now single persons were assigned to specific parts of the system but unfortunately there still was a vast lack of knowledge of the old system. The major disadvantage of assigned specialists is the "not my job" syndrome: there always is another guy responsible for the task on my table so work can easily be pushed away. The next disadvantage is the "don't touch my baby" syndrome which instantly blames developers who dared to touch code not in their area of responsibility.
The team resulted in a hypoproductive group of developers, controlled by waterfall processes, solo programming, missing code reviews, missing unit testing, vast lack of knowledge, and individual code ownership: the worst of all worlds finally was born.
Productivity raised instantly after installing a working Scrum with that team. Bug rates dropped rapidly simply by applying the definition of done: code reviews and unit testing now are mandatory. As a next step single team members were asked to spread their knowledge via pair programming. This opened the way to collective code ownership.
The team has to improve a lot more and it will find out all those issues as impediments in the next retrospective meetings. Well, if they don't, the Scrum Master will give some hints by defining appropriate retrospective goals.
In the end, the team will become hyperproductive and will finally re-generelize their specialized generalists.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.