What We Believe About Agile

Happy New Year! We hope that 2015 started great for you. To kick off what we expect to be more frequent blogging, this post describes what we believe about Agile. I'm motivated to write this for two reasons - to explicitly state our point of view and to prepare for a Certified ScrumMaster class that I'm teaching this week.

Agile is four values and twelve principles found on the Agile Manifesto home page and on the Principles behind the Agile Manifesto page. That's it. We believe that if an organization of people works together in a way that is aligned to these values and principles that the organization is Agile. We approach all of our teaching, coaching and other consulting from this point of view.

Agile isn't daily meetings, user stories, continuous integration, product owners or other related activities, artifacts or roles. Agile is a mindset of collaboration to create great products incrementally and iteratively, frequently adjusting based on changes in the world around us and what we learn.

A group of people could work in a way that is Agile with a model of interaction that they invent. In other words, you don't need Scrum, Extreme Programming, SAFe, Kanban or any other framework to be Agile. However, frameworks certainly help people execute efficiently and consistently.

We created Applied Frameworks because we believe in fulfilling the needs of people and organizations to be more effective and happier in their work to produce great products that meet and exceed their customers' needs. We believe that an Agile mindset enables us to accomplish WHY we exist.

This year we want to help you and your organization find your most effective and happiest state of execution and hope this is your best year yet. Let's go!


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. 

Career: Should you learn to program?

Many people today seem to be advocating for everyone to learn programming. But you’re not going to learn programming at your age if you haven’t already. And you definitely won’t if it doesn’t really interest you. You can’t just “get technical” by sheer force of will. You need to be interested enough to spend a few hours figuring it out. You need a passion for it or else you’ll give up.

But there’s an alternative. You can learn programming logic using a scripting language. If you have a Mac and don’t know about Automator (available on all Macs running OSX), you should check it out. I use it for a bunch of stuff.

For example, I often want to resize an image to make it fit better on the web site. So I wrote this simple script in Automator:

resize images.jpg

I set the default value to 1280 but I also selected “Show this action” so when the script runs, I can change 1280 to 600 or whatever value fits best. You can do the same thing in Preview but I find this is easier plus I can use it on multiple files.

My dad wanted to export records from Contacts to Excel. (Strangely, that’s something you can’t do in Contacts. Sure, you can upload your contacts to Gmail and then download a CSV but that’s more trouble than my dad could handle.) So I wrote another script.

export contacts.jpg

In this case, Dad runs the script, chooses the Group that he wants to export (or leaves it blank for all groups). The script then passes that group to the next action, which finds all the people in that group, gets their contact info, and copies the result to the clipboard. Now just run Word or Excel and paste what’s in the clipboard.

Automator is like “drag and drop” programming and it’s something most people can learn fairly quickly. The key is to have an application that you want to automate. Like move a file to iTunes. Or extract the audio from a movie to make an audiobook.

I don’t know if you know it but technical people are a special kind of lazy. We never like to do the same thing more than once. We’d rather write a program to do it again and again. Like good product managers, we don’t just want to get it done; we want to get it done right so we don’t have to do it over.

If you’re not interested in learning how to write scripts, you can still learn to appreciate logic and technology. I know many product managers who have learned a lot of technical stuff just by asking for explanations. Don’t get befuddled. Ask for help. Get an explanation.

One product manager kept wasting his team’s time. He would say “do it this way” when he really didn’t understand the issues. I got him alone and explained what the people on his team were asking and explained what he had told them to do. I walked him through the capability step by step, and he was amazed. He didn’t know the product had the feature that I was describing and he’d been using it for years.

You can find a guide to help you, whether it’s someone on your team or elsewhere. Developers and other technical folks are glad to share their experience. Get a technology mentor to explain architecture and data structures and whatever technical challenges you need to understand.

A good product manager asks for help. Do you?