Sunday, January 22, 2017

Self-Organizing Teams

Much of the promise of Agile, and specifically Scrum, results from self-organizing teams. Self-organizing teams are the core value creation organism at the heart a healthy Agile ecosystem.  A self-organizing team will deliver functionality at a higher velocity and higher quality. Additionally, members of a self-organizing team will experience higher morale. Simply put, self-organizing teams will be more efficient, effective, with higher well-being than the overly managed alternative.
Unfortunately fostering a self-organizing team is not a simple endeavor. It is both an art and a science and it is a process that can not be rushed.  
When coaching teams and their leadership on the topic I often use the tomato plant analogy.

I don’t understand the mystery of what makes a tomato plant grow, but I do know that if I foster a healthy environment of sunlight, water, and fertile soil over the course of a few months a small fragile plant will likely mature into a fruit producing powerhouse.  
In a similar way, after 10+ years of Agile coaching, I don’t understand all the mysteries of a self-organizing team. There are far too many variables and variations to write a recipe, but I do know that like the tomato plant, fostering a few basic elements will dramatically increase (not guarantee) the chances for success. Additionally, just like you can’t pull on a tomato plant to make it grow faster, a self-organizing team needs time and space to grow to its potential. Fortunately, the tomato plant analogy comes full circle and the time it takes for a tomato plant to yield fruit is similar to the time needed for a team to experience the benefits of self-organization.

Identifying a Self-organizing Team

Identifying a healthy tomato plant is easy, lots of gorgeous fruit with healthy bright green leaves free of blight and leaf eating parasites. Identifying a healthy (performance and well-being) self-organizing team striving to reach its potential is also easy if you have been fortunate enough to experience one. It’s much more difficult to recognize one if your experiences are limited to traditional management structures, waterfall software development, and command and control vs. servant leadership environments. These environments can also produce valuable fruit, but not to the extent that self-organizing Agile teams will.

Here are a few indicators of self-organizing teams:
  • The team understands the Vision of what defines success.
  • The team is cross-functional and have the skills and capacity to complete backlog items.
  • Team members are focused and motivated by results (better product & better process).
  • Team members authentically collaborate (co-create) toward results. They plan, replan, and adjust as a team toward their shared commitment.
  • Team members have fun with one another and enjoy challenging and being challenged by themselves and their teammates. They see each other as peers.
  • Team members have collective ownership (vs. individual ownership) of the code and the sprint backlog (user stories and tasks).
  • Team members pull work from their shared list of tasks. They are not assigned work by managers or “senior” team members. They pull work outside their “speciality” or comfort zone as a way to learn, and increase team velocity.
  • Leadership practitioners are evaluating the team based on sprint results (better product & better process) and not on items inside the sprint (tasks and task hours) and individual resource utilization.
  • Quality is a non-issue, sprint commitments are consistently being achieved, and velocity is predictable and gradually increasing
This is not a complete list, but it should be enough to raise awareness of improvement areas.

Fostering a Self-organizing Team

Just as it is not possible to create a tomato plant, you can not create a self organizing team. But here are a few items that may help to nurture that process.

Development Team

  • Take ownership of contributing your best toward the shared sprint commitment. Challenge yourself to improve and pull work that may be out of your comfort zone. Ask team members for help.
  • Support other team members when they look like they need help. Pairing on difficult tasks is often an effective way to grow skills.
  • Be honest, respectful, and helpful with your team. Create a safe environment to reduce fear and foster creativity.
  • Pull for work. Don’t assign work to other team members. Authenticity suggesting work is vastly different than assigning work.
  • Plan and write tasks as a team during sprint planning and as necessary throughout the sprint. Respectfully challenge teammates on inefficiencies, redundant tasks, or unnecessary tasks.
  • Be transparent with specific tasks and remaining hour estimates. Large generic tasks do not expose the work. Smaller more specific task breakdown better exposes the work and allows team members to work in parallel.
  • Raise impediments when resources to achieve the sprint commitment are outside the reach of the team. Collaborate with those outside the team to resolve the impediment.
  • Contribute to retrospectives and improving your process.

Product Owner

  • Communicate vision, acceptance criteria, and definition of done. Setting clear expectations will help the team to understand where the finish line is and enable them to drive across it. A team will not self-organize if they do not understand their mission.
  • Help the team to be successful. Be responsive to questions and support them in the removal of impediments.
  • Be honest, respectful, and helpful with your team. Create a safe environment to reduce fear and foster creativity.
  • Foster the space for authentic commitment at sprint planning. The team needs the ability to get clarity on the backlog items as a way to raise their confidence. Only then is the commitment real.
  • Keep the sprint backlog stable. Disruptions to the sprint backlog will impede its completion. Shorter sprints (2 weeks vs. 4 weeks) may be helpful.
  • Allow the team to experience success. The sprint commitment should be challenging but sustainable. “Stretch Goals” for a sprint generally play against the feeling of success. Work can always be pulled into the sprint if the team hits its goal early. Sometime it is necessary to pull way back on the commitment for a couple sprints until the commitment is consistently achieved. At that point challenge the team to increase their velocity. If the commitment is pulled back to unacceptable levels, ask the team what is needed to increase it.  

Management and Leadership
  • Allow the team makeup to stabilize for an extended period of time. While deliberate teaming is an effective strategy to grow skills and accelerate velocity, ad-hoc shifts in team makeup will block self-organization.
  • Ensure the team has a shared vision of what success looks like. They need to know their overall objective.
  • Building software can at times, seem messy and chaotic. Incremental delivery, using sprints as time-boxes serves to contain the messiness. Evaluate team performance on sprint results and velocity, not task items within the sprint. Scrum done well is very empowering and motivating for team members, but if daily activities are managed by those outside the team, it can be viewed as extreme micromanagement.  For example, management should not be evaluating tasks or hour burn-down charts within the sprint unless they are asked by team members for support or guidance. The hour burn-down chart is a tool for the team to help them understand where they are relative to their shared commitment.
  • Decouple time reporting from task reporting and feature costing. Using task hours for time reporting generally plays strongly against self-organization and is often interpreted as micromanagement.
  • Assemble a cross-functional team. A team without the skills can not self-organize. A talented and motivated team can grow the skills, but it will take time. Development managers can be embedded with the team to “pair” with other team members and help develop skills, but they need to be viewed as peers on the team.
  • Operate as a Servant leader vs a manager. Partner with team members and ask what you can do to help them be successful.
    • Remove as many constraints as possible, but establish and communicate necessary boundaries and allow the team to work within those boundaries. A team member should be empowered to pull any task they feel they can add value to. Identify and remove traditional processes that may not be adding value in the Agile context.
    • Remove as many metrics as possible. Working software should be the primary metric. All other metrics should be evaluated based on value. Too many metrics will have a negative impact on self-organization.
    • Allow time for the team to self organize. This is at least 3-4 sprints for a cross-functional team.
    • Support the removal of impediments. Partner with practitioners, leadership, and other managers to remove immediate and systemic impediments.
    • Raise your awareness of activities that may be perceived as micromanagement.

Scrum Master

  • Stay neutral in reporting and other activities. “It’s not good news or bad news, it’s just the news.” Partner with the team and the organization on how to effectively work with that information. Champion the needs of the team to the organization and champion the needs of the organization to the team.
  • Coach and support the items listed above for the Team, Product Owner, and Management & Leadership.
  • Champion the Agile mindset and the associated process. Scrum is a framework that can be extended by the team and the organization. Help to keep the practice reflective of the process. This is essential for continuous improvement and valuable for self-organization.
  • Pull for impediments. Look for areas where team members may be stuck or struggling and ask if they need assistance. Demonstrate that you are there to support their success and to help resolve items impeding their success.
  • Facilitate a conversation on self-organization at the sprint retrospective. This blog may be used to help with that conversation

Self-organization is a rich but  foundational concept of effective agility and it’s nuances are complex. Given the space/time, skills, and capacity along with a shared vision, self-organization has a chance to emerge. My hope is that this blog will help raise awareness and help you with conversations regarding self-organization.

Photo Credit: Country by Nature

1 comment:

  1. Good article on self org. Some coaching and mentoring techniques to consider...

    Coaching Techniques

    • Open door office — timely and available
    – Proactive by them is better than reactive by you
    – But if your “mood” is otherwise,schedule another time

    • Direct, to the point and honest
    – Set guidelines in advance to control emotional response to
    • Never, Never make decisions for them
    – Offer suggestions and ideas
    – Remember they have no commitment to act on your thoughts
    • Do a retrospective (review) after each assignment
    – What worked / what didn’t / what did they learn

    Mentoring Attributes
    • Experienced without baggage
    – Been there and done that but not looking to rule the world
    – Doesn’t have own agenda
    • Consistent, ensure connections are steady and reliable
    • Discrete and confidential
    • Positive / upbeat
    • Communicative, willing to tell stories and discuss issues
    • Nonjudgmental (critical)