I recently had an interesting experience with a new team learning Scrum. The team came from a hierarchical background where they were very process oriented. For the first few sprints of scrum the team went through the normal forming stage and then all of a sudden it all began to fall apart.
In dissecting what went wrong with the team various feedback was received but overwhelmingly the feeling from my side was that the Process of Scrum had taken priority over the principles of Agile.
For example…
The “Product Owner” was not happy with the progress of the team but felt he could not verbalize this with the team because he did not want to be seen as “managing” the team. Instead he felt that the demo with the client was the best place to verbalize his concerns. A team member was very concerned about how some of the team were working together, but felt he had to wait a week and a half before bringing it up with the team because this type of communication was meant for the retrospective. For me these are classic examples of someone learning the process, but not learning the principles behind the process.
The agile manifesto outlines the principles quite clearly…
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
In both examples what came across strongly with both examples was that these individuals were putting processes and tools over individuals and interactions.
For instance, the Product Owner was correct, the process is not to “manage” the team in a command and control structure and the demo is a place where concerns about the progress of the project can be verbalized BUT what was missed was if you are part of the team (which the product owner is) and you feel your fellow team members are off track and not going to deliver you have every right to bring this up in a respectful way to the team and address it asap. This is not managing, this is called being a team player. You would be doing your fellow team a disservice leaving this.
This was highlighted even more with the team member waiting a week and a half to verbalize their concern of a process because it was retrospective “stuff”. The retrospective is definitely a good place to bring up process adjustments, BUT it is not the only place! If there is a major issue and it has to be dealt with now then now is probably a good time to deal with it (Provided it is urgent). If it is not urgent and can wait a week and a half then the retrospective would be the better place to bring it up.
The rule of thumb… process is a good thing and having a solid process is a good base for a well performing team, but understanding the principles behind the process ultimately leads to a team being really effective.
