Wednesday, November 18, 2015

Harness the Power of Done (And Be Free!)

I'm going through an exercise to define a definition of done with the software team I work with. We have an informal definition implied through our working agreements.  A good definition is formally defined, well understood and applied consistently by all team members for all deliverables.

If you want apply something consistently you need buy-in.

To enable buy-in I started with the Scrum Guide, the definition of the Retrospective, a champion, and guidance. I stayed out of the decision making and limited input to questions and clarifications on objectives.  I was fortunate. The team wanted to do Retrospectives and had a champion to help develop this capability.

The Retrospective is an activity providing a team with the opportunity to reflect. Its focus is on people, processes, relationships and tools. Its intent is to provide a mechanism for capturing learning and identifying actions for improvement.

Built into the Retrospective is the requirement that the definition of done be improved. It is an explicit manifestation of continual improvement for a Scrum team.

People can bristle at the suggestion they can improve. They equate improvement with deficiency instead of excellence. Athletes intuitively understand that improvement results in better performance.

A champion is key to achieving buy-in.

With support a champion can engage, educate and identify impediments. I deal with impediments by helping frame questions. The lack of decision making other than objectives means the champion owns the solution. The lack of decision making is critical to developing a self-organzing team.

Successful champions are self-aware.

The self-aware champion has a pragmatic understanding of their abilities and values differences of opinion. They recognize that like-minded individuals are easy to work with but that they can fail to challenge assumptions.

A champion works in small groups.

A small group is important during the initial stages. During the initial stages the champion needs to clarify their ideas, approach and issues. A small group provides the champion a way to work though these issues with people who see the problem space differently. It is this small group that helps frame the objectives for the rest of the team.

The critical success factors are a champion and helping them create a work group that provides the diversity needed to do a deep dive on the issues.

It took a self-aware colleague to crystallize the importance of finding people to complement a champion. This colleague improved my understanding on how to improve the chances for successful organizational change.

Examples enforcing the value of differences in opinion include concerns expressed around the need to formalize the Retrospective and the need to continually improve.

Scrum defines the Retrospective as a meeting. Its value lies in capturing and executing opportunities for continual improvement. Challenging whether a separate meeting is valuable because there may be other ways to conduct effective Retrospectives.

Can Retrospectives be effective without a formal meeting, especially if the team already has other avenues to conduct conversations? I don't know. We conduct a Lean Coffee each week so this line of enquiry is valuable.

Tying the definition of done to continually improvement may not be obvious to the causal reader of the Scrum Guide. The implications require thought. As does the question of how much to improve.

Upon hearing this, I suggested this linkage might make an excellent agenda item for the work group. Will they discuss it? I may never know. The fact that it's on people's minds is valuable because it seeds a conversation on how the team can grow.

It's too early to tell if the team will succeed. The fact that there is desire, a champion and supportive management implies we are well on our way to getting a definition of done and valuable Retrospectives. I look forward to the outcome.

Thursday, November 12, 2015

Self-Organizing Teams for the Rest of Us

I was pleased to learn Bertrand Meyer's position on self-organization in "Agile! The Good, the Hype and the Ugly". In Meyer's view, self-organization is hype--widely touted ideas that make little difference, good or bad to the resulting software.

I support that a team should be empowered and that empowerment should include the ability to organize their work. I value the input from the people who work with me and I strive to create an environment where people can contribute to their fullest and can provide constructive criticism. It seems foolish and unwise to do otherwise. This is just common sense.

Where self-organization becomes confusing is the discussion on subtle control by asserting influence. [1, 2] It is devilishly difficult to glean what this really means. How might this be achieved in practice? It might involve management using the Socratic method. It might be a combination of completely different approaches.

Meyer points out that the degree of self-organization achieved is dependent upon the skills of the practitioners within the team. An exceptionally experienced team may work without a manager but until you have such a team it is likely to require one.

Meyer takes exception to the notion that self-organizing teams should be applied to the entire software industry. This doesn't imply that self-organization is a poor goal--on some levels self-organization is just common sense. On other levels, it paves the way towards higher performing teams.

Just because many teams will never become the equivalent of a conductor-less orchestra isn't reason to ignore this idea. It is reason to recognize that such a lofty goal may not be achievable and that the costs in trying to achieve it may not be worthwhile. That's good advice.

A few teams I've worked with have struggled with self-organization. It's refreshing to get another perspective on the topic. Especially when this perspective pushes aside the complexity hidden in notions of self-organization and points out that good software can be created without self-organization.

[1] Organizing Self-Organizing Teams presents a theory for promoting self-organization with a team. This theory assigns 6 roles that need to be used, mostly by an Agile Coach who interact with the team.

[2] Self-Organization and Subtle Control: Friends or Enemies? provides a simple introduction to complex adaptive systems, links the theory behind these systems to a software team and contains a couple of models for introducing positive change into a software team.