What's in Your Agile Toolkit?

Toolbox.jpg

A hammer is very effective at pounding nails, but not so good at turning screws. Different tasks benefit from using the proper tool.

Use of the wrong tool or an improperly used tool can have unintended consequences.  There's an old saying, "Give a 5 year old a hammer, and suddenly everything needs pounding" -- with predictable results.

There are a number of agile frameworks out there, but one of the most popular, Scrum, doesn't prescribe the use of specific tools. This lack of guidance presents a question:  If you are new to Scrum, or are simply trying to increase proficiency, what agile practices should you use? What tools should you pack in your toolbox?

Scrum Skeleton

Scrum Skeleton

Scrum with Practices

Scrum with Practices

Figuring which tools to use is not trivial.  There are literally hundreds, if not thousands, of potential practices.  If you don't believe me, here's starter list ( I stopped at 101 practices):

101 Practices

101 Practices

The answer to which tools to use lies in understanding the problem that you are trying to solve.  In an earlier post, "Where do you want to get to?", I suggest a model for narrowing down the choices to tools that fit the problem space.  This narrowing creates focus on a smaller set of tools best suited for the job.  Add the right tools to your toolkit and learn how to use them effectively in the context of solving the problem.

Where do you want to get to?

331px-Alice_par_John_Tenniel_23
‘Would you tell me, please, which way I ought to go from here?’

’That depends a good deal on where you want to get to,’ said the Cat.

’I don’t much care where—‘ said Alice.

’Then it doesn’t matter which way you go,’ said the Cat.
— - Alice’s Adventures in Wonderland, Lewis Carroll

Where you want to get to matters, unless, like Alice, you are on an adventure and you are just trying to get back to where you started. In my work with organizations, the general intent is to get to somewhere different, somewhere better. As an Agile coach with 20+ years helping others develop proficiency in Agile, I've found effective "where you want to get to" strategies  tend to fall into one of 4 contexts -- team, skills, customer, or flow.

4 Dimensions of Agile Proficiency

These contexts establish frames for selecting specific agile practices and choosing goals for measuring progress towards proficiency in those practices. For example, the "skills" frame might lead to the use of practices such as coding standards, paired programming, and continuous integration. A reduction in production defects would indicate an increase in skills proficiency.

Of course, Agile practices are not restricted to just one frame. Paired programming would be an equally valid practice in the "team" frame. The frames might be viewed in a venn diagram with some practices such as retrospectives living in all 4 frames. Likewise, a measure of progress, like team satisfaction, could span more than one frame.

Agile Proficiencies Overlap

Agile Proficiencies Overlap

The main benefit of frames is focus.  You don't need to, nor should you try to, do all Agile practices at once, right out of the gate.  Just like incremental product development, you should adopt agile practices incrementally, respecting your organization's capacity to absorb change in process and practice, and keeping an eye on your goal -- where you want to get to.

"Draw Left": Why Communication Matters

"ROCK!!!" Despite my warning, the ominous scraping sound moments later told me we were leaving a bit of our canoe behind us on this trip down the Shenandoah River. This little encounter is an example of what my son jokingly calls "painting the rocks" based on the red vinyl marks we sometimes leave as reminders of our passage.

Normally, when canoeing, we try to avoid collisions, and at first I was puzzled and a bit upset that my son had not reacted in time to maneuver the bow of the canoe out of the way. He's a skilled paddler and a simple stroke of his paddle would have been all it took to slip by unscathed. Why hadn't he done what I expected?

Well, in the somewhat heated discussion that ensued, I discovered that I hadn't exactly been clear as to the location of said rock. Besides, I had the advantage of polarized glasses and despite being in the stern, generally was able to see submerged obstacles well before my son. Lacking this critical information, he simply pulled the business end of his paddle out of the water and let me steer assuming I had it all under control. Had I wanted him to do something, clearly I would have said so.

On reflection, admittedly much later and after much fuming, I realized that we could have avoided the rock if I had simply shouted "Draw left, now!" Never mind trying to point out the rock. Avoiding the rock was the goal. Getting the front of the canoe to shift to the left was what was needed now.

Our collision resulted from a failure to communicate. We had mastered the right paddling techniques. But, we hadn't mastered the practice of communicating in a language that would enable us to operate as a team. In the end, it shouldn't have mattered whether or not my son could see the rock. It only mattered that he know what was needed.

At the shout, "Draw left, now!", my son would have simply put into action what years of practice have make into muscle memory. He would have reached his paddle far out over the water to his left, slipped the blade into the water, and, with a quick stroke, pulled the flat side of the blade toward the side of the canoe. The bow of the canoe would have shifted to the left and aided by a stern draw or even a simple angling of my paddle on my part, the canoe would have slipped by leaving that rock unpainted.

In a team environment where a rapid response may be necessary, whether canoeing downriver with a partner or as a team member on an Agile project, it helps to have a common language or lexicon to foster quick communication. The right words spoken at the right time tend to lead to the correct action. The use of words outside the lexicon may lead to undesirable results.

It takes time and practice for a team to create a common language. Once developed, instructions like "Draw left" result in quick and efficient responses. Giving an instruction like "Rock!", which is not part of the language, is often inefficient and ineffective. Developing proficiency or fluency in the team's language is essential to the smooth flow of the team's work.

What is your team's language? How proficient are your team members in their way of communicating?  Consider both business language and technical language. What are the words that are unique to, or have a special meaning, in your environment? For example, the word "forging" means different things to a banker than it does to a blacksmith. The phrase "breaking the build" has a meaning unique to the practice of continuous integration. Knowing what this phrase means is essential to the team to know what action is required next. Investing a bit in creating and practice in learning a common team language will pay off well in improving your team's communications proficiency.