Some Thoughts on Self-Organization in Agile Teams
I think some of us are getting it wrong when it comes to self-organization.
Self-organization doesn’t mean that the team doesn’t have managers or that they get to decide what problems to solve or what product to build.
Self-organization doesn’t mean that the team doesn’t have any tooling constraints, or architectural constraints, or budget constraints, or timing constraints.
Self-organization doesn’t mean that the team decides who is on the team, how big the team is, or how much money everyone on the team should make.
Self-organization DOES mean that once the team is formed, and given a problem to solve, and a set of constraints to operate within, the team gets to decide how the work is done.
While any given team, in any given company, may have have latitude to make any or all of these decisions, in my opinion, that is not what is meant by self-organization as it pertains to agile.
I’m interested in your thoughts.
Comments (5)
Allison
Hear, hear! I’ve heard managers refer to their “self-managing” agile teams, and I thought they meant “self-organizing” and didn’t realize the difference. Since then, I’ve realized that those managers weren’t sure about their role and what constraints they were allowed to impose–they feared being too prescriptive or not trusting the team. Esther Derby has some old blog posts on this topic, and she does a great job highlighting that managers need to provide context and create the right environment for teams to self-organize.
Josh Rivers
I’ve seen this definition before.
‘Be as agile as you want to be, as long as you conform to my process, as negotiated by our contract, following my plan, with my tools.’
I’m just surprised to see this advocated outside of a Dilbert strip.
Certainly there are constraints and limitations, but creative solutions involve challenging them…not finding the smallest and most acceptable box to be ‘free’ within. I’ve never seen anyone as interested in improving quality as the people who do the work, and empowering them to disrupt the requirements, timelines, plans, and tools demonstrates trust, respect, and commitment.
Josh, the post was about the definition of self-organization within teams. You suggest that certainly there are constraints and limitations (my point) but then go on to say that the team should disrupt requirements, timelines, plans, and tools. If everyone in a large organization is disrupting the environment, and we require multiple teams to coordinate on more complex deliverables, and the are being disruptive in their own way… how might they come together on a large integrated whole? The answer is that the companies doing this create teams aligned around business problems, with autonomy over the architecture, and have few dependencies between them and the rest of the organization. Couple that with a business model that is striving for innovation, and one that values constant change, and you could be successful. Applying what I understand your position to be in the companies we often work in… where teams are not well formed, where architecture is tightly coupled, and there is a ton of disfunction… you’d have a formula for chaos.
If you want to discuss further, we are going to have to have a conversation about context and local applicability. I don’t disagree in principle, but I don’t agree your formula will work everywhere. In any case… none of that was the point of this post. The post was about what self-organization means in Scrum. We can talk all day about what self-organziation should mean, but I was discussing my interpretation of what it does mean. I’d like your take on that if you have a minute.
Josh Rivers
Mike, the breakdown between what ‘should be’ and what ‘is’ continues to be a problem I have with agile in the cultures I’ve been involved in. It’s a hard thing to digest, and I’m still working on it. I certainly do not have the breadth of viewpoints that you have as a coach for many organizations. I’m sure there are lots of organizations out there that simply will never get to the place they should be. Perhaps there is a degenerate form of agile or scrum which is ‘better than nothing’ that can be customized for them. I’ll probably continue to rail, quixotically, against this, however. I have too much respect for human value and individual contribution to accept that the reduced form is the thing to aim for.
The thing that drew me to your blog in the first place is one of the ways that you refuse to accept a non-crossfunctional team. In my own organization, this is a real challenge, since the people in certain positions of authority or control over information chokepoints really don’t want the work to flow without them in the middle of it. When we do get direct access between developers and the people who use the features, however, the work produces higher quality, in shorter times, with less cost and overhead. There is something here about how prioritizing the work product, and the people doing the work, over organizational structure and hierarchy and standards that simply makes the company and the world better. As Poppendeck asays, Results Are not the Point.
> If everyone in a large organization is disrupting the environment, and we require multiple teams to coordinate on more complex deliverables, and the are being disruptive in their own way… how might they come together on a large integrated whole?
I think that people have really strong natural, instintive abilities to come together. I think if everyone is empowered to challenge the tools, process, plan, etc. and communicated with in a respectful way (and expected to communicate in a way that is mutually respectful) then disagreements will resolve and the best ideas will be adopted. Also, large integrated wholes often appear out of the emergent patterns of competing, conflicting, and disjointed efforts. Trying to establish norms from the top down is a premature optimization, and excludes so much of the value we pay for in hiring creative human individuals to be part of our teams.
> Applying what I understand your position to be in the companies we often work in… where teams are not well formed, where architecture is tightly coupled, and there is a ton of disfunction… you’d have a formula for chaos.
This may be true. It may be that I’m completely wrong and that good stuff cannot be created in the ‘real world’. However, I spend a lot of effort trying to respect and empathize with this view in the environments that I’ve been part of and I tend to see not a fear of chaos, but instead laziness. It’s hard work to manage and lead people to be integrated, valued, educated, trained equals. When people say that ‘it can’t work here’, I hear ‘I’m too busy and uninspired to try’. Sure, you can CHOOSE to exclude your team mates from discussions and dictate that things be done within your constraints ‘beacuse I said so’. You can use power or authority or shame to quiet the disruptions that come from creative change. In the end, you act as a sieve that filters out the creative people from your organization (those people will leave and go some place that values their effort) and concentrates the pool of mediocrity and disfunction. Thus the prediction is fulfilled ‘it can’t work here’.
> The post was about what self-organization means in Scrum.
I’m not sure what Scrum means. On the one hand, it speaks the language of agile and kaizen and improvement. Things like cross-functional teams, and fail-fast can be part of it. On the other, it is often proposed as a imposed and constrained process with statements of ‘we can’t do that here because we do scrum’. The tension between creativity and control is external to Scrum, but is often fought on the field of Scrum with the words of Scrum.
I just hope we can work together to communicate, heal the engineering/management divide, and make our companies and world a better place. I think it’s worth the struggles and fights and hard work. I also know that not everyone agrees with me on that value or the belief that things can actually improve, so I find myself seeking more ideas. Thank you for your contributions to that!
Josh, sorry for the delay approving your post… something was goofy. I saw it come in and then it disappeared for a few days. Couple of quick points…
1. I do think people are resilient and can solve problems, but I don’t think they naturally organize into good architecture. I do think people tend to optimize for the wrong things, often at the expense of the whole. Sutherland said publicly one time that ’emergent architecture’ was never intended to cross class boundaries. I think something similar can be said for self-organization.
2. I am solely focused on the mechanisms of change. How to we get to be the kinds of organizations that can do agile well. What does that end state look like and how do we get there? It sounds like you are an idealist working in anything less than an ideal world. I prefer to be a pragmatist in the short run and an idealist over the long run. Winning little victories doesn’t matter to me unless I have a plan for winning the war. Little bright spots where the ideal works for me is meaningless.. I want the whole system to change. My passion is for how to get the WHOLE system to change. That requires day to day pragmatism IMO.
Thanks for the comment.