1. Have a sharp problem statement

Get this wrong and you’re wasting your time. Focus on one specific, observable problem. Think about ways you could measure the impact of correcting your problem statement. If the problem is measurable, there’s a good chance that you have a problem statement that is ready to be analyzed.

2. Find the right people

A former manager of mine use to say “availability is not a skill.” Get participants who will have the context and experience to generate quality insights. Make sure you get a diverse group of participants that will view the problem statements from a variety of perspectives.

3. Make time for it

Like so many things in life, the objective is not to rush through the activity. Schedule enough time whereby participants do not feel rushed. Do the analysis in one contiguous block of time. Make sure that participants are giving their full attention to the matter at hand, and that they are not disengaging either physically or mentally.2

4. Make it Visible

Be vigilant for conversation that is not captured in writing. A team can easily get into a dialog about the problem’s causes and forget to capture insights that are mentioned. Don’t let potential causes get missed. Make sure that all the participants have a pen and encourage them to write their observations on the diagram. If you hear a cause mentioned that isn’t captured, stop the conversation, get it written, and then go on with the analysis.

5. Get a Facilitator

Last but not least! Find a neutral party that has facilitation skills that can engage with your team. A facilitator will be focused on the mechanics of the activity, allowing participants to immerse themselves in the actual problem that they are trying to solve. A facilitator is instrumental in helping bring out the voice of all the participants, and can guard against the conversation going down paths that are not focused on the stated problem.

Summary

Using a Fishbone Diagram to visualize a root cause analysis session can yield powerful insights. Give your efforts the best chance of success by setting it up with a solid problem statement, and investing in facilitation to shepherd the team through the analysis.

Please share your thoughts on what helps or hinders the effectiveness of a root cause analysis.

Additional Information

1. A Fishbone diagram is the result of an analysis in which a team of individuals articulates possible causes of a specific problem statement, and then enumerates the possible causes of that cause. The individuals involved continue to do this activity recursively until they identify candidate root causes. The visual that results from this analysis will take on a fish-like shape.
2. Esther Derby and Diane Larson have some ideas on how to “Check In” in their book Agile Retrospectives: Making Good Teams Great. The book is definitely worth buying. Make sure people check their distractions at the door, and that you have the attention required for the activity.

This week, Susan DiFabio and I presented on the topic of Agile Sustainability to the Chicago Agile Project Manager Meetup. The objective of the presentation was to have people leave the presentation with some ways that they could take action to make their Agile environments more likely to be sustained.

Click below to download the presentation and speaker notes.

Setup

Create a table with each team member’s name on the left column of each row, and the activities required to deliver the iteration work at the top of each column.

Make the charts big and visible. The more aware team members are regarding how they stand, the more motivated they will be to fill in the gaps.

Now let’s play the game

During the iteration, track the types of work that each team member contributes to meeting the overall iteration goal. To track the contribution, simply put a mark at the intersection of the activity and the person’s name. At the end of the iteration, look at the pattern that has shown up on your Activity Bingo board. If you are like some new Agile teams, the grid starts out sparsely populated (a holdover from siloed organizations).

Horizontal Bingo

As team members increase the number of ways in which they contribute to the team, your team may score a horizontal BINGO.

Vertical Bingo

Similarly as more team members swarm on specific activities and you develop real depth on the team, you may score a vertical BINGO.

Speed

If you want to try to build on the game, consider seeing how early in the iteration the team can end up with either a row or a column filled up.

Celebrate

Be sure to recognize the team’s accomplishments toward being a more effective team.

What techniques have you used to foster cross-functional behavior?

A special thank you to Susan DiFabio, Agile Coach, for co-authoring this blog. Thanks, Maria Matarelli, for your assistance in naming the game.

p.s. Check out another article on Agile teams, tasks, and limiting WIP.

Honestly, it doesn’t matters. If it helps an organization create value for its customers in a way that allows employees to experience freedom while solving challenging problems, it doesn’t matter what label the method carries! But, that would be too short a response.

Longer Answer

One way to decide if something should wear the label “agile” is to look at how it reflects the values stated in the Agile Manifesto. Of the Agile Manifesto statements, this is how Kanban values the “items on the left” over those on the right.

Individuals and Interactions over Processes and Tools

The visibility that Kanban provides to teams is a key contributor to facilitating interaction amongst individuals. The kanban board gives visibility to impediments that individuals are encountering makes resolving the impediment of prime importance.

Unlike Scrum, Kanban does not explicitly encourage generalization of skill sets. While Kanban does not force you to have a role for every queue, it is often easy to start by mapping the roles to queues and then inspect the bottlenecks and address those by helping the team develop more generalized skills.

Kanban is not a tool or a process that supersedes the importance of the individuals and their interactions. Yes, Kanban provides a lot of metrics that can be used to inform planning. However, the metrics are to facilitate interaction among team members, between team and stakeholders, and between team and customers.

Working Software over Comprehensive Documentation

When using Kanban to produce software, there are specific characteristics of Kanban that allow you to value working software over comprehensive documentation; small batches, WIP limits, measuring and managing flow. Perhaps your workflow will have a step or steps related to creating documentation.

Kanban does not prescribe working software, other than through mapping your value stream. If the last step in the value stream is working software, you can use Kanban as a tool to make sure you do that.

Customer Collaboration over Contract Negotiation

Kanban encourages customer collaboration through the prioritization of the backlog. Prioritization of the backlog is an ongoing process. Agile Kanban practitioners often use user stories or minimal marketable features (MMF). Use of either of these approaches supports customer collaboration in creating those items. The person who provides the detail on the stories or MMF is also available to the team to respond to questions.

As in Agile, daily standups are also present in Kanban. Unlike Agile, only people with issues speak in the daily standup. The standup meeting is an opportunity to speak up, whereas in Agile the traditional “three questions” are often present. This gives the team an opportunity to elevate issues to the Product Management representative’s attention, allowing them to be a partner in the process.

Silver Bullet Policy (see slide 20 for a brief overview) allows the customer to swap out an extremely high priority item for the current work in progress. There needs to be a swap so that WIP limits are not exceeded. Silver Bullet Policy may never be used, but can give the business the feeling that if there is an emergency, they can use this policy.

Responding to Change over Following a Plan

Agile teams often plan on a regular cadence. In Kanban, planning events can be triggered on an event. For example, your team may have a rule as follows: When the backlog backlog has dwindled to ten stories, a planning event will be held.

Unlike Scrum or XP, where the teams try to identify a piece of stability to work on for a period of time, Kanban allows the team to re-prioritize the backlog at any time and take something new off the backlog. This allows the team to respond to change sooner than if they were locked into a set sprint duration.

Summary

While Agile is primarily focused on software, Kanban is more focused on developing a lean organization . In fact, the business-oriented language that surrounds Kanban may make it an easier Agile model to embrace than Scrum.

While an organization or team can claim to be using Kanban and use it in non-agile ways, that will not be the case when done well. If the team and management use visualization, set WIP limits, and iterate on the value stream, Kanban is an excellent option for Agile teams.

Find More Information

There are lots of excellent resources on Kanban. My favorite reference is a book called Kanban – Successful Evolutionary Change for Your Technology Business. Thank you, Eric Landes, for loaning me your copy for a while. For further reading, check out the InfoQ version of the Kanban and Scrum Book.

A special thank you to Eric and Susan for co-authoring this blog.

Susan DiFabio, Agile Coach

Eric Landes, Agile Coach

It is free and open to entrepreneurial folks who register. So, register for First Monday at Innovation Park. See you there.

Please feel free to comment on other ideas for building community, especially if you have tested those ideas and have learned from it.

Here’s a technique you can try for limiting work-in-progress. Instead of identifying task ownership whereby team members write their name on multiple task cards, ask each to use a single PostIt note with their name on it. Each person gets only one note with his or her name on it. Let’s face it, even if you have more than one task in the “In Progress” column, you can only work on one at a time. The sticky note is to be placed on the task that is being worked on at that moment. The note is moved throughout the day when changing tasks.

Here are some benefits of this approach:

Token to help address too much WIP

1. Only one task can be claimed by any individual.
2. The team now sees exactly who is doing what work at any moment.
3. The team sees which tasks that are “In Progress” but not being worked on.
4. Knowing what each person is working on makes it safer for team members to begin work on idle tasks.
5. By no longer staking your claim to a whole set of tasks, you invite more collective ownership of completing the team’s work.

In addition to simply putting your name on a single sticky note, you could also capture data about context switching with this simple method. Write the date on your token. For that day, put a tally mark on the note each time the token moves from one task to another.

By using the date and tally marks on the card, you can get a sense for how much context switching is happening throughout the day. Perhaps thrashing is an impediment for your team. Of course, if you switch tasks six times and 5 tasks are completed, you probably don’t have a problem. If you switch six times and nothing gets to “Done,” there may be an impediment’s root cause to search for. Collect the notes throughout the iteration and look for trends in the data.

I hope you find this technique useful. Feel free to comment on the post.

It’s Friday night, and I’m traveling home from San Francisco where I had a great experience at the inaugural SFAgile conference.The conference had high quality speakers, most of the speakers were also able to stay for the duration of the two-day conference. Not only did I receive a lot of value from the formal sessions, the conversations outside of the sessions were particularly valuable(See note 1 below).

SF Agile was an intimate, single-track conference that covered a breadth of topics, including Lean Startup, Lean UX, Teams and Product Stewardship, an Innovation Game, escaping timeboxes (new term materialized: “neo-post-agile”)… And that was Day 1!

Day 2 had topics that included  Agile Leadership, a panel discussion with audience-selected topics, lessons from Dr. Who, Coaching, the team/business bridge,  and happiness.  Although I neglected to put a mark on the “Value to Time Invested” retrospective chart (sorry Angeline), I will posthumously put it to “up and to the  right,” which we learned at the conference is where all good data on a graph goes.

Each day culminated in  a trip down Market street to Blu to socialize with other attendees. The conference’s size allowed for interaction with almost all of the attendees. This is the second conference this year that I have attended that had a single-track format( See Note 2 below).  I think I am a fan of the format. The single-track format creates a shared context for all the attendees. During breaks and after the day’s  formal activities, there is a common reference point that helps create cohesion as attendees can discuss a range of ideas presented throughout the day.

Thank you, thank you, thank you.
Thank you to all the sponsors for making the event very affordable for attendees.
Thank you for allowing me to share how lean principles and getting close to the customer and market were instrumental in shaping my path to being an entrepreneur.
Thank you Angeline and the rest of the folks who contributed to making this event a success. I hope to attend next year’s event.

For those of you who did not go to the conference, consider putting it on your calendar for next June.

Note 1. One example of the additional value was with Joshua Kerievsky’s who recommended the book The Secrets of Consulting by Gerald Weinberg, I actually had to put that book down to capture some of my reflections on the conference.

Note 2. KalamazooX was the other conference. That, too, was a valuable conference and I am way overdue to create a blog post about that. KalamazooX was a very nice one day conference focusing on the softer skills required in technology. Sorry Michael Eaton for the delay in writing about that conference. There was no flight home from Kalamazoo for me to draft it!

As the team begins to figure out what it takes to deliver a story, a team member says:

Some rights reserved by ginatrapani

“Well, we can figure out the steps the system will have to perform to complete the business logic. We also know what data table the result needs to go into. The Product Owner really wants this feature, but we’re not too familiar with the new programming language we are using and it would take too much time to figure it out. For now, we will put the logical steps into a Word document and have a developer follow the steps in the document and manually enter the result into the system we have to interface with.”

That would be absurd! No developer would ever utterer that in real life. The story can either get coded to meet the acceptance criteria within the desired timeframe, or it cannot.

Now, if you take that previous sentence and change it a little bit:

“Well, we can figure out the steps the system will have to perform to complete the business logic. We also know what data table the result needs to go into. The Product Owner really wants this feature, but we’re not too familiar with the automated testing framework we are using and it would take too much time to figure it out. For now, we will put the logical steps into a Word document and have a tester follow the steps in the document and manually enter the result into the test result matrix.”

Somehow, the “test” version of that paragraph isn’t only acceptable to a lot of teams, it’s incredibly common to hear. “We don’t have time to automate the tests.”

In reality, you don’t have time the luxury of not automating your tests. Manual testing isn’t sustainable; it is too expensive and it is too slow to execute all the logic present in your application. Because manual testing is not feasible, the buildup of untested code in your system present the biggest risk to almost any software development effort. (James Grenning recently articulated a strong case for why this is so at a recent Chicago Agile Project Leadership Network meeting.) That risk may not manifest itself today or tomorrow, but not too many versions down the road your team, your application, and your business is going to hit a brick wall of poor quality.

Automated testing cannot be optional. It’s the team’s responsibility to make sure that automated tests are being created. You don’t have to be perfect to get started; just start during your next Sprint. Next, inspect and adapt. Learn from others, get training, and make the investment. Perhaps you “complete” fewer features by not investing in automation, but remember… you would not call a story “done” if the code is not automated, so don’t call it “done” if the tests are not automated.

Stephen Covey’s second habit is “Begin with the End in Mind”. Before you can effectively create the physical manifestation of the product you want to create or the team you want to be, you have to first create a mental representation of that end state.

One exercise he proposes for helping to clarify what is supremely important to you is to visualize your own funeral. When you visualize your family, friends, or coworkers speaking about you after you have passed, what would you want people to say? As helpful as this visualization exercise can be for individuals to recognize what is important in their lives, it is also important for teams to determine what is important to them.

If an article were written about your team and preserved for the future, what would you want people to know about your team, about how you treated each other, and the way you went about your work? To help determine what is important to your team, consider your team’s ultimate goal. What do you want people to say about you, your team, and your work. Consider your teammates, your Product Owner, your stakeholders, and your customers. What about your functional manager? Consider involving your stakeholder community in the discussion.

Going through such an exercise can result in identifying a common view of what the team wants to become and how they want to operate. Without agreement on what the team values, the urgent demands of the project can keep you from becoming the team you need to become. Symptoms of teams without a compass may be that your team becomes myopic, focused on creating features to the detriment of sustainable pace or maintainable code. Alternatively, your team could become paralyzed by analysis and architecture debates, not recognizing when the analysis is sufficient to allow it to move forward.

To create your team vision is to “begin with the end in mind.” It is more than an elevator statement that captures the 30-second pitch for your product, and it is also more than a list of user stories that you intend to complete within a particular timeframe. What you want to distill from this exercise is a set of principles that can inform the decisions that you and your team will have to make through the course of your work. Take the information you collect and use it to create a mission statement for your team. When creating your mission statement, ensure the involvement of all team members; perhaps have a facilitated discussion led by somebody from outside the team can help ensure that all voices are heard. As Mr. Covey puts it: “No involvement, no commitment.”

Make your mission statement visible in your team room, on its wiki, give printouts to each team member, and anywhere else you feel is appropriate. If somebody is violating the mission statement, inquire about the deviation and determine if the mission statement has become outdated or if the behavior is perhaps not correct. Include a review of the mission statement as part of your retrospective.

Remember, if you are on an team and don’t know where you are going, you won’t get anywhere you want to be. Keeping the end in mind and using the mission statement as a team compass can help the team stay on track toward its desired goal.