Archive for the ‘Coaching’ Category

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

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

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

• Speaking @ Agile San Diego on Oct 7th

  Date: 2010.09.09 | Category: Agile, Agile SD, Coaching, Scrum, ScrumMaster, Team | Response: 1

  I will be running a short workshop at the next Agile San Diego meeting showing off a few of my favorite coaching tools.  If you are looking for a few new tricks, stop by and say hello.

  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.

• Reading List (1st Half of 2010)

  Date: 2010.08.23 | Category: Agile, Coaching, Communication, Documentation, Lean, Personal, Retrospectives, Scrum, ScrumMaster, Team, Tools, Training, Transitions | Response: 0

  Wow!  I have read a LOT in the last six months!  I guess that is one of the advantages of being on the road for about six months.

  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.

• You Can’t Phone It In

  Date: 2010.08.19 | Category: Agile, Coaching, Collaboration, Scrum, ScrumMaster, Team | Response: 0

  Being a ScrumMaster is much more than just showing up for the Scrum meetings and lobbing in a few facilitation techniques to keep things moving along.  Yet I think many project managers who are new to being ScrumMasters misunderstand what is required of them.  I feel they read about Scrum in one of the many excellent books on the topic and think, “Facilitation…four meetings…lessons learned…planning…task tracking.  OK, that looks easy – I can do that in my sleep.”  All they can see are the transactional aspects of Scrum.  Since that is all what Scrum is to them, they bring the empty project management mindset to the work and the result is a functional Scrum without any purpose, rituals without any meaning.  And this is where I think many project managers turned ScrumMaster stumble with the role.

  An excellent ScrumMaster has a real presence with the Team.  To become an excellent ScrumMaster one must go beyond the simple transactional elements of Scrum and focus on the transformative aspects of the work.  As ScrumMaster you need to focus, really focus, on the needs of both the Team and the individuals as you work to improve the environment they work in.  You need to be both physically and emotionally there for them in a profound way.

  Scrum’s great promise is that it reconnects people to each other work through empowerment and true collaboration.  As ScrumMaster it is your responsibility to facilitate collaboration, to help people feel comfortable and willing to take both professional and personal risks.  This does not happen in a fifteen minute Daily Scrum, or a two-hour Sprint Planning meeting or during a Sprint Retrospective.  Those rituals have very specific goals and individual coaching is not one of them.  The moments where one-on-one coaching happens and trust is developed are the times when the people are doing the work.  It is those moments when one notices a Team member’s joy, disappointment, frustration, happiness and anxiety.  You catch them being real and experience the moment with them.  This only happens when you share physical proximity, observe and be present when these moments happen.

  In Scrum, we strive to give the Team members slack and ask them to limit multitasking to preserve their focus.  We expect the same from the ScrumMaster and that is why I recommend new ScrumMasters only focus on one Team.  If as a ScrumMaster you are lurching from fire-to-fire, meeting-to-meeting, team-to-team you are still operating in the old project management paradigm and it needs to stop.  People on the Teams need your help.  Stop being so busy and focus on what the Team needs for a change.

• Best Links of the Week – August 13th 2010

  Date: 2010.08.13 | Category: Agile, Coaching, Extreme Programming, Lean, Links of the Week, Pair Programming, PMI, Scrum, Transitions | Response: 0

  Beat the summer heat with these engaging posts.

  1. Lean Software Experience Report – detailed discussion of how XP and Lean were combined for GlaxoSmithKlein IT projects to support new drug development.
  2. Making People Before Making Products – great article highlighting the import role management plays in developing & mentoring knowledgable workers; watch out for the funky scrollbar.
  3. How to Succeed With Scrum When Your Company is Anti-Agile? - Rob Diana talks about how to recover from previous failed Agile attempts in your company with time-honored values such as lies and entrapment.
  4. How to Do Agile When We Only Have 50 Crap Developers? – a short rant on the importance of having good people on your Agile team; the comments are very interesting, too.
  5. Pair Programming Interviews – an experience report from Rob Bowley on how to use pair programming in your interview process.
  6. The Secret Sauce Recipe to Agile Coaching – Rob Myers talks about what it takes to become an excellent coach for an Agile team.
  7. A Coaching Toolkit – a collection of principles to keep in mind when coaching Agile teams.
  8. Scrum Adoption #1: Awakening – Tobias Mayer examines the concept of awakening as a prerequisite for making inroads with Scrum in your company.
  9. How to Screw Up Agile – great mind map on the factors which inhibit (and help) Agile grow in your organization.

• Best Links of the Week – July 2nd 2010

  Date: 2010.07.02 | Category: Agile, Coaching, Communication, Lean, Links of the Week, PMI, Scrum, ScrumMaster, Team, Transitions | Response: 0

  New stuff to read and learn before the holiday

  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.

• You’re Invited!! – An Agile Game

  Date: 2010.06.25 | Category: Agile, Coaching, Games, Lean, Training, Transitions | Response: 0

  A colleague of mine, Deb Hartman Preuss (@deborahh), tweeted “I have a strange job: getting things to happen in other people’s minds, bodies, hearts. Kind of like the faith healer who doesn’t touch you.” and it struck a chord with me.  A lot of what I do as consultant is help open people’s minds to new ideas and look at their actions, which is why I use a lot of games and simulations.  In my experience, games and simulations help people get into a safe space where they can reflect on their behaviors and understand why they might want to change.

  One of my favorite games to help people understand the corrosive effect of push systems and working in silos is the “Invitation Game” created by Chris Sims at the Agile Learning Labs.  In this game, participants are asked to make three invitations to a party with six steps to complete (see below).  The game is played in two rounds and they are timed.

  1. Fold the paper in half
  2. Put a smiley face on the front
  3. Write “You’re invited!” on the inside
  4. Add your signature
  5. Put a sticker\stamp on the back
  6. Deliver the invitation

  In the first round, individuals are teamed in groups of six and each person is given one step to do.  When they complete ALL their work, they hand-off their eighteen unfinished invitations to the next station; i.e. after folding all 18 sheets of paper, the next person makes 18 smiley faces and then passes along to the third person on the team.  Normally, the completed invitations look something like this – all look the same and are sloppy.

  

  In addition, as an observer what you see is a lot of waiting around – due to the constraints of the game only one person can work on the invitations at a time and all the rest are waiting for their handoff – and not a lot of value being generated until the very end.  Another interesting observation is what inactive participants are doing while the active person is doing their task.  Sometimes they are giving helpful, unsolicited advice to the active person on how to do their job.  Things such as “Hurry up”, “You can fold six of them at a time”, “You don’t need such fancy face”, etc., etc.  Sometimes the inactive people are just waiting around with nothing to do or talking to another inactive participant.  If you ask the participants about the experience, they normally say it was stressful and they felt a lot of pressure.  The term “fun” is not mentioned at all.  IME, teams usually deliver their invitations somewhere between 12 to 15 minutes.

  In the second round, we change the rules of the game a bit.  Each person is responsible for making three invitations, they have to make a complete invitation and deliver it before moving on to the next one.  We also time when the first invitation is delivered as well as the when the last one is delivered.  Here are the typical results from the second round.

  

  What you see here is a really interesting and creative stack of invitations.  During the entire game people are relaxed and enjoying themselves.  You also see individuals looking at other people’s work for inspiration and drawing on new ideas.  People experiment more.  Many times, while waiting for the entire team to finish other team members will start additional invitations and deliver extra value to the customer.  Finally, if you look at the statistics, i.e. the timings, you see the second round really shine.  The customer gets value within the first two minutes and all the invitations for all teams in delivered 8 to 10 minutes – a productivity increase of nearly 50%!

  When both rounds are complete, I lay out all the invitations on the table and ask the participants which invitations a customer would want.  The answer is always the same, the invitations from the second round.  The second round invitations are just so much more interesting and creative than the first.  In addition, by delivering the items one-at-time when completed, the customer gets more opportunity to provide feedback to the team on what they really want (or don’t want) in their invitations.  If the customer finds an interesting variation – they can sell it right away, show it to their stakeholders and\or ask the team to make more (“I need more invitations with stickers of ponies.”).

  I also ask which round is more like everyday work and the answer is again very predictable – the first round.  In the first round of typical batch\handoff work, the customer is obligated to accept the invitations delivered even if they are sloppy, low quality and don’t meet their needs.  What would their management and stakeholders say if the customer asked for the resources (12 to 15 minutes) to make another batch of crappy invitations?  They already spent 12 to 15 minutes of six people’s time.  They can’t go back and ask for another set.  In the batch\handoff work, there is so much waste of time where people sit around doing nothing.  Fortunately, people display a great degree of ingenuity and find something to occupy their time – criticizing and interfering with the work of the people who come after them.  A very typical behavior in most organizations.