Agile2014 Gratitude

I really enjoyed meeting new people and seeing so many old friends at Agile2014 in Orlando. Thank you to everyone who attended my session, asked questions and provided feedback, which encouraged me and gave me ideas for future events.

Here is the feedback for "Teaching Agile to Management":

"Your session's recorded attendance was 80 attendees (at start), 76 (in the middle) and 76 (at the end). 37 attendees left feedback.

"The feedback questions are based on a 5 rating scale, with 5 being the highest score. Your average ratings are shown below:

  • Session Meets Expectations: 4.22
  • Recommend To Colleague: 4.22
  • Presentation Skills: 4.49
  • Command Of Topic: 4.73
  • Description Matches Content: 4.22
  • Overall Rating: 4.24"

The slide deck is available for download here. The Word file for the "Role-ing Doughnut Game" is also available. I print the file on Avery labels (10 to a sheet). I measure and cut 8 cards per sheet out of card stock sheets to mount the labels. The poster for the game is also available for download. I order 3' x 4' posters from FedEx Office.

Please share your experiences in the comments and feel free to send any questions our way.

The 3 Questions vs. Tools

Why Tools Drive Daily Scrums into the Mud

I have observed a disturbing pattern in many Daily Scrums driven by an intense focus away from the three questions and to various Agile tools. I see people checking out of the interaction, I don't hear all voices, I don't feel any energy and I don't sense any collaboration or collective ownership of the work.

What I See...

Screen sharing like Live Meeting…whether 7 people in the room and 1 person remote or 2 people in the room and 6 people remove…almost always hosted by the ScrumMaster. A tool's task board displayed. The meeting flows from the top of the task board to the bottom with conversations like,

ScrumMaster: "OK, story B-01243…Sam - What's the status?"

Sam: "Oh, ummm, I finished the 1st task [but Sam hasn't moved it to 'Done'] yesterday. I started the other task but got blocked [also not yet moved by Sam]. Then I worked on the task for story B-01250 [at the bottom of the board]."

Everyone else during this conversation - Silence…Looking at who knows what on their screens.

ScrumMaster: "Sam, do you want me to move those tasks?" OR "Sam, please update your tasks." AND/OR "Any impediments?"

Note: If the ScrumMaster moves tasks, then we're in for a treat as he/she navigates down to find B-01250 wherever it is on the board to move tasks around.

Repeat for every BACKLOG ITEM on the board…Every day.

Why this Pattern Fails

  1. Violates the pattern of the 3 questions…No coherent, fast realization of progress toward the Sprint Goal.
  2. Focuses attention on the screen/task board, not people.
  3. Focuses on a top/down flow, which almost always does not reflect the actual nor optimal flow of the work in progress.
  4. Drives the WRONG behavior of stimulating excessive WIP - work in progress.
  5. The team is not self-organizing the meeting…Intentionally or not, the ScrumMaster is organizing the meeting to flow through the tool.
  6. Invariably the meeting runs longer than 15 minutes because this pattern drives so much wasteful conversation.
  7. No/Little synchronization of work because, in general, things on the board only have 1 person talking about them at a time.

Why Do We Do a Daily Scrum?

  Daily Scrum at   Klean Denmark     CC BY-SA 2.0  (photo cropped)

Daily Scrum at Klean Denmark CC BY-SA 2.0 (photo cropped)

From The Scrum Guide…my emphasis added.

"The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one. The Daily Scrum is held at the same time and place each day to reduce complexity. During the meeting, the Development Team members explain:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

"The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal.

Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint.

The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replay, the rest of the Sprint's work.

"The ScrumMaster ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The ScrumMaster teaches the Development Team to keep the Daily Scrum within the 15-minute time-box.

"The ScrumMaster enforces the rule that only Development Team members participate in the Daily Scrum.

"Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team's level of knowledge. This is a key inspect and adapt meeting."

The Agile Atlas overview of Core Scrum provides a similar description of the Daily Scrum.

Disclaimer

Don't get me wrong, I have nothing against Agile tools for Application Lifecycle Management. These tools greatly support teams. They save a whole bunch of time generating useful information for Development Teams, Product Owners, Product Managers and organizations. They provide organizational 'memory' and collaboration as the single source of backlog information. They just stink as tools for Daily Scrums…and other Scrum activities.

What did we do before the tools?

We met in the team room and stood near the task board. Sometimes people referred to the board to jog their memory. Most just spoke off the top of their head, because that's what mattered - "Yesterday, I finished X. today, I'm going to do Y. I don't have any impediments. John, I would like to chat with you for 5 minutes when we're done about the whoozijiggy design."

(My friend Carlton Nettleton and my colleague Gil Broza have shared their unique and complementary ideas on this subject.)

What to Do as a Coach or ScrumMaster if You Observe or Facilitate this "Tool-Driven" Pattern?

  1. Ask the team if you can have a short conversation with them about the Daily Scrum. You're seeking permission.
  2. Have a mini-retrospective.
    • How valuable is the Daily Scrum?
    • How good are their daily plans to work together for the day once the Daily Scrum ends?
    • What would they like to change?
    • What might happen if they stopped using the tool and returned to the 3 questions with nothing in front of them except other people (if in person or notes or whatever if remote)?
    • How does everyone, including the ScrumMaster, feel about this?
  3. Ask them what they want to do.
  4. Let go and let the team move on.
  5. Check in with them a few days or a week later (if you have the invitation for an ongoing coaching relationship).

Your feedback is always welcome…What are YOU seeing at Daily Scrums?

Roadmapping That Works

Thanks to everyone who attended last week's webinar. I appreciated all the great questions. The recording and slides are now available as well as a full set of Visio and Excel templates below. I will also post the questions and answers from the webinar. I plan to add a lot more content in the coming weeks to provide greater detail about our product roadmapping framework and how to use it.

iStock_000011359879Small.jpg

Basic Template - Excel / Visio

Expanded Template - Excel / Visio

Advanced Template - Excel / Visio

productcampRTP 2014 Presentation

I enjoyed spending Saturday at pcampRTP and appreciated the opportunity to present Finding the Best Frameworks for Product Management. The concepts in the presentation have been percolating in my head for a long time and I finally had a great venue to get the ideas organized, expressed and validated through feedback from a terrific audience. The roadmapping concepts resonated most and I plan to follow up with several more posts on roadmaps.

I look forward to seeing the other presentations once they're shared by the organizers. Some highlights - Mark McClear from Cree delivered a great keynote about their LED light bulb history from a product adoption point of view. Greg Hopper presented a fantastic overview of Product Strategy Lessons from Apple - a light speed talk in over 90 slides in 40 minutes. I can see how his courses at Duke must interest students.

Steve Johnson will be at the next pcamp in Boston on May 3rd. I recommend attending if you're in the area since time at these camps is well spent. 

Don’t learn everything at once

I've also learned that only through focus can you do world-class things, no matter how capable you are.—Bill Gates, Microsoft

In my first job out of college, I was a programmer working “week on/week off” which was really cool. We’d work 12 hours a day for 6 days, Thursday through Wednesday (with Sunday off), and then take a week off. “On” days were long (!) but we found two teams working in shifts reduced mistakes that were more likely with three teams. And of course, “week on/week off” was a great recruiting tool!

48781.jpg

On my “off” weeks, my pal Jay taught me to play golf. Of course I’d played a little before but never really had the time to get any good at it. What really worked for me was the way Jay taught me to clubs. Initially I was only allowed to carry a 2, 6, and putter. Darn it! I have a whole bag of clubs! But we started with just a few. Once these were mastered, he allowed me more clubs.

So often, when you’re trying to learn something new, the topic can be overwhelming. Maybe we’d be better off to follow Jay’s advice and pick just a few clubs.

Lately everybody seems to be saying you should learn to program. But unless you have a reason—an application—you’re unlikely to stick with it. Same for a web site, or a blog, or whatever.

A friend hasn’t used Excel in years but thinks she should know it. But no matter how she tries, she just can’t get into it. The problem is, she doesn’t need it. She doesn’t have an application. And I’ve found that can’t really learn something until you have an application for it—a real need.

In my years teaching product management courses, people often said they wished they’d had the course when they started. But I wonder. Too many clubs just make for a confusing bag. Maybe new product managers need to ease into the job. (Particularly when everyone else in the company is desperately trying to dump their work on the new guy.)

Nowadays what I try to do is introduce people to frameworks just when needed

I have a bucketful of business frameworks—like three horizons, five forces, the S-curve of adoption. The trick isn’t to know the metaphor; the trick is to know when and how to apply it to your business problem.

What clubs should you start with? See my article Your first days… as product manager.