One of the hardest tasks of working with a team is to get a share framework of understanding. Not only about the business domain, but also about the rules and boundaries which help us to function efficiently as a group. If we all know about each other’s tasks and responsibilities, trust can be created. Without trust, overhead is introduced. For instance in a soccer team, if the offense can’t rely on the defense, how can they focus 100% on their game?
I’m often surprised how the viewpoints in a new agile team differ. Small things like, when do I move a post-it on the task board? The definitions of done, the definitions of ready, estimations, priorities, … basically all agreements that are made by the team about their development process.
This is why during one of our retrospectives, we drew out the workflow from the point of the sprint planning till the time of the sprint demo. I tried not the influence the team by my ideas of a good flow, instead we focused really on drawing the picture as it was at that time.
During the drawing of this process flow, the team often had discussions about the order of the steps, the dependencies and who was involved in which part. This was really the outcome I was hoping for, because it gave an excellent reason to do the second part of the exercise, which is to look for improvement areas. Can we get rid of some dependencies? Can wait times be reduced?
At the end we had several actions for improvement and our framework of understanding was a bit more shared.