This year the SF Agile conference  is being produced by two good friends of mine – Angeline Tan (@agilemeister) and Mike Sutton (@mhsutton) and they opened up the program using a crowd sourcing model.  Anyone who had a topic they wanted to speak about were encouraged to submit their session using IdeaScale and then other interested participants could comment and vote for the sessions they felt should be included in the program.  I helped the conference in a couple of ways – was a reviewer of sessions, my business made a donation to help sponsor the event and I helped arrange Jim McCarthy to be the keynote speaker on June 5th.

Finally, San Francisco is just an awesome city and the conference venue is right on Market Street in downtown San Francicso.  It just cannot get any better than this, so please register and join in on the fun!

Related posts:

1. Speaking at PMI San Diego Conference – May 13th & 14th
2. Upcoming Conferences
3. Speaking at Orlando Scrum Gathering – Mar 9th 2010

One of the concepts from TFBR that I had overlooked, but was reminded again when working with Andrea, was the importance of Accelerated Learning (AL).  AL forms the foundation of TFBR since it creates the community space where the learners can connect with one another and activate the all-important peer-to-peer learning.  The basic tenants of AL are:

• Learning involves the body as well as the mind.
• Learning is fundamentally an act of creation, not consumption of information.
• Learning takes place on many levels at once in the human brain and is not a linear, one-thing-at-a-time brain activity.
• Collaboration increases learning; isolation and competition decreases it.
• Learning occurs through active doing, with time for reflection and feedback not passive listening.
• Positive emotions and mental imagery improve learning; the lack of both inhibits learning.

In the Resources section of this site, I have added a mark-up which describes AL and shows how Sharon Bowman has linked these concepts to the 4C’s from TFBR.  Please feel free to use this document if you need to provide an overview of the AL and the 4C’s.

No related posts.

1. Visionary – has a specific point-of-view and is passionate about what they see as the future for their team and organization.  As a visionary, a ScrumMaster could be an evangelist or an individual who possesses the calm confidence of knowing what they really want.
2. Facilitator - while a ScrumMaster must have a point-of-view of vision, when they work with a self-organizing team they must be neutral.  When they are acting as the facilitator, they create the space for collaboration and self-organization to occur and refrain from providing content.
3. Leader – since the ScrumMaster works in the space of “no authority”,  they need to draw followers to them through the power of their ideas, the strength of their conviction and the ability to communicate their vision.
4. Mentor – one of the strengths of a ScrumMaster is that they care and respect the people they come into contact with each day.  In order to excel as a mentor, a ScrumMaster devotes much of their day building genuine, personal relationships with everyone they interact with.
5. Teacher –  ScrumMasters need to possess a deep understanding of Scrum, be knowledgable on the current set of Agile variants (XP, Crystal, DSDM, Kanban, Lean for Software, etc.) and provide thoughtful answers on how to apply Scrum outside the lines.  I expect a ScrumMaster to be comfortable explaining Scrum in a variety of ways, in a variety of forums, to variety of roles and to a variety of people with different levels of understanding about Scrum and Agile.
6. Coach - sometimes people need “an answer” and sometimes people need help finding the solutions to the challenges on their own.  A skilled ScrumMaster knows the difference and can regularly create effective coaching conversations which produce actionable results.
7. Change Agent – Scrum is much more than a set of activities or practices we do at work.  Scrum is about change.  As a change agent, the ScrumMaster brings change to all parts of the organization and socializes the impact of change with stakeholders.
8. Expert Communicator – Scrum is about having the more interesting conversation, the conversation that we need to have and about fostering a dialogue about how to improve.  To support this, the ScrumMaster must model the crucial skills necessary to start and maintain dialogue.

One of the things we noticed in our conversation was this role of ScrumMaster does not exist in organizations today and many of these roles are in conflict with one another.  In most businesses today, there is no one person who does all these things.  Some people might do some of these activities sporadically but no one does all of them all the time.

Related posts:

1. How I Became a Certified ScrumMaster

I have a lot of interest in helping the Spanish speaking Scrum community grow and there is\was a complete lack of books on Scrum written in Spanish or English language books that had been translated into Spanish.  Now no more!  Earlier this year I published a Spanish translation – Catorce Observaciones para la Práctica de un Buen Scrum - of my book.  It was a lot of work, but now there is a high-quality book on the subject for Scrum for my Spanish speaking friends.  My translator, Diana Perez, was awesome and did a great job.

Finally, I want to thank Chris Sims at Agile Learning Labs for inspiring me to write my own book on Scrum plus explaining to me how easy it is to publish a book on your own.  Without Chris’s inspiration, this book would not be widely available.

Related posts:

1. Writing Good User Stories
2. Reading List (1st Half of 2010)
3. Scrum Gathering Amsterdam – Nov 15th to Nov 17th

The Perfection Game has two main gains.  One, to achieve perfect results by thinking and telling one another what you like and what would make the results perfect.  Two, to give feedback to another that is an affirming learning opportunity.  Since the Perfection Game comes from the Core Protocols, there is a very specific way it is played.  Here are the rules:

1. The requester asks a responder(s), “Will you play the Perfection Game with me?”
2. Next, the requester asks, “On a scale of 1 to 10, how would you rate [the item, action or event being considered].”
3. The responder tells the requester what was good, or what they liked, about the requester’s item, activity or action that earned the score in the form of “What I like about it was [a… b… c…].”
4. Next, the requester ask the responder, “What would have made it perfect?”
5. The responders then tells the requester what specific actions are needed in the next iteration to make the item, event or activity perfect in the form of “What would have made it perfect for me was [x… y… z…].”
6. Finally, the requester looks the responder in the eyes and says “Thank you.”
7. Repeat steps 1 to 6 for all responders.

As I stated earlier, following the protocol described in the Perfection Game is extremely important.  Purely or partially negative feedback (“constructive criticism”) is not allowed at any point in the Perfection Game.  As a responder, you must give the feedback to the requester verbally – there is no written feedback allowed.  If you cannot think of anything that will help the requester improve, the default score in the Perfection Game is a perfect 10.

A word about the scale in the Perfection Game – the scale of 1 to 10 is not about dislike to like, where 1 is “completely dislike” and 10 is “completely like”.  Rather, the scale goes from “the object has no value” to “I can’t think of anything that would make it better”.  Keep in mind that as a responders if you give something an 8, you are saying that it is 80% perfect and as the responder you can tell the requester exactly what they need to do in order to gain the missing 20%.

Finally, Jim and Michelle McCarthy also have a very interesting podcast discussing the origins of The Perfection Game and how they think about it.  Be sure to check it out and start playing the Perfection Game.

Related posts:

1. You’re Invited!! – An Agile Game

The most visible benefit of my collaboration with Karen was for me to “4C” my training plan for my CSM course.  4C is an acronym that stands for “Connection, Content, Concrete Practice, Conclusion” and they are framework for an instructor to help design their class that  leverages TFBR and Accelerated Learning.  The 4C’s are described in more detail below:

• Connections: This is the beginning or opening of a training.  It can also include pre-training time as well.  During the Connections step, learners make connections with what they already know, or think they know, about the training topic.  They also make connections with what they will learn or want to learn with the other learners in the training group, and with you, the trainer.
• Concepts: This is the direct instruction, lecture or presentation part of a training,  During the Concepts step, learners take in new information in multi-sensory ways: hearing, seeing, discussing, writing, reflecting, imagining, participating and teaching it to others.
• Concrete Practice: This is the active review that usually follows information delivery.  During the Concrete Practice step, learners actively practice a new skill using the new information, participate in an active review of what they have learned and again teach others what they know or can now do.
• Conclusions: This is the wrap-up or closing part of a training.  It can also include post-training time as well.  During the Conclusions step, learners summarize what they have learned, evaluate it, make a commitment to use it at work or in their lives and end with a short celebration of their learning experience.

From my experience with Karen and applying the 4C’s on my own, the framework offers instructors two powerful advantages:

1. Your course immediately becomes modular.  Each learning objective  is achieved by connecting the learners to the topic, teaching them content, allowing them opportunities of concrete practice to try out the material on their own and closes with a conclusion before moving to the next learning objective.  Your course then becomes just a series of 4C’s that knocks down one learning objective after another.
2. The 4C’s provide a fantastic diagnostic tool to help you improve your course.  Since the class is now modular, if a connecting activity is not working, you can switch it.  Content section is too long?  Move to concrete practice sooner.  As instructor, I felt that I had really good content and concrete practice exercises, but my courses were weak on connections and conclusions.  Look to Sharon Bowman’s book – The Ten Minute Trainer – for over 150 exercises and activities that help with these areas..

Related posts:

1. Training From the Back of the Room
2. Accelerated Learning
3. Why I Want to be a Certified Scrum Trainer

I want to send a special thank you to my hosts for the evening Carolyn Sanders and Stephen Reed (@ScrumMasterNZ).  They completely took care of arranging for the venue, meeting me and taking me out for drinks afterwards.

Related posts:

1. Agile 2011
2. Agile 2009: Distributed Agile Development
3. Agile Transitions Workshop

1. Powerful Questions – this was one of the largest sessions about Powerful Questions that I ever ran.  I think there were more than 40+ people in the room and people were standing along the walls.  Even though it was a large group, I felt the interaction was good, the main points were communicated and the participants “got it”.  There are two good write-ups on the session from Kenji Haranbe (the stage manager) and Sam Laing.  For more on Powerful Questions check out this really great PDF  from The World Cafe to get you started.
2. Removing Impediments with Drawings – this session is based on Dan Roam’s visual framework, Back of the Napkin, as a way to share ideas that stick.  This session was HUGE!!  When I walked in the room, I immediately knew I did not have enough materials for my session – I had brought enough materials for 70 and I needed about 50 more!  At some point, I had to tell the proctors that we cannot accept anymore people and I know some people were angry about that.  Since the room was so large with so many people, it was not as interactive as I hoped and the next time I run this session, I would have a co-presenter.  Craig Smith wrote up a really great review with awesome pictures on his blog.  Thanks!!

Next year, I will remember not to spend so much time with consulting work while at the conference.  I felt like I spent the whole time on conference calls, did my sessions and then went home.  Not that much fun

Related posts:

1. Agile 2009: Distributed Agile Development
2. Agile 2009: Debugging Pair Programming & Impact of Gender
3. Upcoming Conferences

1. PMI San Diego Annual Conference – On May 13th, I will be giving a class on Estimating and Planning.  On May 14th, I will be giving a short tutorial on how to use Innovation Games to prioritize.
2. San Francisco Agile Conference – my colleague and friend, Angeline Tan (@agilemeister), invited me to be a speaker at this conference she has been working very hard to organize.  On June 16th, I will be presenting Improve Flow Through Prioritization.

You can still register for both the PMI San Diego Conference and San Francisco Agile Conference.

Related posts:

1. Mike Cohn at XPSD
2. Speaking at PMI San Diego Conference – May 13th & 14th
3. Lean and Agile: Roommates, Married or Twins?

For those who do not know, stories are a lightweight artifact that allows us to both capture the business’s needs AND plan the work.  They are typically written on index cards (yes…little 3×5 or 4×6 cards) in the language of the business or customer.  With user stories, we only write enough to capture the user’s needs and no more.  We tend to view stories not as complete specification of the requirements, but as placeholders for later conversations between the developers and the business.

When used properly, a user story’s lack of detail provides us a great deal of utility – we can use the same document to talk about a requirement from a high-level, zoom in on implementation details and jump back out, all in the course of a few sentences.  Then once we are done talking about requirements, we can consider risk, identify dependencies and create a project plan without ever having to put down the index card.  Wow !!  I know of no other requirements artifacts out there allows us such utility.

Over the years people who are really successful with stories have settled on some commonalities found in all stories:

• Role: who, or what, is going to use this feature?
• Feature (or capability): what is the Team going to deliver, or add, after they finished their work?
• Value: why does the business even want this feature?  What impact to the business will it have?
• Acceptance Criteria: how will we know if this feature is done?
• Estimate: how much does the Team think this feature will cost?

IMO, in order for a story to be considered complete it has to have ALL the characteristics described above.  I find that when people have trouble with defining all the characteristics, the stories are not what I call ripe, i.e. they have not been thought through well enough to be usable by the Team.  In addition to these characteristics, stories also should follow the INVEST criteria (this great article by J.B. Rainsberger talks about INVEST as well).

Mike Cohn has written a great book on user stories.  Unfortunately, for all the goodness in the book, folks seem to have focused on the one bit of junk in the book – the user story template.  In his book, Mike offers up a template some teams found helpful with writing stories and from there this template has been the source of so many bad stories that I am not going to give it anymore more ink (or bits).  What I object to about the template is that it causes people to stop thinking as they mechanically fill in role, feature and value and omit acceptance criteria and estimate (presumably because they are missing from the template).  When I see people struggle with stories, it is because they are trying to jam their business into some template that helped some unnamed team  (who probably doesn’t even use this template anymore) five or six years ago and – surprise – it doesn’t fit where they are right now.

There is a thinking process that needs to occur before you write a single story.  The steps I tend to see people completing who are successful writing stories are listed below.  Please keep in mind, while these steps are linear in my post, one can jump back, forward and skip around as it makes sense.  The goal is to have answered these questions by the time you have finished your user story exploration.

1. What are the roles (or users) that will use your system?
2. What are their needs?  How does the product help them accomplish that?
3. What features (or capabilities) do you want to provide these roles?
4. Why are these features valuable to the business?  What sorts of business outcomes can we expect from these features?
5. What are the priorities of these features?  Did we make a promise to deliver some already?
6. How would you know if these features are done?

Finally, people have a tendency to want to write a lot of details on the front of the story card.  I have two suggestions for these people.  First, use smaller cards – really.  User stories are NOT specifications or requirements documents.  They are just index cards capturing the user’s needs and reminders that we have to capture those implementation details later.  If you are trying to cram more and more onto an index card, that might be sign that you may need specs or some type of design documentation in addition to user stories.  Second, the types of details that people are trying to write down are actually acceptance criteria.  By pushing those details into the test cases, we keep the story in the language of the business and retain the focus on the feature and value your Team is providing.

Related posts:

1. Saying Good-bye
2. Agile 2009: My Greatest Coaching Mistakes 2000-2009
3. Fourteen Observations of Good Scrum Practice