Scrum is not easy
I was discussing a Scrum implementation today with a unhappy manager. He said that although the teams are improving, the current productivity still needed further improvement and he needed it fast.
He said that the problem was that some people in the teams are specialized for developing services on the ESB and therefore are not fully utilized during the sprints. There is little work for them to do once they finish their specialized work. In order to ‘improve’ productivity he took the ESB developers out of the teams and created a special ESB team. Next to that he also took QA people and architects out of the teams and put them into their own teams. The ESB developers, QA and architects could now go full speed ahead and be fully utilized.
“This will surely improve productivity”
This solution will of-course not improve productivity. The bottleneck is developing the normal stuff and the splitting of the teams does nothing about the bottleneck. The ESB team can create as much ESB functionality as they want, but it will only queue up before the normal development teams.
As a result the teams will get more work produced but will not increase production of completed functionality.
It is more likely that their productivity will even decrease because of undone work that increases every sprint they work like this.
It is ok to try, maybe it does work! If it does great! If it does not also great! as long as he learns and is ready for the next step.