Self Organization inside a Team

One of the biggest challenges in management is be able to track your own rhythm, making sure your plans are executed and things go smoothly.

In my previous post about Driven By Self Organization I stressed the importance of making things visible and plan for the future. How can one set the environment of the team to drive the entire team to success?

Thinking about it lately made me think that I have my own thoughts about what should be visible, how the team should react internally and how should one behave in such team as a Team Lead. Don’t get me wrong, I don’t have 30 years of experience leading small<->giant teams for small<->giant companies, these ideas are solely based on my gut feelings: making things SIMPLE (KISS) so the entire team will be driven by self-organization without the “burden” of self-management. If things are easy to do, it’s easier to get better at them.

The trick is to allow all of the members in the team to be part of the organize->execute game. Some will play, some won’t, but they will all be affected by the always-ready environment and notice how inner-interaction change their day. By making it visible, they will be motivated to take action (it will feel natural). I came up with this drawing to expose our sprint plans and progress:

This is a very SIMPLE presentation of the current sprint features and every-day progress – “cards” will move between columns as people work on them.
There are some magic “self organization” tricks integrated into this 1-Visible-view:

1. Achievement-based planning: Before arranging the features/cards, we try to set the “deliveries” for the week. This is a free-text (don’t be tempted to make it a list of features) ideas to “set the mood” for the week. It will describe features we want to finish, some design we need to handle before the next week, some quality check we want to pass (“make sure no critical/major bugs are open”) etc. They help to plan the week as they define goals that are measurable, driving the team to achievement-based planning rather than like-best-do-first development.
2. Visibility is key: Every member of the team knows exactly what’s left for the entire team on a weekly level. No more “but I finished all my tasks two days earlier than we’ve talked! what can I do that Joe is new here and couldn’t continue as you thought? oh, I didn’t know we are dependent on his task before we can release the package…”
3. Help each other: remind yourselves that things need to be completed, help one another by helping out when someone is behind of schedule (alright Joe, I’ll take Feature A, don’t worry). The board will make it easier to know “where can I help?”
4. We want Quality: Nothing is DONE until it’s tested and fixed. The idea of splitting “coded” tasks from “tested” tasks is to set the mood for “production ready” code.
5. Small goals are easier to achieve: Splitting the sprint into smaller chunks make it easier to win small battles. Each week defines small trophies – the “deliveries” we promised for that week.
6. Plan leftovers for tomorrow: at the end of every week\sprint, you could easily see what was left. Discuss why it failed and plan it for tomorrow (=next week or next sprint).

Team Lead in such a team will mostly act as a coach, helping the team members to split the features into tasks, remove obstacles, motivate cooperation and taking notes about “how can we get better?”. Most importantly, it will allow her (or him) to be productive and feel he can help the team’s effort instead of the constant-chaos feeling managers tend to have when things go poorly. The team members are aware of the plans and can balance the efforts to break loose of this chaos-like feeling.