Confessions of a SPC Cheating on the Scaled Agile Framework

I’ve developed a knot in my stomach. I feel like I’m about to cheat on one of my early Agile loves – SAFe. It’s just exploring, right? Well, maybe… maybe I’ll go back, but then again maybe not. I guess I won’t find out until I try, right?

I am a SPC, a Scaled Agile Framework Program Consultant, and I’m going to a Scrum@Scale class next month. Not just any Scrum@Scale class, but one taught by Jeff Sutherland. [insert giddy giggles…]

Jeff isn’t the only draw.

I’ve been a SPC for almost five years and was on the team that explored how we might be able to implement the Scaled Agile framework at a former employer. In fact, I may have been the very first Product Managers who was certified as a SPC. It was a big deal and I was very excited about it. Who doesn’t love the SAFe Big Picture?


That Big Picture was a huge draw for us to evaluate SAFe in the early days of our Agile transformation. It was a natural extension of what we had recently accomplished by adopting Scrum. There it was; a recipe book for how to build software at scale in our large, complex environment. For that reason, SAFe took hold in the organization.

As Jeff and the team at Scrum, Inc. have aptly pointed out, not all companies, and certainly not all Scrum implementations are the same. I would add that as you mature along your Agile journey, the recipe book that was once comforting might now feel a bit restricting. I’ve heard it from some of our customers, “…we really like parts A and C of SAFe, but D and F feel like overkill and unnecessary.”

Additionally, I have recently been working with Scrum teams that don’t build software, but need to scale beyond the single Scrum team. Although those smarter than me may disagree, SAFe doesn’t quite feel right in these instances either. Scrum has expanded beyond the domain of software, and we need to find ways to scale that fit.

And this is when I started to explore...

Let’s inspect and adapt not just how we apply Scrum and other Agile methods, but how and why we should scale. My interest in branching out as a consultant and coach, and even as a SPC, is to explore how we might help those that don’t quite feel that popular scaling frameworks like SAFe “fit.” The lighter weight, modular, fractal structure that we see in Scrum@Scale may be just the right approach to scale an organization.

Stay tuned. In about a month I’ll let you how it goes. Meanwhile, anyone want to cheat with me?  Scrum@Scale with Jeff Sutherland, November 8-9, Durham, NC

Registration Link
 

SatSSAFe.png

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?

Top Ten Signs That Your Product Manager Isn't Agile

Blog Editor's Note: This post originally appeared in late 2008 when we were Enthiosys. I'm very interested in whether anyone else agrees that the list still resonates. Enjoy.

Originally Published October 20, 2008

Here at Enthiosys [now Applied Frameworks] we spend a lot of time helping Product Managers become Agile. In the process, we often run into developers who are really frustrated with their Product Managers' lack of Agility. Acknowledging their pain, here are our top ten ways to tell if your Product Manager doesn't understand Agile. And yes, it was hard to whittle down from the 40+ items on our initial list.

10. She says "I think" instead of "the market research says" or "during our last review meeting with a customer…".

9. He thinks release planning can be done in 2 hours.

8. She sometimes attends an iteration planning meeting, and rarely (or never) attends an iteration acceptance meeting.

7. He thinks the backlog is just the list of market problems he captured in his MRD.

6. She doesn't have a roadmap beyond the stories in the next release.

5. He thinks MuSCoW works when prioritizing the backlog.*

4. She can't provide acceptance criteria during release or iteration planning.

3. He stops visiting customers so he can attend every daily standup. Even worse, he talks about his tasks during the daily standup.

2. She thinks that year-old market data is good enough for managing the backlog or developing a roadmap.

1. He thinks a product owner is a Product Manager.

*MuSCoW is a way to organize requirements into buckets of "Must, Should, Could, Would".

Is product marketing the same as marketing? (I say no)

I’m often asked to differentiate product marketing from marketing (or marketing communications, if you prefer).  This effort gets confusing for most because of the term “marketing.”

I’ve long been uncomfortable with the term “marketing.” For many of us, marketing is a philosophy. Marketing is looking at the business from the buyer’s point of view. It’s looking at the whole product, not just the software. Marketing includes packaging and pricing, and even how we answer the phone. But for others, “marketing” is a department, often associated primarily with advertising and branding.

Consider this: in marketing we use "greeking" to help people evaluate a design without getting distracted by (or obsessed with) the text. Product marketing owns the text; marketing owns the design. 

For technology companies, product marketing managers are tasked with taking the product from the development team to the sales team and ultimately to the market. They are typically responsible for buyer profiles, positioning, and product information. Their focus is on product. In contrast, marketing (or marketing communications) is responsible for the execution of go-to-market programs. Their focus is on markets. They ensure programs are aligned with corporate branding standards, resonate with buyers, and empower the sales team.

It helps to think of marketing as a development organization. Product marketing managers bring requirements to marketing; marketing develops go-to-market solutions to address those requirements. Marketing is expert in designing programs that succeed and knows when to use those programs to address specific go-to-market problems.

As product manager is to development, product marketing manager is to marketing.

As a product manager brings requirements (or problems to solve) to development, product marketing managers bring go-to-market problems to solve.

A product marketing manager says, “The CIO needs to understand our infrastructure and architectural decisions to see how we align with their strategic technology direction.” Marketing replies, “We need a web page with a link to a white paper.”

Few organizations expect product managers to write production code. Likewise, product marketing managers should not develop programs, design brochures, or create web pages.

Product marketing identifies sales enablement PROBLEMS; Marketing designs SOLUTIONS.

How do you define product marketing? Add your comments below.

Related: See “Positioning, Messaging, and Ownership” at http://appliedframeworks.com/blog/2013/04/22/positioning-messaging-and-roles