Archive for the ‘Agile’ Category

• Speaking at SFAgile 2012

  Date: 2012.05.14 | Category: Agile, Conferences, Personal | Response: 0

  I wanted to let people know that I will be attending the SFAgile2012 conference from June 4th to June 6th.  On June 4th, I will be participating in a panel on the Pay It Forward program sponsored by a business partner of mine Conscires Agile Practices.

  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!

• Fourteen Observations of Good Scrum Practice

  Date: 2012.03.21 | Category: Agile, Certified ScrumMaster, Personal, Scrum, Tools | Response: 0

  My courses are deliberately designed to exclude PowerPoint presentations and focus on the peer-to-peer interactions, but I recognize that a significant number of students need something physical to take from the class and review later.  In addition, there is no possible way for me to cover every topic the same way in a two-day CSM class, so I needed something for the learners to refer to as a reminder on how to do Scrum well.  As a result, early last year I wrote a book on Scrum – Fourteen Observations of Good Scrum Practice – as teaching aid for my CSM classes.  From the learners I have spoken with, they find the book to be a useful summary of the main concepts in the class, a handy reminder of what we discussed and short introduction to Scrum that they can share with other people at work.  When you attend one of my CSM class, you receive a complementary copy.

  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.

   

• The Perfection Game

  Date: 2012.03.06 | Category: Agile, Communication, Scrum, Tools | Response: 0

  I recently came across an awesome and challenging book – Software for Your Head by Jim McCarthy.  There are so many interesting things about this book.  One of the key tools I discovered I can use right away while reading the book was an amazing tool to provide feedback called the Perfection Game.

  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.

• Visit to Auckland Agile

  Date: 2011.10.06 | Category: Agile, Presentations, Scrum, Tools | Response: 0

  Just finished a trip to New Zealand and had a chance to speak at Auckland Agile on September 29th.  The session was another run of my “Removing Impediments with Drawings” that I have presented numerous times in the past year (the most recent at Agile 2011 in Salt Lake City).  I am not sure exactly, but I think we may have had about 40+ people in this session.  A lot less people than Agile 2011 and I thought the outcomes were better.  Glad I had a chance to meet with this group and share some ideas that might not have made it to their part of the world.

  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.

• Agile 2011

  Date: 2011.08.20 | Category: Agile, Conferences, Presentations, Tools, Travel | Response: 0

  Wow!  Another Agile conference under my belt.  This year was a visit to Salt Lake City and two talks at the conference.  Both of these talks are continuations of my sessions from the Amsterdam Scrum Gathering in 2011.

  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

• Upcoming Conferences

  Date: 2011.05.04 | Category: Agile, Conferences, Innovation Games, Presentations, Scrum, Tools | Response: 0

  Been really quiet these past months, but I wanted to share some upcoming places where you can see me in action.

  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.

• Writing Good User Stories

  Date: 2011.02.07 | Category: Agile, Coaching, Communication, Extreme Programming, Lean, Planning, Tools, User Stories | Response: 1

  User stories are tool that originated from Extreme Programming and have become the de facto way Agile teams document and collect their requirements.  There is a lot written on user stories (link, link, link), so I am just going to talk about what I consider important in writing good stories since I see a LOT of really bad ones out there today.

  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.

• Reading a Release Burndown Chart

  Date: 2010.11.08 | Category: Agile, Communication, Planning, Product Owner, Scrum, ScrumMaster, Tools | Response: 1

  In Scrum, we use a lot of easy-to-understand tools to communicate status.  A very common tool is a burndown chart.  In this diagram, I am showing a sample Release Burndown chart for a Team with eight Sprints in their release and will talk about how this is commonly used on a Scrum Team.  At the start of the release, the Team estimated 130 units of work would be delivered in eight Sprints.  At the end of Sprint #1, they delivered twelve units of work (the green bar) and 118 units remained (the red bar).  As the release progressed, a little more of the Product Backlog was delivered by the Team in the next two Sprints.

  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.

• Musings on (Agile) Metrics

  Date: 2010.10.18 | Category: Agile, Conferences, Design Excellence, Design for Six Sigma, Lean, Measures, Scorecards | Response: 0

  Last week I attended a really interesting session at Agile Open NoCal about what are good metrics for Agile teams.  Since I spent a lot of time thinking about this when working with Cardinal Health on their Design Excellence program, here are some thoughts I have.

  Metrics are a powerful tool to influence behavior.  They should be applied judiciously and cautiously to any problem since they ALWAYS create unintended and unexpected behavior.  The larger the organization, the more important it is for measurement since that is the way big organizations receive feedback and can adjust their behavior.  However, it is unreasonable to insist all metrics are destructive and irresponsible to expect a large business to fly blind without some sort of data.

  I tend to think, most people do not understand how to design good metrics or they create metrics that are easy to gather, i.e. using time sheets or something else similarly foolish, or they pick metrics which are valuable to the data collector, not anyone else.  I don’t claim to be an expert, but I have some ideas which I think are consistent with Lean Thinking and Agile.  There are four guiding principles I can provide:

  1. The only metrics that matter are the one tied to customer value or satisfaction.  All the rest are intermediate measurements.
  2. The people being measured should have a say in creating the measurement system on which they are judged.
  3. Apply the Lean concept of Measure Up when creating your metrics.
  4. The best metrics are temporary.  Once the metric has produced the desired outcome, discard it.

  Pascal Dennis in his book, Getting the Right Things Done (not my favorite book – long on story, short on specifics), gives some great guidance on the first principle when flushing out the concept of True North. True North is an emotional description of the strategic and philosophical goals of the organization tied to real-life, customer-focused metrics.  Not the kinds of metrics middle managers care about or software teams, but the types of metrics that show up in reports to shareholders and are on the minds of the executives and senior leaders.  These are the metrics EVERYONE in the organization needs to be focused on and thinking about every day.

  In my experience, the people doing the work know what metrics are meaningful to them and which have no impact on their day-to-day activities.  To create a powerful measurement system that gives accurate, real-time data, engage the people doing the work in creating this system.  In addition, the metrics they come up with, are the metrics on which they are evaluated.  The common objections one runs across when developing this idea with middle manager are “what if the workers don’t come up with anything?” or “what if they are not sophisticated enough?”  I feel if you explain to the workers what is the True North, the main business metrics, they will come up with meaningful metrics that tells them if their work is contributing to the objectives of the organization.  The people who work in the company want the business to succeed (and if you feel otherwise, you have a different, more serious problem).

• Speaking @ USC Code Camp – Oct 23rd & Oct 24th

  Date: 2010.10.15 | Category: Agile, Coaching, Collaboration, Conferences, Presentations, Scrum, ScrumMaster | Response: 0

  It is that time of the year again, time for a trip to USC for SoCal Code Camp.  Here are the topics that I submitted for this year’s event:

  1. Introduction to Scrum – Scrum is a framework for developing high-performing, self-organizing teams to deliver value to customers and the business quickly.  In this hands-on session, Carlton will explain how Scrum works and describe the roles, artifacts and rituals of Scrum.
  2. ScrumMaster’s Toolkit – Are you just getting OK results with Scrum?  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, you will learn tools that breaks these old patterns, unlocks the potential of Teams and gets them moving toward high-performance.
  3. Selling Your Ideas With a Drawing – Ever stand at a whiteboard & not know what to draw?  Ever watch a good idea got lost in a lot of talk?  Pictures convey ideas more clearly & have a greater impact than a simple conversation.  Come ready to draw diagrams in this hands-on workshop and create powerful diagrams which shift how you visualize your work & convince others.

  I’m pretty excited about these sessions since all of them are new for me.