"Self organisation without constraints is anarchy" - David Snowden
‘You’re an empowered team, self organise!’ This is something I have often wished worked as some kind of mystical incantation that short-cuts all of the hard work, soul searching, difficult conversations and reflection teams and their coaches have to undertake on the path to true self organisation. That’s not to say it cannot be fun; the point that I am making is that it is not easy.
So why isn't easy? Few of us are blank canvases, we all bring with us our previous experiences that shape our mental models and thus the way we think. I remember vividly the challenge I felt changing my own mental models after years working in a traditional (Waterfall inspired or based) delivery environments, adapting to autonomy was tough.
So while we may think the products some of us work on may be ‘green field’, the teams we build are never on a green field site because the way we act and what we build will inevitably be shaped by past experiences so in essence it's always a brown field team and development.
Clear and consistent support by senior management can help but we know all too well that the impact of such support, often fades quickly and can be taken the wrong way. Have the management come and spend some time with the team and receive some coaching themselves (from your resident Agile coach or Scrum Master). Senior management that believes and chooses to 'go see' beats any level of passive sentiment only senior management support.
Enabling constraints can help us break these mental models and form self organising teams that realise their empowerment. Enabling constraints are those which open possibilities, by limiting the choices that we have, by restricting the possible options available and leaving enough so that creative ways to deliver can still emerge.
It can be incredibly daunting for a team to be given the power to shape their own destiny and it is naive of us to believe that all teams are formed with the inherent ability to successfully self organise on day 1 or even on day 100.
By using our knowledge from successful self organising teams we can carefully pick the constraints that we put into place, some options are:
- Take a leaf from Kanban and set some Work In Progress (WIP) limits. This can help to
- Get people to pair up or form groups; in short work together more
- Help the team get the items they have started finished to help avoid half finished backlog items at the end of the sprint
- Are the team's skills (or lack of them) creating pain?
- Self forming teams, some say, are much stronger and have a higher sense of purpose. If nothing else it can be fun and definitely makes people feel more involved in the process. Let the potential team-mates arrange themselves into the teams but state at the beginning of the exercise the skill sets (and their proportion) you believe each team should have and have each person label themselves with their name and primary specialism to make life a little easier.
- Of course this only works if you have a choice in who is to be in the team/s, when faced with no choice work with the Product Owner and set her constraints that enable the best balance of Backlog Items that meets the needs of the Users and also enables the team to develop the right skills.
- When faced with a skills deficit learning is even more important than ever so, again, work with your Product Owner to constrain the number of items that directly contribute to the Product Increment and let the team fill the gap with learning, preferably through learning items on the backlog (to ensure transparency)
- Get some comfy seats for the team (and oh yeah make sure that they are within 5 steps of each other)
- Constrain the seating options for the team, don't enable the team to sit in different locations as this will mean self-organisation will be a very slow train coming but do let them make their team area their own.
- Help the team understand what a good task backlog item and task size is for them and set a limit for the number of people that can work on it
- It’s easy for teams to throw the kitchen sink at a backlog item or task as some of our mental models still believe that throwing more people at a software delivery will make it go quicker. In reality all this does is increase the necessity for communication and invariably slow things down.
- To increase ownership of the team deliverables ask that a pair or individual make a statement to the team when they pick a backlog item or task to work on “this one is ours”
- Working in an Agile environment isn’t all democracy and holding hands dancing through the field. An Agile environment should be a rigorous, focussed, committed meritocracy which means ownership of the work to be done is imperative. There is nothing stopping the team letting a particular pair, person, group taking ownership of completing an item. What is not the right thing is to have someone assigning these tasks out to the team or having the Scrum Master, Coach, Product Owner, well anyone other than the team as a whole be accountable for the delivery of the item.
So that's it, what are your thoughts? There's lots I haven't mentioned (in the interest of brevity) so let me know what you think. Its also dawned on me what I should probably have a good think about the classic question “Why self organise?” and think of some good ways to answer it.
