Partnership & Possibilities

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.

In the “Generating Insights” phase of a retrospective, the “Group Mind” activity provides a way for teams to discover where their thinking converges and quickly identify common concerns.

The retrospective leader (RL) helps the team form three or four small groups of team members–pairs or triads, depending on the size of the team. Each small group takes no more than eight to ten minutes to brainstorm all the issues (or ideas for action) facing the team and write each one on a separate sticky note. The retrospective leader challenges the sub-groups to go for quantity of issues over quality. Every issue they can think of should appear on a group sticky note.

Serially, each group offers one issue on a sticky note. The RL asks whether any other group has the same or similar issue and places those sticky notes in a row on the flip chart page or whiteboard. Then another group offers an issue for matching and posting. The process continues, moving from group to group until the team has posted all the issues.

When all groups have reported all their issues, the RL highlights which issues came from all the groups. These are the “group mind” of the moment. As the team moves into the “Deciding What to Do” phase, they focus their ideas for actions on the common issues.

The agile coach or scrum master makes a record of the remaining issues, as the team may converge on one of them as the “group mind” at a future retrospective.

Does your team have Working Agreements? (WA’s)

Effective teams think about how they will accomplish their work together before they begin working. They describe the levels of performance and professionalism they want to achieve, then record them in Working Agreements.

WA’s cover such areas as:

What does “done” mean for us?

What will meetings look like for us? (e.g., type, number, frequency, duration, attendance expectations, decision-making, etc.)

What Agile engineering and project management practices and methods will we incorporate?

What interactions, teamwork and collaboration will best support our work? (e.g., communication flows, conflict, feedback, continuous learning, social time, fun!)

Effective teams regularly take stock to review and revise their WA’s, in retrospectives or planning meetings. They ask questions such as: What Working Agreements have helped our team the most? Which ones have become second nature? Which did we think we needed, only to discover they weren’t enough of a stretch?

The Software Association of Oregon has invited Jim Shore and I to present two workshops introducing Agile methods and mindsets to companies in Oregon as part of the Oregon Training Network. Register for “The Business of Agile” and “Agile Software Development: No Silver Bullets, Just Good Sense” at these links.

BTW, if you haven’t already found it, Jim’s blog is great place to find information about the Agile “how to’s”.

So many teams complain about the “do nothing” retrospective. Team meetings can remain results-free for many reasons (possibly the topic of another post…and anyway, I’m sure Esther Derby must have written about it ).

However, one way to stimulate team members to implement action plans is to follow the energy.

Software teams usually have little difficulty identifying the things they wish were different in their work environments–processes, practices, team interactions, product owner interactions, or impediments that have resisted a simple fix. When a team has created a list of ideas for improvement on a flip chart or whiteboard, I ask them to filter it three ways.

First, I ask them to estimate the story size of the item, in points or T-shirt sizes. That gives everyone on the team a chance to notice how much effort one or more team members will have to give to take the action. And whether they think it’s worth it. (A version of planning poker, described in my last post, helps the team to arrive at the story size estimate.)

Second, team members multi-vote (with dots or some other voting method) on the items they think will have the highest beneficial impact once implemented. We notice the pattern of votes, and write the total votes for each item on the list.

Finally, team members vote one more time. This time each person checks-in on his or her own levels of interest in every specific idea, and votes for up to two ideas that energize them the most. “What do you really want to make happen? Which idea(s) gives you energy?” They can vote twice for the same idea if their energy for that one is particularly high, or vote once each for two ideas.

When a team makes action planning decisions based on how much team capacity an action will require, what likely benefit they’ll get from it, and, most importantly, what they really want to make happen, things get done. Improvements happen.

So, if your team is plagued by “do nothing” retrospectives, go for maximum impact and follow the energy.

Stig Efsen, Trifork Scrum coach, invented a new way to help teams move the continuous improvement ideas from retrospectives into real action. In an “Agile Retrospectives” workshop last January, he showed our workshop group how to use Planning Poker for a list of ideas for actions.

As part of the Generating Insights part of the retrospective, we created a list of proposed ideas for action. When the list was complete, we played a quick round of planning poker for each item. Stig used cards with Fibonacci sequence numbers. In a relatively short period of time, the team had a shared understanding and a set of task point estimates for each action item.

Since then, I’ve used the technique in a number of short retrospectives. Sometimes I’ve used Fibonacci numbers and sometimes I use T-shirt sizes. It depends on what the team is used to or what seems like the best fit.

Once the team decides on the action or experiment they want to try during the next iteration, the point estimates make it easier to write up a card and carry it into the iteration planning meeting. Then the team includes the action as part of the “real work” plan.

About a year ago, I wrote post on FRIM, a new activity for gathering data for the work of retrospectives.

This is an update. Over the past year, I’ve had some new ideas and participants in our “Agile Retrospectives” workshop have provided their creative thoughts.

First New FRIM idea: Now when I use the FRIM activity, I draw the grid differently. The vertical axis has stretched up 5 points from neutral for a set of positive impact ratings. and stretched down 5 points for a set of negative impact ratings. (+5 = wildly beneficial impact, +4 = highly beneficial impact, +3 = moderately beneficial impact, +2 = some beneficial impact, +1 = more beneficial than neutral impact; 0 = neutral impact; -1 = more detrimental than neutral impact, -2 = some detrimental impact, -3 = moderately detrimental impact, -4 = highly detrimental impact & serious impediment, -5 = wildly detrimental impact & major impediment).

The horizontal axis of frequency changes with the length of the work increment. For a two week iteration, the ratings would include: A = rarely, fewer than once per iteration; B = about once per iteration; C = ~ once or twice per week; D = daily; E = many times per day; F = continously.

Second New FRIM idea: When I do FRIM on a single flip chart page, I’ve learned to use the smaller size sticky notes, 3″x3″ or smaller. When I have the luxury of recording it on a white board or a wall papered with butcher paper or multiple flip chart pages in an array, then I like the 4″x4″ sticky notes. Always the Super Stickies, 3M Post-it brand, when I can get them. Otherwise I keep a box of drafting dots for backup stickiness.

Third New FRIM idea: After the events have been posted on the grid, ask the group to stand with you across the room. Look back at the grid and see what patterns the team see from that distance. When that conversation slows down, move up closer to the grid and begin reading and seeking understanding about the individual notes.

I’m sitting at the Portland Bar Camp, listening to my friend Tony Deis from TrackersNW. He’s tell me about how he ran a outdoor camp for high school students using Agile practices. Tony said, “We got to the campgrounds on Sunday after a long drive. It was raining. We had an Umiak to build and a rotation schedule of activities for the campers. Bn Monday, I felt miserable. We were missing the kids and staff expectations for the kind of freedom and accountability we want for our camps.”

Then Tony had an idea. On Tuesday morning, he held a retrospective with the 22 campers and 8 staff members. They looked at how things had gone up until that point. The campers came up with a backlog of action items for the next day. Tony asked the opinions of the action leaders to discover what they needed - # of people, equipment, supplies - for each activity. When the back log was completed, the campers signed up for various activities - which included tasks like staying dry, gathering mussels and other wild food, cooking meals, cleaning up, help with farm chores, slaughtering and butchering a sheep, tanning the sheepskin and making tallow candles, and much more. Oh, and building the whale boat. I can’t type as fast as Tony tells me about this adventure.

From that moment on, each day camp started with signing up for the day’s activities. It continued with three stand-up meetings each day and a retrospective at the the close of day. During the stand-up meetings, campers identified obstacles and impediments, as well as transferring excitement for the activities they’d completed to other campers. At the end of each retrospective, they groomed their backlog for the next day.

By mid-week, the campers took over the stand-up meetings and retrospectives. The first camper-led retrospective was a bit rocky, and as they gained respect for the process, the very next retrospective was, as Tony says, “Smoking Hot!” As were all the rest. And, the campers were noticing how their empowered action at camp might fit for their student meetings at school.

Tony thinks that it was important that they had the same place to meet in each day, an old barn. So the meetings could happen out of the rain.

I wish I could convey Tony’s excitement. TrackersNW has incorporated a number of Agile practices in its own business administration. This is the first time they’ve moved on to using the practices in their programs. I suspect it won’t be the last.