One of the most important activities when engaged in process improvement involves reflecting upon existing capabilities. True, the activities that sustained development may not improve development anymore. For example, when things have plateaued.

Not everything needs to change--if the business is producing value something is being done right. The trick is to tease out the existing goodness in what's right and identify small improvements to add.

I’ve recently purchased Bertrand Meyer’s book “Agile! The Good, the Hype and the Ugly”. Meyer looks at Test Driven Development (TDD). Meyer’s discussion on TDD adds clarity to the murkiness surrounding it--no code without tests. Nuff said.

Is no code without tests enough?

Nope.

Testing shows the presence, not the absence of bugs. [Dijkstra]

Meyer points that it's impractical to expect that you not start any development until all tests pass. You may justifiably document the existence of bugs during development and rightly spend your time working other parts of the functionality that are deemed important.

In "Why Most Unit Test is Waste (A Look at Test Driven Development)" I point out a vagueness surrounding when to begin TDD. This vagueness manifests itself in the form of bootstrapping your architecture. The answer isn't in that article because it goes against Agile principles (Working Software instead of comprehensive documentation). The answer is you create an architecture then move on to the development and testing (in which ever order you prefer).

Practically speaking there isn't a one-size fits all answer to these questions. Experience and knowledge play a big role in the decision on how much is enough. I do like Leslie Lamport's position in Thinking for Programmers: create a blueprint with enough detail to permit you to continue.

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-organizing 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 continual 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.

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.

I've recently purchased a copy of Blue Yodel by Ansel Elkins. I can't say enough about the poems in this book. They have a haunting and disturbing quality that forces you sit back and really think about what she's saying and, more importantly the deeper implications of what she is writing about.

The forward by Carl Phillips does a much better job than I can of dissecting some of Elkins writing. I'll simply add that the depth that Elkins brings to her imagery and the placement of dissimilar images has an effect that is magical.

If you are considering purchasing one book of poetry this year consider Blue Yodel. You won't be disappointed. Blue Yodel by Ansel Elkins
My rating: 5 of 5 stars



View all my reviews