An Example of a Self Organizing Team

After a recent presentation where I talked briefly about self organizing teams, someone came up to me afterward and said (I'm paraphrasing) "That team stuff is great and all, but some people are just lazy and need to be told exactly what to do and when." Argh.

But before you judge that person, let me tell you a story. In this true story you'll have the opportunity to judge me for having the same thoughts before trying a different approach. This is the story of my self organizing daughter.

My kids go to a great school - the kind of school that fosters engaged teachers who go the extra mile to create engaged students. Throughout the school year the teachers run numerous clubs before school, at lunch, or after school including run club, football club, circus club (complete with unicycles!), reading club, wrestling club, girls club, gymnastics club, etc. My kids love attending these clubs and my oldest (aged 10 during this story) was determined to be in every one of those clubs.

This is great, except there were a few problems. Many of the clubs started before the school day so she had to be ready and out the door pretty early. Since most of the clubs had a strict attendance policy (if you miss two days, you are out of the club), being on time was important. Further, because of our cold winter weather, she received a ride on many of the mornings with one of her friends. If she was late getting out the door, her friend also risked being late and missing out on the clubs.

So, being the responsible parents that we are, we nagged her out the door each the morning. "Time to get out of bed", "Have you brushed your teeth yet?" "Go comb your hair",  "It's time to make your lunch now!" "Hurray up, you're going to be late!" It made for some pretty frustrating mornings for all of us. We treated her exactly as the statement above: "some people are just lazy and need to be told exactly what to do and when." She would do the task we asked her to do and then wait to be told what to do next. Looking at it now, she was disengaged and dis-empowered. I cringe at the memory.

While this was happening, I was reading the 7 Habits of Highly Effective People by the late Dr. Stephen R. Covey. I had my "Oh crap" moment when he said this:

"You cannot hold people responsible for results if you supervise their methods. You then become responsible for results and rules replace human judgement, creativity, responsibility...  Effective leaders set up the conditions of empowerment and then... get out of people’s way, clear their path and become a source of help as requested.“

After talking it over with my wife, we approached our daughter and apologized. We then discussed a new plan with her. Since she clearly was capable of getting out the door on time on her own, she would take over that responsibility. We would make ourselves available to be a source of help if requested but otherwise stay out of it. She jumped at the chance to take ownership of her morning routine. On the first day of this new arrangement she was ready fifteen minutes early and there hasn't been a day since then that she wasn't ready on time. Not so lazy after all I guess - just the victim of well intentioned managers.

After getting over my embarrassment, I pondered how this is a great parallel to self organized teams:

1. Status is known daily. We had daily status of her progress - if she was late she would miss her ride or be kicked out of a club. Our agile teams have daily standups, visual boards, frequent deliveries and demos so that everyone understands that status of the project at all times.

2. Agreed upon goals. She understood the goal (get out the door on time so that she can keep going to clubs) and desired to reach it. Self organized teams need to understand the goals of the project, not just the tasks to complete the project.

3. Freedom over methods. She started out being assigned tasks and moved to taking ownership of her own methods. Self organizing teams are given freedom to achieve the project goals and pull their own tasks rather than being assigned tasks.

4. Ask for help. She wasn't abandoned if she ran into trouble (oh no! I can't find the shirt that matches these pants!) - we stepped into help when asked. An effective scrum master, agile project manager, IT director, etc helps the team in a similar manner.

5. Empowerment brings results. This change turned a painful morning routine into a simple one because she was given the trust and responsibility to achieve the goal. When a team is given the trust and empowerment to accomplish the goal using their own methods, great things occur.

(Note :You can ready a similar story about Dr. Covey and his son entitled "Green and Clean")

How to create a User Story Map

User Story Mapping Series

* How to Create a User Story Map
* How to Prioritize a User Story Map
* Tips for Facilitating a User Story Mapping Session
* Don't Etch your User Story Map in Stone
* User Story Mapping Tool Review – SmartViewApp
* Story Maps - A Testing Tool After All

User story mapping is becoming a popular technique through the efforts of Jeff Patton and others that allows you to add a second dimension to your backlog. Here are a few reasons you should consider using this technique:

• It allows you to see the big picture in your backlog.
• It gives you a better tool for making decisions about grooming and prioritizing your backlog.
• It promotes silent brainstorming and a collaborative approach to generating your user stories.
• It encourages an iterative development approach where your early deliveries validate your architecture and solution.
• It is a great visual alternative to traditional project plans.
• It is a useful model for discussing and managing scope.
• Allows you to visualize dimensional planning and real options for your project/product.

Want to hear more? I talked about the value and use of User Story Mapping with Richard and Carl on show #750 of DotNetRocks.

To create your own user story map:

1. Form a group of 3-5 people who understand the purpose of the product. 3-5 seems to be the magic number. Any less and you might miss some ideas. If you add more people, it slows the process down and there are diminishing returns on the quality of ideas generated.

2. Start by gathering the major user tasks of the project/application in silence - the “things people do”. Each person takes the same coloured post-it and silently writes down one user task per post-it. Once everyone has finished writing their post-its, have each person read their post-its aloud and place them on the table in front of the group. If anyone has duplicates they should be removed at this point.

• Depending on the size of your application it can take 3-10 minutes to get all the major tasks, but you can watch the body language to see when they are done. You will see that the group goes from huddled in at the beginning to standing/leaning back at the end.
• Likely each post-it starts with a verb. (eg. Compose E-mail, Create Contact, Add User, etc)
• These are the high level user stories called “User Tasks” which forms the "walking skeleton" of the map.
• When they are done, point out to your team that in a few minutes they gathered most of the high level scope and that if they missed a user task or two, someone else probably didn’t. This might be their first ‘aha’ moment for silent brainstorming.

3. Next ask the team to group the post-its in silence. Simply ask them to move things that are similar to each other closer to each other and things that are dissimilar to each other should be moved farther apart.

• Use silent grouping simply because it is faster than grouping them out loud.
• If duplicates are found, remove them.
• Groups will form naturally and fairly easily.
• Once again, body language will help you see when they are done - usually 2-5 minutes.

4. Using another colour of post-it, name each group and put the post-it on top of the group. This step can be done out loud.

5. Arrange the groups left to right in the order a user would typically complete the tasks.

• If the group can't decide on an order between two or more tasks, it probably doesn't matter.
• The groups are called “User Activities” which form the backbone of the map.
• You should now have the first 2 rows of the user story map - something similar to this:

A1       A2    A3          (user activities = backbone)

T1 T2 T3 T4 T5 T6 T7 T8 T9 (user tasks = skeleton & timeline)

6. Now walk the skeleton to make sure you haven't missed any major user tasks or activities. You can walk through user scenarios, or even bring in users and ask them to walk through their job functions to make sure everything is accounted for.

7. With a finished framework for the map, you can add more detailed user stories below each user task before breaking your map into releases. I like to use the same silent brainstorming technique to generate the initial set of stories for each user task and augment it with other techniques such as user scenarios and personas. Once you have a good set of stories, then you can put your release lines in the map and ask your users to prioritize top to bottom.

• I like to put the first release line on the map pretty high on the map so that it only allows for 2-3 user stories per user task in the first release. This has been an effective way to encourage prioritization and scoping.
• Because all the stories end up on small post-its, you can forgo the traditional 'as a' format and just put the story title on the post-its. This will allow you to read the map a little easier.

8. Finally, I like to take all the user stories in the first release and do some serious user story slicing to make sure we have sliced the first release as thin as possible. As a guideline, you should strive to be able to create the whole app (at least one small user story slice for each user task) in the first iteration or two.

"An example would be handy right about now" (Brian Marick)

(click to enlarge)

Here is an example user story map for creating the next email client competitor:

• The second row contains the "things people do" in an email client such as Compose Email, Send Email, and Create Appointment. 
• The first row contains the groupings for those things people do. 
• The first yellow row is the smallest user story slice for each user task. For Compose Email, that means a basic form with To, Subject, and Body text fields plus Send and Cancel buttons. Functionality for RTF support, HTML support, adding attachments, getting email addresses from your contact list etc, are not included in this user story but are included as user stories lower in the map. 
• The small blue and orange post-its on the larger yellow post-its indicate the status of that user story. The blue ones say "done" and the orange ones say "wip" so that you can see your project status flow down the map.

If we now build the first row left to right before working on any stories in the rest of the map we can deliver all of the basic functionality quickly. This enables us to validate our messaging architecture (i.e. Send an email and then make sure you can Read it). It also allows us to test all the basic functionality in the application end to end so that we can make sure it all works together while getting feedback on whether or not it will solve the business problem. If we were building the very first e-mail client, we could release to the public at this time. Notice also that we did not have a user story for "Delete Contact" in the first release - we don't need to deliver functionality for each "User Task" in each release.

Finally, some definitions:

(click to enlarge)

• The post-its you create in Step 2 are the User Tasks (blue post-its in the diagram). 
• The groups and group names in steps 3 and 4 are the User Activities (orange post-its). Jeff calls these top two rows the backbone and walking skeleton of your application. 
• The user stories (yellow post-its) are organized under each User Task in order of highest to lowest priority for that User Task. 
• The chronological order of how users will typically use the application goes left to right (Time).

Subscribe to Winnipeg Agilist by Email

Agile Chartering - an Agile Documentation Alternative

Last spring I wrote two posts about agile documentation (Part 1: Introduction and Part 2: Guiding Questions) and asked you to consider this statement: 

"A document isn’t the only vehicle for expressing or transferring good thinking and ideas."

Recently I coached a team that was converting an application from VB6 to VB.Net. One of the challenges of the project was to agree upon and define the rules for when to fix the old code, when to just get it working, when to re-write whole sections, etc. One method to gain agreement on this approach could be to schedule a series of meetings and write up the conversion rules and strategies in the project charter document. Here is what we did instead:

Using a variation of the silent brainstorming technique we spent about 20 minutes creating a light weight conversion manifesto we could all agree upon. As you can see, we had some fun when we named the groups. The manifesto was 'documented' using an easel pad, post-its and sharpies. We placed it on the wall in the team room and referenced it often throughout the project. Situations we could not have documented up front surfaced during the project and were discussed quickly while referencing the post-its. This light weight manifesto served as a great vehicle for expressing our good thinking and ideas.

A meeting and a word document could have accomplished this as well, but not in the same amount of time, with the same effectiveness, or with the same mirth. In addition this is a great team building experience for teams that already have enough experience with long meetings and longer documents.

For more ideas on how to streamline your project chartering, take a look at this new book by Diana Larsen and Ainsley Nies: Liftoff: Launching Agile Teams and Projects

---

FYI - here is a quick explanation of the manifesto:

Image Via ThunderBoxRoad.com

"Hold your nose, just get it working!": Yes, the existing legacy code isn't beautiful, but it works and the users are happy with the functionality. We focused on delivering the functionality as is without any modifications unless absolutely necessary. (see “If you have to pass gas, fess up”). This included ignoring existing known issues and defects.

"If you have to pass gas, fess up": In the rare occasion that code or design must be changed, you must discuss and gain agreement with the team before doing so. Any issues or resolutions that come up must be shared with the team.

“Don’t paint the outhouse”: We are going to be making changes to the application after we deploy the .Net version so there is no need for a fresh coat of paint at this time. No UI "clean-up" is allowed except for minor formatting issues and we won't do any re-factoring unless absolutely necessary.

“You can’t get out of the mob unless you get out of the city”: We used VB Migration partner to do the initial conversion to VB.Net. The tool was a big help to speed up the project but some of the converted code is a little ugly and the team wanted to dive in and fix it all right away. If we were to focus on fixing the ugly code now it would not deliver value to the user – just less ugly code. So we put our focus first on converting the code and getting it live (i.e. getting out of the city) so that we could leave the mob behind in later projects as we replaced parts of the system.

Subscribe to Winnipeg Agilist by Email

Agile's perspective on failure

In the fall of 2011 I did some research regarding agile and failure for a presentation at Much Ado About Agile 2011 in Vancouver. The research was focused by a blog post by Philippe Kruchten describing some of the agile elephants. He listed "commercial interests censoring failure" and "using Elitism as a defense (against failure)" as two of the elephants. I consulted my brother-in-law Dr. Jason Ediger who is a psychologist to learn a bit more about the psychology of failure. After a brief explanation of what agile is, he responded with this:

"The assumption of failure is built into the agile process. The traditional method is built on the presupposition that we can plan failure out of the process. We don't have to test for it because we've taken everything into account. Agile assumes that humans are going to fail. By it's very nature, agile can't ignore (or censure) failure. If the accusation is that agile suppresses failures, then by definition - that is not agile. If agile is done properly then it can't* fail because it tests for failure all along. If you suppress failure, you guarantee it. Agile has a different perspective on failure. It doesn't see failures as catastrophic, but as expected. That difference in perspective allows us to celebrate failure rather than suppress it."

Pretty interesting comment don't you think?

Agile tests for failure all along in order to succeed. We aren't hoping for, or even planning on failure, but we do test for it regularly by delivering frequently, having daily stand-ups, keeping project status visible, etc. We do all this so that we can discover and react to our failures quickly in order to succeed.

Subscribe to Winnipeg Agilist by Email

Agile is simple but not easy: advice for agile beginners

As we prepared for yesterday's user story mapping session at Agile Winnipeg, Jon Labun and I reflected on agile stories that we've been a part of or heard about. A common theme emerged - agile is simple but not easy. We touched on this in the presentation and argued that user story mapping should be a central part of your agile practices in order to make many things 'easier'. Many agile stories start off well with organizations and teams wanting to give agile a try, but then fail to put in the investment to understand what being agile is about. The teams assume that agile is simple but lack the knowledge of how all the pieces fit together and end up running a project that is just an agile facade - agile words on the surface, but traditional methods (or no methods) underneath. It isn't the fault of agile that the projects end up in trouble or fail. 

Some common problems:

• Unending backlogs that are hard to visualize and prioritize
• Definitions of done that don't include testing & deployment
• 20 page requirements documents for one user story
• Incorrectly assuming that agile means 'no planning'
• Planning at the task level vs. the story level
• Testing after development is done rather than throughout the project.
• Out of control scope
• Out of control change management
• Never ending projects
• Significant quality issues
• etc

If you are beginning your agile journey then welcome to the club! It can be a lot of fun and very rewarding. But please, please, don't start without gaining some knowledge first. The agile community has a good head start on you and can help you through some initial hurdles to make your 'simple' journey a little easier. Please do read some articles and books, listen to podcasts etc, but your best learning will come from interactions and conversations with others who are further along the journey. Here are two important pieces of advice for you:

1) Find your local user group and support it with your attendance. Bring real questions and ask the group to help you find some answers. If you are in Winnipeg, visit www.agilewinnipeg.com. If you are elsewhere, consult the Agile Alliance's list of local user groups.

2) Attend conferences. Many of the successful agile teams I know point to ideas and practices they learned at conferences as crucial steps in their organization's agile journey. But don't expect to only 'attend' sessions - plan to interact with the audience and speakers during the sessions and also over lunch, dinner, drinks, or even indoor sky diving. There are several great conferences you can attend, but I'll highlight one in my region - PrairieDeveloper Conference in Calgary, Alberta from March 12-15. Regardless of your location, this is a can't miss conference with 80 sessions + full day workshops. See you there?

To paraphrase Mike Cohn, the agile community has helped me up my game - now up yours.

* P.S. Prairie Developer Conference is more than just agile of course, bring your whole team, your IT pros, your managers, etc.