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