Tag: Leadership

I often get asked to visit agile teams—delivering some ad-hoc training and taking a look about. Usually I’m asked to do an informal assessment and share improvement feedback—framing the visit as part get to know each other session and part agile assessment. A short while back I visited a team. They’d been doing agile (mostly Scrum) for quite a while and considered themselves relatively mature in their adoption.

Right away, when I got off the elevator, I noticed that their environment was open and airy; so very conducive to collaborative agile teams.  There were rolling whiteboards all about and small groups of people were talking and pairing all over the place. Even the managers were sitting out in open space.

So my anticipation grew as we walked around. I was looking forward to seeing some high-performance and mature agile team activities and the subsequent results that such teams can deliver. There’s nothing in the world quite as exciting as a well-honed agile team.
(I know, I know that’s a geeky, agile coaching perspective…but they do get me excited 😉

The other exciting part of this organization is that they’d invested in hiring some internal agile coaches. Again, that was a maturity indicator from my perspective as they had experienced ‘guides’ for their agile journey—call them Agile Coaches or Agile Project Managers.

The Teams

But then as I physically sat down with the teams and interacted, I realized quite quickly that something was wrong. Drastically wrong. The teams seemed to be aimlessly “doing Agile”. There was no sense of velocity, no sense of reliable burn downs, no sense of release planning, and each had no clear sense of commitment to where they were going. In a nutshell, the teams were in open space, there was an agile façade of sorts, and they even had coaches, but when you looked under the covers, there was no “consistency or directional substance” there. Here’s an example of what I mean…

Backlog Grooming – Run Amok

One of the first meetings I attended was a backlog grooming session. I was introduced to ‘John’ as the Product Owner. He was going over some user stories for his team and they were estimating them. John went to the board and started writing down numbers. I was curious as to what he was doing. Then he started to point to individuals and tell them what their estimates were for the individual stories. He articulated architecture and design approaches, as he saw them, and basically shared with his “self-directed” team that he’d sorted out all of the “hard stuff” for them.

He seemed quite proud of the leadership he was providing.

Their agile coach was also their Scrum Master. And John was the functional manager for the team, but also their Product Owner. He also seemed to have assumed the role of Chief Architect and general oracle for the team. Clearly there was lot of “role overloading” going on within this team.

So at this point I realized that I vastly underestimated the maturity of the teams. I had a perception from the coaches I’d met with and from the environment. But when you scratched the surface, the environment was culturally command-and-control oriented. They’d also seemed to be struggling with the people & focus investment that agile requires.

As I walked around the organization and became immersed in different teams, different projects, different instances of Scrum, etc.; I realized that everyone was saying they were ‘doing’ scrum and ‘doing’ agile, but there was no rhyme or reason to it.

There was also no consistency or standards in the practices. One team would be using user stories, but without any notion of or investment in acceptance tests. Another team would be spending nearly 90% of their development time ruthlessly designing cucumber tests, but their stories will poorly written and ill-defined.

In some teams, a team member was encouraged (forced) to be a developer and the Scrum Master and the Product Owner—without any training whatsoever. In other cases, functional managers were taking on Scrum Master & Product Owner duties for teams that reported to them. In these cases, you could SEE the team nearly always deferring to their managers in decision-making.

There was literally, self-directed bad Agile chaos. The only thing that was consistent across the various development groups was—

1. The had a daily standup
2. They had a sprint duration/tempo defined
3. They had whiteboards and used lots of cards
4. They had user stories and tasks for their current sprint
5. They sort of supported Scrum ceremonies of sprint planning, demo, and retrospective
6. You’re “self-directed”…so do what you want…

As I sat down with their coaches and (softly) confronted them on this—they reacted poorly. The overall reaction was that they were doing the “best they could”. That the organization lacked the maturity and readiness for more mature agile practices & adoptions, so they were introducing small changes in an effort to help where they could.

I felt quite sad afterwards.

I know the coaches were trying to do the best they could…and so were the teams. But, from my perspective they were just “scratching the surface” of agile and not realizing much (if at all) of the promise & benefit of “being Agile”. And it made me wonder if the coaches were actually doing their teams a service by only introducing them to the easier bits & pieces of agile and allowing the over-customization of most of the core practices?

Another way of saying it…is it ok to only do 10% agile and leave it at that? Even if the culture is challenging? Or if the teams resist? Or if the budget doesn’t allow for it?

Is that “good enough”?

The other key point is that by over-compromising, the coaches were not challenging the status-quo within the organization. For example, all of the functional managers still seemed to be behaving in a command-and-control fashion.  They should have received some training & coaching as part of the agile adoption—to at least introduce them to their need to and how to change their leadership habits.

ScrumBut

And I don’t think this organization is unique. Nor am I the only one who’s noticed ‘compromise’ in agile adoptions. I believe it was roughly in 2009 that Ken Schwaber introduced the notion of a “Scrum-but”, as in…”We’re using Scrum, but…”. Here are some precise examples:

• We’re using Scrum, but we don’t know our velocity
• We’re using Scrum, but our Manager is our Scrum Master and our Product Owner
• We’re using Scrum, but we’re not a cross-functional team
• We’re using Scrum , but we’ve never really effectively planned and executed a sprint
• We’re using Scrum, but we don’t really groom our Backlog
• We’re using Scrum, but we have 10 Product Owners directing our efforts
• We’re using Scrum, but we only have 10% of everyone’s time to get our sprint work done

Apparently he was noticing quite a bit of Scrum without the conviction associated with doing the majority of its practices well. What was frustrating is that every ScrumBut team likened themselves to “doing Scrum”. From their perspective, they were actively leveraging it. But their implementations were mere shadows of the true intention of Scrum.

Now I do think Ken is a bit of a purist. His expectations are that all teams should do 100% of Scrum, as he personally defines it in the Scrum Guide, or you’re a ScrumBut. I think that can be a bit harsh and unrealistic. However, I do feel there should be minimal levels of adoption that are required before a team claims to “be Agile”.  That’s where we’re going next.

Should there be a price for agile admission?

The team I visited made me think and I’m thankful to them for that.

Think about whether it is ok to adopt miniscule and easier bits of the agile methods and still declare yourself to be agile. To fool yourself into thinking that you’re already “good enough” and that whatever path you choose, all will equally drive the promises of agility—without the hard work.

I’ve always prided myself on being a pragmatist as an agile coach. I’ve certainly molded and crafted practices for teams that included compromises. I felt that agility meant that you were situational or context-based in your application of the various techniques and approaches.

And to a strong degree, I still feel that way. However, is there a point of diminishing returns? Where you compromise so much that the resulting practices are virtually worthless? And that the results you realize are so small or even negative in their impact? Or actually do damage to the team and to the agile community?

I now think the answer is yes.

When we adopt agile there should be an intentional price of admission. Call it a baseline of core agile practice support that you will achieve prior to “going Agile”.  For example, I don’t think you should be doing Scrum without a Scrum Master. I think having a Scrum Master is a price of admission element to Scrum. And here is some fine print around that notion:

• Every Scrum team needs a dedicated or near-dedicated Scrum Master; someone with sufficient time to practice the craft of the role.
• They need to have a fundamental understanding of Scrum and received some “serious-level” training around the role and agile leadership. I’m not demanding a CSM, just some investment in external training.
• It’s incredibly bad form to have a manager assume the Scrum Master Role—particularly bad of their team also reports to them. Don’t do that.
• If they are multi-tasking between the Scrum Master role and another role (developer, tester, etc.) they shouldn’t be the Scrum Master on a team where they’re also an individual contributor.

If you can’t support the above constraints in establishing Scrum Masters, then don’t do Scrum. And this is simply one example of the entry criteria for Scrum. I went into more detail to make the point regarding one of the more important roles within a Scrum team.

Scrum Entry Criteria

Here’s what I would consider a short list of entry criteria or the price of admission for entering Scrum in your organization:

• You’ve introduced Scrum & Agile to your leadership team and they understand (and accept) the transitional role they need to play
• You have a focused Scrum Master and focused Product Owner per team
• You have formed dedicated (focused), cross-functional team(s)
• The team(s) has been trained in all aspects of Scrum
• You have a thoughtful Product Backlog per team, encompassing the project at-hand, that has been groomed by the team
• The team(s) have Release Planned their first project-level deliverable
• The Scrum Master(s) & Product Owner(s) have received separate training on the individual nuance of their roles
• There are NO compromises with role overloading OR functional managers taking on roles across the team(s)
• The team(s) can self-direct and has examples of successfully doing so
• The team(s) have an environment conducive to collaboration
• The team(s) are committed to using low-fidelity tooling (cards, walls, whiteboards, team rooms, web cams, simple e-tools, etc.)
• Before starting their first sprint, the team(s) have a clear project mission, charter & goals that they can leverage in guiding and measuring their sprints

Too Prescriptive?

But is the above list too prescriptive?

I’ve often heard the argument for open-ended agility as being truly self-directed. The thought goes—how we can truly be agile and still hold prescriptive guidelines over a team?

My counterpoint to that is we’re talking about Shu-level teams here and Shu-level organizations (interpret Shu as entry-level experience and there’s a link for more research at the end). I believe a bit of prescriptive guidelines are necessary in order to set the stage for what “good Agile” looks like. It creates an environment for teams to mature so that they can effectively inspect & adapt their way towards higher maturity and performance.

I’m starting to think that not setting clear entry criteria is a bit of an irresponsible copout. That as coaches we have gotten a bit lazy, as it’s so much easier to coach agile teams without any entry criteria or guidelines—as you saw in my example. Shame on us!

Wrapping Up

This was a serious post for me in that it’s challenged the very core of my flexibility and pragmatism in my own agile coaching. I think determining what to baseline and how to approach agile adoption is a deeply situational and personal choice for most Agile Project Managers & Coaches.

However, I think as a discipline, we err too much on the side of too little. Call it a lack of courage or willingness to take a stand. I don’t try to understand the drivers. But for my own coaching, I’m going to be asking more of my teams going forward in their initial agile practices. Not in the search for perfection. But in the search for a “meaningful set” of initial practices that are hard, that drive improvement, and that fosters an environment of “agile done well” in the teams.

Another way of saying it, I don’t think we can truly call ourselves Agile Project Managers & Coaches if we’re fostering “10% Agile”.

Thanks for listening,

Bob.

References & Follow-up

1.       Online version of the ScrumBut test

2.       A counterpoint to my “seemingly forceful” diatribe; Rachel makes the case for not being too forceful…

3.       Shu-Ha-Ri to help with my Shu-level references

Don’t forget to leave your comments below.

I remember the day as if it was yesterday. It was my first sprint review at a company I’d just joined as an agile coach. They’d been ‘doing’ Scrum for several years and I had gotten the general sense that they were well disciplined and mature agilists.

So when they scheduled a series of sprint reviews to expose the x-team efforts of their latest sprint cycle, I was understandably excited. I got into the room early to get a good seat and was eager with anticipation.

Gradually, the room filled and it became quite noisy, which only drove my anticipation higher. Then the first team took “the stage” and began their review. They popped up some PowerPoint slides and away they went…
Their deck was polished. They had lists of things they’d done, and downloaded pictures and jokes to lighten the mood at appropriate points. They marched through the work that they’d done…one slide at a time and at appropriate points the audience politely applauded their approval.

But it struck me midway through the first review that something was missing—something really, really important. There was no working software. How could this be, I thought. The whole point of the sprint review was to expose working code to stakeholders for review and feedback. Then I thought that this was probably an exception or special case, specific to just this team. Surely there’s working software coming up next.

But one by one, each subsequent team followed the same pattern—showing humorous slides and textual representations of effort, but no working code to be seen. Slowly and then more quickly my enthusiasm waned and I became quite frustrated. Not so much with the team, but with whoever had explained the purpose of a sprint review to everyone. Clearly, they didn’t “get it.” And neither did the stakeholders, as they continued to chuckle politely at the jokes and applaud each team’s efforts. It seemed as if the ceremony was simply there to check a box in the Scrum process list.

Never Again!

Needless to say, the teams never took quite this same approach again in their sprint reviews. While I truly honor the notion of self-directed teams, I immediately laid out some guidelines and goals for our future sprint reviews.

Some of them aligned quite naturally with the Agile Manifesto; for example, the notion of demonstrating working code at the end of each iteration or sprint. But some of the guidelines were unique to our organizational and cultural dynamics.

That’s actually the focus of this post…I want to share some of the guidelines, strategies, and the mindset we leveraged to turn-around our sprint reviews. Over time we move from:

• Polite applause…to…enthusiastic cheers and aha moments
• Polite applause…to…gaining congruent and constructive feedback
• Selling and marketing our results…to…making them transparently honest
• Small crowds…to…standing-room only and videotaping
• PowerPoints…to…working software whenever possible
• Entertainment…to…showing business value and exposing team effort
• Going through the motions…to…intentional and congruent feedback
• Selling and marketing our results…to…having them speak for themselves!

Surely it didn’t happen overnight and we continued to adjust and fine-tune our sprint reviews over time. However, we achieved a state in our reviews where they became the cornerstone for our agile adoption across the organization.

Let me share some of the things we focused on…

Guidance toward “Excellent” Sprint Reviews

In general, I like to consider the sprint review as a “big deal.” Why? Because it is.

An agile team has spent a focused period of time working on the most important stories on the planet, and is ready to deliver working software surrounding those features or stories. This stuff is hot off the presses and people should inherently care. They should be excited to see the results. Heck, you should have to beat them away at the doors.

It’s the team’s responsibility to REVEAL their efforts effectively. And I’m not simply talking about the software. No, they should be telling and showing a story surrounding their work. It should contain context and narrative. There should be a connection to the last sprint and toward future sprints.

So below I want to share some critical focus points and a sample review agenda for your consideration. I hope the specific ideas help you to improve your reviews, more effectively engage your stakeholders, and create a more energetic reveal for your teams.

7 Key Focus Points for your Sprint Reviews

1. Ownership

   We established that the Product Owner ‘owns’ the overall pattern for the Sprint Review. Sure, it’s a “whole team” thing. But at the end of the day, external communication, showing planned-delivered value, and gathering and adjusting to feedback are primary aspects of the PO role.  They’re also responsible for getting people in the review—so if attendance is spotty, they’ve got work to do to figure out why and to change your patterns to get the “right people” in the room.

   Very often I think of their role as one of Master of Ceremony—where they are conducting all aspects of the review. They are certainly not doing everything themselves, but guiding the overall quality, focus, and results of the review.

2. Format

   We put a lot of thought into the scheduling and timing for the review (or reviews if you’re part of a multi-team initiative). You’ll want to get into a regular tempo (day and time) for your reviews. Within the context of the review, you’ll want each team to follow a consistent flow (see potential review agenda below).

   In our case, we had multiple teams demoing on the same day—as our sprints were synchronized. So our format was really a cross-team agenda that sliced a three-hour time slot into appropriate stages for each team. Not only did we plan each review, but our Chief Product Owner took a stab at conducting overall flow across the teams.

3. Sprint Goals

   I personally like the view where the review is “hinged” on the sprint goal(s) that the team(s) signed up for. Quite often I tell teams when they’re crafting their goals to think about the e-mail invitation they’ll be sending out for the reviews. The ‘story’ of the sprint is then tied to the goal and how the team reacted to meeting the goal.

   And you should be honest about how the team delivered to their sprint commitments, so “Call It” as a success or failure. But never, ever let the term ‘failure’ be used to browbeat the team. Failure is a part of teams’ learning and the organization needs to adopt a “Fail Forward” attitude.

4. Whole Team View

   As I said, I like the view where the Product Owner is the Master of Ceremonies, the Scrum Master is the facilitator (if needed) and the entire team gets a chance to “show off” their results in each review. This whole-team approach serves to give your team transparency and the chance to shine—so round-robin your demo individuals and give everyone (person, role, etc.) a chance to show off their work and results.

   And no, don’t ‘force’ introverts to speak uncomfortably in a large forum. Make it encouraged and optional. Very often these folks can serve as the ‘driver’ for the demo—so quietly participate. But do engage the whole team!

5. Preparation

   If there’s a key to a solid sprint review, it’s preparation—somewhere safely between “way too much” and “totally winging it.” You should put some thought into what work is relevant for the review, in what flow should it be demonstrated, and how it connects to previous and upcoming sprint work.

   Quite often someone with a QA background will develop a review ‘script’ that helps the team expose their efforts in a cohesive way. Ultimately, the Product Owner should have the strongest voice into what gets exposed and why—setting the stage for the ‘reveal’ with the stakeholders.

   If in doubt, reserve sufficient time in sprint planning for review preparation and DO prepare.

6. Execution & Demonstration

   The review demo needs to be smooth, thoughtful, polished, and ultimately the software needs to work flawlessly. Dry-running the demo and having everything pre-setup is a must. You should also do timings to ensure your demos fit into your allotted time. And don’t forget about Q&A time.

   Beyond the demo, you need to tell a story that encompasses your feature workflows. I’ve seen teams in their first sprint show an architectural diagram that reflected the work they planned for the upcoming six sprints. Then in each sprint review, they “filled in the boxes” as they began to flesh out the application architecture. I thought this approach was an outstanding way to “connect the dots” for the audience.

   From my perspective, ALL WORK that a team took on in a sprint is a candidate for exposure. That might include features, enhancements, bug fixes, refactoring, documentation, testing infrastructure, virtually everything. Sure, some things might require some finesse to demonstrate or illustrate, but if it’s work the team did—it’s a candidate for the review.

   And finally, be ready to explain things sufficiently so your audience UNDERSTANDS what you’ve just shown, its significance, and the level of effort behind it.

7. Wrap-up

   Finally, we always wrapped up reviews with a general request for feedback—both on the software itself, but also on our review dynamics. Were the transitions well made? Did we explain what we did? Do you know how to send us your feedback? And what can we change to make the next review even better?  We usually only spend a few minutes here, but it’s time well spent. If you’re familiar with the notion of a Fist-of-Five, we usually leveraged that technique for closing feedback.

Sample meeting agenda

Consider the following as a healthy template for your team’s sprint review agenda:

1. Introduction
2. Team Chart
   • who’s-who: names, roles, and location of team members
   • external folks who helped with the sprint
3. Acknowledgements – Appreciations
   • certainly shout-outs for team members
   • but also a good time to recognize “external folks” who were instrumental in the sprint
4. Sprint Goal
   • articulate the Sprint Goal, speak to any adjustments that were made during the sprint
   • call it: was the sprint a success, i.e., did the team meet their commitment to the sprint goal?
5. Strategy? Success? Efforts? Discoveries? Results?
   • share any relevant strategies the team used to deliver the work
   • explore the effort behind the sprint
   • were there any discoveries that were unexpected; any critical results?
   • all of this is to give the audience a “behind-the-scenes” look at the team’s sprint
6. Demos, Q&A
   • demo the selected set of user stories / features—allow for Q&A
7. Coming Attractions
   • speak to progress to release goal(s) and upcoming work in future sprints
8. Fist-of-Five Toward Improvement
   • engage the audience in review-performance feedback
9. Close

Wrapping up

I simply can’t tell you how good it feels to have a high-impact sprint review. And while I put a lot of pressure on the Product Owner and team for the results of the review, as an Agile Project Manager you play a central role as well.

Teams often get “caught up” in the work of the sprint and short-shrift the review preparation. In fact, this is a common anti-pattern. You can turn this around in sprint planning—asking the team to plan for and allocate sufficient time toward the review, while also reminding them as the end of the sprint approaches to consolidate their work.

Remember, the review is also a “QA checkpoint” for the team. There’s nothing like pulling things together and demoing them—to bring a healthy dose of reality to a team’s sprint efforts. You always shake things out—environments that don’t work, integrations that weren’t made, and interactions that were forgotten.

So Agile Project Managers, I hope this post has inspired you to take charge of your reviews and make them the most powerful event within your agile teams. While it is certainly the team’s responsibility to prepare and deliver, you can influence the attitude and approaches. You can also amplify the positive feedback you’ll get as you improve.

Thanks for listening,

Bob.

BTW: a presentation of this material was shared at the 2012 Atlanta Scrum Gathering. You might find it interesting as it complements this article.

Don’t forget to leave your comments below.