Some aspect attracting my attention since my very first Scrum training is the fact how a Team actually handles team work.
In a conventional software development team you probably find a bunch of hierarchical organized group members including managers, an architect, engineers and developers. While the architect figures out what to do with respect to the managers needs, the engineers define how to do it and de developers eventually do whatever the hierarchical organization above has defined.
In a Scrum Team, the Team is told what to do directly by the ProductOwner in form of stories. Consequently, what to do, how to do it and the act of doing it is completely within the responsibility of the Team. In the conventional approach, each level could blame the level above in case of a failure. The developers blame the engineers for insufficient definitions, the engineers blame the architect for a faulty architecture or misleading bullet tracing and the architect might blame the managers due to a strict budgeting, too much pressure and so on. Of course each manager might blame his manager in turn and so on.
So, how do we end up in a team effect? I have seen teams where each developer picks a story from the task board, teams where each developer had his/her own area of stories (server, client, user interface etc.) and teams where the overall team works at one story at once. Boris Gloger, holds the view the entire Team (of developers) works on the same story. I am not absolutely sure yet, how this works in larger teams (5+ developers) with small stories, however in theory, if a story is done by the hole team it succeeds as team.
If each developer works on a separate story, I recall a passage from the latest book of Robert C. Martin, talking about who breaks the code will own it. What’s the logical implication of this? If a developer breaks code he might get blamed by other team members. That’s the quick death to a team. If the team separates in smaller groups which maybe blame this developer, this might be an even quicker detach to the team. If the blaming happens in front of the ProductOwner, this might fundamentally harm the overall Scrum Team, in particular the Team – ProductOwner relationship. Suspiciousness, maybe shorter sprint duration and additional tension within the whole Scrum Team might be the result. The very best ScrumMaster will have a hard time undoing this. Considering the fact that a really good team might take up six to twelve moths to form up, blaming should be avoided at all circumstances.
So what’s the right attitude in this case? If something goes wrong, a story is not fully implemented, code is broken, previous functionality is lost or whatever goes to the dogs, the whole team should stand up, work together to fix this issue as quick as possible without caring who introduced it. Of course the team should perform a root cause analysis what exactly happened, however, as it should be done in retrospectives, the topic should not be what went wrong and who’s fault it was. Instead it should be about how to avoid such a issue in the future. That way its all about improvements and that’s what Scrum is about at the very end.
