Partnership & Possibilities

I do my best work in collaboration. And this October, I get to collaborate with two outstanding Agile colleagues! Lucky me! And lucky you if you can clear your calendar to attend these workshops.

Secrets of Agile Teamwork: Beyond Technical Skills October 21-23, with Esther Derby. Esther and I have offered this public workshop in Portland for several years. Directors, project managers, coaches, and team members applaud both the format and content of this course. This fall, for the first time, we’re going East Coast, and holding the workshop on beautiful Amelia Island in northeast Florida. For a description and registration information, look here.

The Art of Agile Planning October 27-28, Portland, Oregon, with James Shore. Jim and I have put together this workshop to review and extend the material in his book, The Art of Agile Development. In this course, you’ll learn everything you need to know about agile planning: product envisioning and the role of the product manager; making and meeting commitments; release planning, risk management, and roadmaps; writing stories and identifying minimum marketable features; iteration and Sprint planning, task estimation, and getting work to “done done.” For a more detailed description and registration look here.

The Art of Agile Delivery October 29-31, Portland, Oregon, also with James Shore. In this course, you’ll learn everything you need to know about agile delivery: incrementally exploring requirements; using test-driven development and refactoring; involving customers and writing customer tests; how incremental design and architecture really work; involving testers, conducting exploratory testing, and creating code without bugs; automated builds and continuous integration; delivering software that’s “done done” and ready to ship. For a more detailed description and registration information look here.

As the chair of the Agile Alliance board over the last year, I’ve had lots of occasion to think about the effect of group values and principles on work. This pondering led me to invent a new activity for the the “Gather Data” phase of retrospectives.

Instructions for Values Activity:
Have plenty of sticky-notes available. I like the 4”x4” super-sticky kind. Accompany the sticky notes with black, broad-line felt tip marking pens. I like the water-based kind that don’t bleed through the paper, but permanent ones will work too.

Ask team members to pair up or get in groups of three. Give the group a task of remembering and writing down events that happened during the iteration (or release). Depending on the length of the iteration, I allow 7-15 minutes. Encourage them to work quickly without censoring each other or evaluating the events. Stress quantity. So far, it’s like the preparation for a Team Timeline or FRIM activity.

Prepare flip charts labeled with Agile values. Use your Agile team values, or the XP values, or the Agile Manifesto values , whichever ones have the most meaning for your team. Make one sheet for each value, plus a blank sheet titled, “value-free”. Draw a horizontal line dividing each value sheet into two roughly equal sections. Label the top section with a + (plus) and the bottom section with a - (minus). Post the flip charts up on a wall in a row.

Ask the pairs to post their sticky notes on the sheets according to whether the event was an instance of a high expression of a value or a low expression of a value. As team members post the sticky notes, encourage them to add any other events that come to mind.

When all the sticky notes have found a place, move the group across the room from the chart wall. Ask a series of questions to explore the events and values, for example:

* What did you see and hear in your small group as you thought of events and wrote them down?

* What do you notice from this distance about the events the whole team posted? Where do you see many notes? Where do you see only a few? What other patterns do you see? (Move closer to the charts so everyone can read the notes.)

* As you think back about the events, which ones seemed challenging or frustrating? which seemed surprising or confusing? which seemed fun or enjoyable? What do you notice about where those notes appear on the charts?

* Which values has the team kept alive? Which not? Why? How do those values impact what has worked well during the iteration and what you’d like to change?

* What would we need to do during the next iteration to live up to our values more often?

After pondering the answers to these questions, the team moves more easily into a discussion of possible action steps and making a team decision about plans for improvement. But that’s a different activity.

Story
When I introduced a team to this activity we used their values: Customer Connection, Clear Team Communication, High Quality Product, and Mutual Respect. As they considered where to post different notes, I overheard discussions about how different events reflected a push for fast production over quality and how that had affected their demo. Some of their speedier shortcuts created unwelcome behaviors in the code. Sacrificing the value for a quality product had also impacted their value for a strong customer connection. The customers didn’t understand why they heard so many excuses, restarts, and “ooops!” exclamations during the demo. Was it ready for them to see or not? After working so hard to build trust with their customer, the team could practically see it eroding during the demo.

The activity gave the team another way to look at how they worked together during the iteration, as well as a deeper understanding of why their values mattered.

They generated many ideas for sticking with values more closely when they answered the last two questions: How do those values impact what has worked well during the iteration and what you’d like to change? and What would we need to do during the next iteration to live up to our values more often?

Over the years, I’ve noticed when I have a stronger response to particular phrases, sentences, doggerel, koans, and so forth. I get a thrill when someone can frame an idea simply and powerfully into a pithy statement. I collect those inspiring or clarifying quotes. I find them in many sources and sometimes in unlikely places, though usually not from compilations.

Today I’ve decided to share five of my favorites:

An Ethiopian proverb:
When spiderwebs unite, they can tie up a lion.

Rudyard Kipling, poet:
All good people agree, 

And all good people say, 

All nice people, like Us, are We, 

And every one else is They.

A statement heard from James Burke, author/historian:
“As in Nature, if an organization is too inflexible or stands still too long it will get eaten.”

Thoughtful reframing from Abraham Lincoln, President:
“The dogmas of the quiet past are inadequate to the stormy present. The occasion is piled high with difficulty, and we must rise to the occasion. As our case is new, so we must think and act anew.”

Excerpt from Mary Parker Follett, pioneer of organizational theories:
“It seems to me that whereas power usually means power-over, the power of some person or group over some other person or group, it is possible to develop the conception of power-with, a jointly developed power, a co-active, not a coercive power.”

If you like quotes too, you can bring them into team retrospectives. Offer a quote as part of Setting the Stage. Ask each team member to check in by saying how they think that idea showed up during the iteration. Choose quotes that don’t obviously fit. Make it a creative stretch. It helps to prepare everyone for thinking creatively during the session.

Last month, Cory Foy sent me an email about a project retrospective that gave his team new insights and direction. He used the subject line, “They got it!” You can find the story of Cory’s recent retrospective experience, along with the thread of additional comments, on the XP list digest archive.

Here’s Cory’s story.

“Yesterday I started my new role as the development manager of a team that was just bought out by a new company. They released the latest version of their software (an 18 month effort) on Thursday - a couple of weeks late, after about 2 1/2 months of working extra, weekends, and lots of heroic efforts, plus, of course, being bought out.

“This afternoon I moderated a project retrospective for almost the entire team - we had support, QA, Development, Business Analysts and Management present. I used several exercises out of Esther and Diana’s Agile Retrospectives book - Check-In, Focus On/Focus Off, Timeline, Color Code Dots, Patterns and Shifts, Learning Matrix, and Start/Stop/Keep.

“Without any leading towards agile from me, the team analyzed the information, looked at insights, and decided on the following actions:

  - Find better ways to estimate
  - Find ways to involve the whole team earlier
  - Find ways to introduce a more iterative development process
  - Modify our methodology to better define “done”
  - Give frequent demos (ideally at the end of the iterations)

“It was really nice to watch a team take the time to look at what they’ve done, spend time working as a team to evaluate it, and deciding as a team that the only way they are going to get better is by finding ways to become more agile in their day to day workings.”

Cory went on to tell me, “The book was a great guide - I pulled it all off using a whiteboard, some index cards, and some highlighters, since I hadn’t had a chance yet to gather the other materials. Thanks a ton for the great resource!”

Good work, Cory! I appreciate you for the gift of this inspiring story.

Just because your team members feel shy about expressing (or receiving) appreciations in public, doesn’t mean you should stop doing them. Tami Flowers told me about her solution to making sure team members know what they’ve done that helps their co-workers and to encourage them to keep doing those things. She called it “Card Pass with Appreciations.”

Here’s how it goes:
Arrange chairs so that team members sit in a circle of chairs or around a table. Make sure that every person has a pen. Pass out large index cards, one per team member, and ask each person to write his or her name at the top.

Then the fun begins. Instruct team members to pass their cards to the person to their right (or left, just keep it consistent). Each team member reads the name on the new card and writes down one (and only one) thing that person did that helped the writer or the project. Point out that the actions don’t have to be world-changing, even a small action that made things better will do. Offer a couple of your own real-life examples, “When I accidentally kicked the plug out of the fax machine and couldn’t figure out why it wouldn’t work, Lisa found the problem, then crawled under the table to plug it back in. She told me about a time when something like that happened to her. So I didn’t feel quite so stupid,” or “Frank re-filled my water bottle when I was busy” or “Raj overheard our foo problem and came to help.”

Give 1-2 minutes per pass and use a timer to maintain a lively pace. Keep passing the cards around until the cards return to their original owners.

Use this activity to transition from Setting the Stage to Gathering Data. It starts the data gathering process. Alternatively, use it at the end as part of Closing the Retrospective.

We’re getting together again this Friday, Aug. 15. Jim Shore says it better than I. C’mon over.

I was at a party much too late last night (after the Agile2008 banquet), and it’s good I was there. Just as I was getting ready to leave, two people walked over to me and told me a story about their retrospectives.

One of them thanked me for the book and said that it had helped in their retrospectives. Then he told me that the activities in the book had inspired him to create activities on his own. I asked if he would share an example with me.

He described how interpersonal conflicts and friction had plagued his team. As a result, interpersonal conflict issues took up too much of their retrospective time. Team members complained. They had little time available for dealing with other issues. Out of this situation, they created a variant use for their retrospectives.

The team developed a working agreement that goes something like this:
When any two or more people have a conflict, they are _required_ (as part of their membership on the team) to do a root cause analysis on the problem. Together.

My new colleague said that it’s rare when this doesn’t resolve the problem. However, that’s only the first step.

They also must bring their analysis to the next retrospective and jointly report it to the rest of the team. In this way everyone can learn from their experience. After several iterations of this retrospective activity, disruptive interpersonal conflicts have become much rarer. People resolve differences as a matter of course before they become bigger issues. The retrospective reports occur much less frequently. What’s more, the team has returned to using most of their retrospective time for continuous process and methods improvement.

Kevin Kelly, author of Out of Control: The New Biology of Machines, Social Systems, & the Economic World, writes about scenius (a.k.a., “the communal form of genius”).

Which made me think about skunk works in general and, inevitably, Agile teams and their open workspaces, in specific. Kelly describes several attributes of scenius where collective genius can flourish:
* mutual appreciation (“Offer Appreciations” in your retrospectives anyone?)
* rapid exchange of tools and techniques
* network effects of success
* local tolerance for the novelties.

Kelly goes on to describe Camp 4 at Yosemite National Park–a scenius of rock climbing, and notes further attributes:
* an unremarkable space, nothing special, even one that others might find undesirable
* allows for flexible use
* takes some effort and commitment to get there and stay

The next time you select a place for your Agile team to work, consider the above.
* Can you find an unremarkable space that no one else wants? One that could morph in many directions based on the ongoing needs of the team.
* Can you make it a challenge to become a part of the team and set an expectation that it will take showing real effort and commitment?
* Can you create a climate where team members recognize that great ideas, successes, or breakthroughs come from a collective, mutually encouraging effort and where they share the good feeling of achievement?
* Will you value and actively appreciate each others’ contributions? (One idea: Hold Appreciative Retrospectives. See here, and here, and here.)

What would it take for the Agile Alliance create a new source of scenius? Maybe something like the Music Masti at Agile 2008?

An Agile coach contacted me to discuss an issue on his team. One of the critical contractors on his team had left the project for another assignment, unexpectedly, on two week’s notice, just before an important release. Oh my! The coach described his initial shock and dismay. He wanted ideas for how to handle the unexpected loss of a team member with his team. Together we developed a list of five actions that would help deal with this impediment.

1. The Agile coach could contact the contracting agency to give them feedback on the impact on the project of the abrupt loss of a team member. He could seek an agreement with them to give earlier notice of personnel changes. It would be a good opportunity to let them know what skills and qualities he looks for in future contactors.

2. He could meet with the team to ask team members’ for their ideas of how they could still meet their commitments.

3. He could set a time with the Product Owner to recalibrate expectations and let her know the team had developed a plan for dealing with the disruption.

4. If one was needed, he could recruit a replacement. But only if the team thought they could meet their commitments while on-boarding a new team member.

5. He could ask for a team discussion of how individual team member behaviors (like leaving with too little advance notice) impact the team and the project.

Finally, he realized he hadn’t yet built “bench strength” in cross-functional skills and knowledge on his team. Losing this team member meant losing critical momentum while someone else got up to speed. The Agile coach decided to assess the “truck factor” risks on his team. Where else was the project vulnerable to the loss of a single team member? What knowledge or skills needed to spread beyond one or two members of the team?

Armed with several alternatives for action, the Agile coach ended our conversation with a comment, “I know the Agile Manifesto values include ‘responding to change’, but that doesn’t mean we’re calm, cool and collected when change comes knocking at the team’s door! Now I see that when change happens, it’s not a disaster. It’s an opportunity to learn how to increase our effectiveness as a team.”

Sean and Scott from the Software Association of Oregon’s (SAO) Oregon Training Network asked Jim Shore and me hard questions about Agile methods. You can read the interview here.

For more about June 17-18 workshops about introducing Agile into your organization, look here.