Agile Management vs Self-Organized teams: a contradiction?
Categories: Professional, Consulting, AgileA key concept for agile development is self-organized teams: the development team is completely responsible for the end result, and thus is given all power of commitment to a sprint or iteration. Interestingly enough, extreme programming adds the “coach” into the mix, while Scrum has a “Scrum Master” while Feature Driven Development organize feature teams with “class owners”. These positions resemble some power-roles in the teams, similar to project manager or technical lead roles. Can you have complete self-organizing teams with such roles?
Forget the Scrum Master? The Scrum master has no authority over the team. Yet, the Scrum master should facilitate that the Scrum process is followed and remove any obstacles the team has. I quote: “The ScrumMaster is responsible for orchestrating and enforcing the process (i.e. Scrum), and removing any impediments that hinder the team’s progress.“ In a truly self-organized team, why cannot the team handle this role amongst themselves, if the need is there? Isn’t this what true self-organizing is all about? What options do the Scrum Master have if the impediments are amongst the team? Even more, I quote the script (the agile manifesto, www.agilemanifesto.org) first line: “Individuals and interactions over processes and tools”. Hence, having a Scrum Master to enforce the process seems totally contradictionate to the core of agile development? How can the Scrum Master really enforce the process with no authority? What if the team decides, as self-organized as they are, to go another direction than what is core-scrum?
But what then is Agile Management? Self-organizing teams are, per definition, without management. However, it’s important to specify the limits of the team: The team is solely responsible for creating working software that delivers business value in accordance with the customers expectations. Thus, the team is not responsible for anything outside the creative part of business value. So the agile management must handle this. For me it looks like the development team is a “black box”: Scrum tells us how the development team wants the requirements (input), while the team is responsible for the output. Given there’s a balance between expected result (input) and actual result (output), the project is a success. If the balance is not there, the input is altered in an effort to correct the difference between expected and actual result. If, however, the team consistantly fails to deliver expected results management need to take action: change inputs, change the process, change the team or shut down the process. Either way, the error has already been made and the project may be lagging. Management always wants to avoid teams from failing but giving up authority to self-organizing teams drastically reduce this possibility.
No wonder why agile management is probably the most diffuse and difficult role of all agile roles.