The Dragonflame

Thoughts, stories and ideas.

30

Mar2015

Scrum fundamentals - self-organizing development team

The second entity in a Scrum is the development team. As far as Scrum roles are concerned, anyone that does work towards achieving the sprint goal is a developer. Traditionalists may call team members devs, testers, etc but in Scrum they are all developers.

Among the qualities of the Development Team (DT), the Scrum Guide states a particular quality that has sparked a great deal of controversity: self-organization. What does self-organization mean? How far does it go? To what extent can a scrum development team self-organize? Why is it important? And even: should the team self-organize?

What does self-organization mean?
This question is fairly simple and the answer is given right there in the Scrum Guide: No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality.

To what extent can a scrum development team self-organize?
The Guide also hints at this answer as well: the team decides how to do the work. The Product Owner (or any BA behind him) decides the what, the team decides the how. However, the details can be sketchy. Let's not forget that Scrum is a development framework. It guides the development process, not the management of the entire company. The Scrum Team coexists in the larger enterprise environment and still obeys some rules. For example, the team doesn't control the resources: from people to hardware, the team will manage what it has at its disposal. Some scrum proponents suggest that the team should be able to choose their Scrum Master. While it may be a good idea to have this ability, the choices are still controlled by the company's hiring policies. However, at the very minimum, the team controls all the details of how to turn user stories into usable product following the prioritization.

Why is it important?
This question is a bit more tricky. I can't say I have the ultimate answer, but it seems to be a method of waste-control. The team has all the technical abilities required to build the product. Of all the components of a Scrum, the Development Team concentrates these abilities and decides how to use them. They are told what to do and then they decide on the how. Waste comes in through command-and-control systems when the developers are required to spend time justifying the how to non-technical people. This is the ultimate definition of waste because the "why" related to the necessity of a certain technical task that a developer says is required for completing a story is lost on people outside the dev team and is ultimately irrelevant.

Waterfallian Project Managers tend to drag teams into justifying each and every action, a course of action complicated by partial technical knowledge incompletely drawn from past projects. The impression of understanding makes these PMs second-guess team decisions and (worse) referring authority to outside sources. While another opinion might be useful at times, it is still up to the team to decide when/how and to whom to refer in case it is needed. Other people's know-how, while potentially valuable, doesn't change the fact that the team working on the project needs to implement the teachnical solution and as such it is very likely that solutions coming from outside, regardless how efficient, are not sustainable in the long run unless they are under the complete control of the working team. It is fairly pointless for you to tell me to use a different library than the one I am used to, because even if assuming your idea is better, my unfamiliarity will make my work less efficient, more prone to error and when time comes to maintain that code, the lack of knowledge will make it risky.

In order to be able to own the work, the development team needs to be able to self-organize and take all the decisions required. While experienced team members can (and should) challege and help other team members, POs and SMs shouldn't force the team into technical justifications as the skills of the team as a whole should be trusted (if they aren't, then it means perhaps someone built the team in the wrong way).