Archive for the ‘Agile’ Category

• 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.

• Speaking @ PMI San Diego Soft Skills Breakfast on Oct 15th

  Date: 2010.10.04 | Category: Agile, Coaching, Communication, PMI, Presentations | Response: 0

  I have been invited to speak to at the PMI San Diego soft skills breakfast group on the topic of Powerful Question.  The breakfast meeting is for project managers to learn new techniques and interpersonal skills and to network with their peers.  The meeting starts at 7:30 AM and I probably will begin speaking around 7:45 to 7:50.  Here is the description of the topic.

  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.

• Sponsoring Agile Open California – Oct 11th & 12th

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

  This year Look Forward Consulting is a Silver Level Sponsor for Agile Open Northern California.  As a sponsor, I am very proud to be supporting the Agile community in California and would like to see the number of people doing good Agile grow.

  As in years past, the event will be held at the Fort Mason Conference Center and will be using Open Space Technology.  If you have not had the chance to participate in an Open Space, you are in for a treat since each Open Space is a special experience.  For only $250, you will get to interact and learn from fifty to sixty of the leaders in the California Agile community in an intimate and thought-provoking environment.  The topic this year is “Agile Out of the Box”

  

• Speaking @ Agile San Diego on Oct 7th

  Date: 2010.09.29 | Category: Agile SD, Coaching, Collaboration, Communication, Games, Scrum, ScrumMaster, Team | Response: 0

  Next week I will be speaking at one of my favorite groups – Agile San Diego – on October 7th beginning at 6:30 PM.  The topic will be “Tools for ScrumMasters and Agile Team Leaders” and this is a quick description of the session.

  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!

• Innovation Games® at PMI Silicon Valley – Sept 21st 2010

  Date: 2010.09.15 | Category: Collaboration, Communication, Conferences, Games, Innovation Games, PMI, Presentations | Response: 0

  Just wanted to alert folks I will be facilitating an Innovation Games^® session at the PMI Silicon Valley 2010 Annual Symposium on Tuesday, Sept 21st from 3 PM to 5 PM.  The theme of the conference this year is “Beyond Project Success – Business Success” and I have been working with Luke Hohmann and Margaret Motamed to select some fun games to play that will open up some minds on the value of collaborative games in helping your enterprise grow and succeed.  We have also planned some exercises to ensure the participants walk away with a memorable learning experience.

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

• Estimating & Planning for Agile Teams – Oct 2nd

  Date: 2010.09.12 | Category: Agile, Estimating & Planning, Extreme Programming, Planning, PMI, Scrum, Training | Response: 0

  Having trouble communicating deadlines to stakeholders?  Unable to get a commitment from the Team on when work will actually be delivered?  Having trouble managing dependencies?  Agile processes, like Scrum and Extreme Programming, rely on lightweight techniques to progressive guide and steer a project to completion.  In this hands-on workshop, Carlton Nettleton will review the common Agile tools used by successful Teams to produce project plans which have clear milestones and deliverables and raises risks and dependencies early.  The topics covered in this class will include:

  • Importance of creating a Definition of Done for the Team
  • The role of user stories to capture, develop and validate requirements.
  • Common estimating techniques employed by Teams.
  • How to develop and maintain a Release Plan to track progress.
  • How to use easy-to-understand Agile metrics to monitor status.
  • Link common Agile planning practices to the PMBOK.

  Participants that are PMP will earn 4 PDU.  Register today!