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

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

In Sprint #4, the scope of the release increased by thirteen units (the yellow bar) and the Team only completed three units of added functionality.  In the figure, one can see the velocity of the Team increased during Sprints #5 and #6, completing twenty and twenty-one units of work, respectively.

At the end of Sprint #6, it was clear the scope of the release was too large for the Team to complete before the deadline.  The Team’s velocity of twenty-one units per Sprint and the concept of yesterday’s weather, indicated the Team would not burndown all the remaining work before the end of Sprint #8.  As a result of this data, twenty-five units of low business value Product Backlog items were dropped, or descoped, from the release by the Product Owner.  When Sprint #8 was completed, nine units of work remained, but it had marginal business value.

Related posts:

1. Using a Sprint Burndown Chart
2. Agile 2009: Advances in Release Planning
3. Focus on Adding Value, Not Features

Want to unlock the creativity of your teams?  Would you rather guide your team members through their own thinking process rather than lead them down your own?  At the October breakfast meeting, Carlton Nettleton will describe the powerful question technique, how to ask powerful questions and why these open-ended questions are key to creating high-performing, collaborative teams.

You do not need to be a member of PMI San Diego to attend, but they request people to sign-up in advance.

Related posts:

1. Speaking @ Agile San Diego on Oct 7th
2. Speaking @ Agile San Diego on Oct 7th
3. Speaking @ XPSD on Sept 3rd

Are you just getting OK results with Scrum?  Has Agile not delivered on the much anticipated quantum leads in productivity everyone had been promised?  One common source of lackluster performance comes from following routine behaviors and ordinary patterns of teamwork associated with the “old way of doing things”.  In this hands-on workshop, Carlton Nettleton will share powerful techniques from his coaching toolbox that breaks these old patterns, unlocks the potential of Teams and gets them moving toward high-performance.

This is going to be a fun evening and a bit experimental since I am going to leave the main learning objective up to the participants.  I will also be giving away a free copy of Lyssa Adkins’s excellent book, Coaching Agile Teams.  Come to The Linkery, have a few drinks and learn something new!

Related posts:

1. Speaking @ Agile San Diego on Oct 7th
2. Speaking @ USC Code Camp – Oct 23rd & Oct 24th
3. Speaking @ XPSD on Sept 3rd

Stop by if you are looking to do something different, have a little fun and say hello!

Related posts:

1. New Offering – Innovation Games®
2. Agile Games @ XPSD Jan 13th
3. Speaking @ XPSD on Sept 3rd

1. Understanding A3 Thinking – excellent description of how to use and create an A3: a Lean tool for executing Plan-Do-Check-Act (the Deming cycle).  This is the definitive source on A3, Henrik Kniberg has an Agile example and template on his site.
2. Getting the Right Things Done – good description of the concept of True North, developing strategy from True North and the respectful nature of Lean, the rest is kinda dull.
3. Pedagogy of the Oppressed – unique perspective on the characteristics of oppression, the oppressed and the oppressors; liberation for both the oppressed and the oppressors originates when the oppressed become fully engaged in the human dialogue of being, not simply exchanging roles with the oppressors.  Interesting connections to corporate life in the 21st century.
4. Project Retrospectives – discussion on the importance of making a deep-dive examination of a software project when it finally is complete with detailed exercises and agenda.  This is great book if you want to know more about retrospectives.
5. More Secrets of Consulting – just brilliant!  If you liked the first book, this one has so many practical gems for the consultant.  The only tedious parts of this book are the references to his other books.  My favorite tool: the Wishing Wand.
6. The Future of Management – this book was a favorite of the CEO at my last client.  There are many Scrum concepts in the case studies provided.  Too bad that many of the principles of self-organization and empowerment supported by the executives never filtered down to the teams
7. Coaching Agile Teams – WOW!  This is an awesome book, deep and rich with many profound insights on the various roles of an Agile coach.  In addition, Lyssa provides practical tools to improve both the coach and the individual.  This is definitely a book to return to again and again.
8. Training From the Back of the Room – this is my favorite book from the last six months since it has had the most impact on my personal performance.  It has changed my perspective on how to train adults with its sound theory of education and myriad of exercises which bolster learning.  Share this book with anyone who trains adults (thanks to “Agile Bob” Hartman for tweeting this book title!)
9. Practices for Scaling Lean & Agile Development – comprehensive companion book to Scaling Lean & Agile Development (which is very good on Lean and Scrum).  This book is full of good stuff, but just too long.  Unless you are a guru (or wanna be), stick with the first book.
10. Succeeding with Agile – Mike Cohn has put out another great book based on his years of practical experience with Scrum.  This book is also pretty long, but not tedious.  A great read if you have some experience with Scrum, but want to improve the overall experience, apply targeted improvements or figure out how to expand the reach of Scrum in your organization – it covers it all.
11. The Back of the Napkin – provides a framework on how to apply visual thinking tools to explain and sell ideas.  Since most of the work I do is conceptual, being able to draw a powerful picture is a useful skill.  A nice addition to my consultant toolkit and I look forward to sharing it with others (I didn’t find the companion book that useful, so skip it).
12. Hitchhiker’s Guide to the Galaxy series (not pictured) – these books were consistently entertaining, surreal and light; most were less than 200 pages.  The pace slows down around book 3 (Life, the Universe and Everything), but delightful nonetheless.  I cannot believe I just discovered them in my mid-30′s!

Believe it or not, there are a few books I did not get a chance to read.  I guess these will have to wait until after vacation.

• Leading Out Loud – about finding your authentic voice in business.  I bought this to get some ideas about leadership and self-organizing teams.
• Hope is Not a Strategy – I need to understand the sales process better and improve my ability to sell.  This looked interesting.

Related posts:

1. Best Links of the Week – July 2nd 2010
2. Best Links of the Week – August 13th 2010
3. Reading a Release Burndown Chart

1. The Zen of Scrum – Jurgen Appelo provides a 70-minute video overview of Scrum, roles and philosophy.
2. The Difference Between Waterfall, Iterative Waterfall, Scrum & Lean (in pictures) – Visual representations of these various processes.
3. Company Culture Affects Your Code – A short examination of influence of Conway’s Law and culture on your software projects.
4. Explosion of Agile Practices – A list of 50 or so common practices used on Agile teams.
5. My Progression Toward Kanban – Brian Doll provides a good overview of Lean software development techniques and his personal journey there.
6. Post Agile Companies – Cory Foy looks at three Agile organizations and explains why understanding the Agile principles and values is more important than doing the Agile practices.
7. How Great Leaders Inspire Action – Simon Sinek describes a simple model to inspire others in this 18-minute video from TED.
8. Iterative and Incremental Development – Explanation of the difference between incremental vs. iterative software development (IID) and the history of IID.
9. Why Estimate Twice? – Good overview on the common practice of estimating the size of features, while estimating the duration of tasks.

Related posts:

1. Best Links of the Week – July 30th 2010
2. Best Links of the Week – July 16th 2010
3. Best Links of the Week – Feb 9th 2010

1. Large-Scale Agile - Jim Shore talks about the seven factors to consider when trying to make Agile large.
2. What is the One Thing You Can Do to be More Agile? – various vendors at the Agile 2009 conference provide their answer to this question during this five-minute video.
3. Intro to Scrum Video – Bob Hartman and Arif Gangji provide an eight-minute video overview of Scrum.
4. In Praise of Middle Management – this article explains how leadership from middle managers is essential for driving change brought on by Scrum.
5. The Role of Test Manager in an Agile Organization – Johanna Rothman talks about how Agile transforms the role of Test Manager from one that schedules resources to that of coaching, removing obstacles and building organizational capacity.
6. 78 Things I have Learned in 6 Years of Agile Coaching – Jean Tabaka shares her accumulated wisdom about Agile and change.
7. Top 10 Questions When Using Agile for Hardware Projects – In this interview, Larry Maccherone discusses how Agile is applied on software-hardware projects.
8. You’re Just Going to Fail, So Don’t Bother – Scott Downey, Scrum Coach at myspace, discusses why Scrum is so difficult for many organizations and identifies the six hard truths you eventually confront when using Scrum.
9. Agile Roots – A Personal History – Jim Highsmith, a signatory of the Agile Manifesto, discusses the origins of the Agile movement.
10. The Wrong Lessons from Toyota’s Recalls – and the Truth - Jeffery Liker gives his take on the Toyota recalls and what they say about Toyota’s highly touted manufacturing process.

Related posts:

1. Best Links of the Week – August 13th 2010
2. Best Links of the Week – July 2nd 2010
3. Best Links of the Week – Feb 1st 2010

1. Pollyanna Pixton on Agile Leadership – a 30-minute video talking about the factors corporate leaders can influence which support Agile teams.
2. How I Learned to Program Manage an Agile Team After 6 Years of Waterfall – Sara Ford describes in brutal candor her experience becoming an Agile PM while working on CodePlex at Microsoft.
3. Explaining Agile – Mike Cottmeyer neatly summarizes his understanding of Agile.
4. How to Compare Elephant Herds - Dave Nicolette finally (?) explains why comparing teams through velocity is meaningless.
5. What Does a ScrumMaster Do? – for those of  you who are curious and wanted to know.
6. Replacing the Iron Triangle of Project Management? – short discussion on reevaluating a well-accepted PM paradigm.
7. Adopting Agile Development – the Role of the CIO – how senior leaders in your organization can help promote Agile adoption.
8. Moving Beyond Scrum – a look at some reasons why one might want to take the next step.
9. Tragic Mistakes When Adopting Test-Driven Development (TDD) - Scott Ambler discussing some pitfalls & obstacles companies encounter when they begin the process of using TDD.
10. Comparison of Open Agile with Scrum – introduction of a domain-independent framework for delivering value while using Agile principles via a compare-and-contrast with Scrum

Related posts:

1. Best Links of the Week – July 2nd 2010
2. Best Links of the Week – July 16th 2010
3. Best Links of the Week – Jan 12th 2010