Rigid Agility

Being in the business of helping development teams and organizations become more effective, I get to see very diverse starting points. The clients of the last few months, however, had a lot in common.

They use one of the popular ALM (lifecycle management) tools.
They use Scrum, doing their best to fulfill its expectations for meetings, artifacts, and roles.
They’ve picked up many of the “best practices” associated with Scrum.
Despite the framework’s built-in continuous improvement loop, their process improves little.

People’s approach to work consists of many elements. Think about each element as being on a spectrum, from rigid to flexible. Most teams I meet place too many of their elements — especially the Scrum parts and those “best practices” — on the rigid side.

These teams’ rigidity is due to two beliefs they share: that the mechanics of Agile have to look a certain way, and that they should perform certain mechanics because they are good. I think neither belief is helpful: how can you be agile if you’re being rigid about its implementation?. Rather, you’ll be agile if you apply its mind-set. Here is my take on the most ubiquitous examples of haves and shoulds, and what the mind-set would guide you to do instead.

You do not have to have a daily recital of answers to three questions. You do, however, want the team to coordinate their activities so they maximize their likelihood of finishing and delivering by the end of the iteration.

You do not have to have a demo meeting if it’s not worth having. A common example of that is when the only non-delivery person to show up is the product owner, and she’s already seen everything. Another scenario is when the meeting yields no meaningful feedback about the product, making the meeting just an expensive get-together.

You do not have to diligently write down “What Worked Well?” and “What Needs Improvement?” in every retrospective. You do, however, need to reflect regularly (and frequently) on the team’s work and methods in order to make them better.

You do not have to spend one hour in planning per week of iteration length. Some teams do that usefully, others go mental with boredom. You do, however, have to identify enough meaningful work that can fit in the next iteration, and not make that determination too early so it stifles adaptation.

You do not have to have a single person own a story or a task. The ALM tool you use might lead you to think that, but that’s just a tool limitation. What you want to have is the team finishing valuable stuff. If work has to flow between people (and not just between roles such as dev and test), that’s not a problem; in fact, it’s often desirable.

You do not have to put hours on tasks and do iteration burndowns. Especially in software development, where it’s devilishly hard to get the tasks and numbers right. You do, however, need to have a decent sense of your ability to finish valuable stuff when the iteration timer dings.

You do not have to pick a ScrumMaster and a product owner who are different from the delivery team. You do, however, need to have someone look after the backlog from a business standpoint, and someone to help the team grow as a team. Yes, they need to be competent, empowered, knowledgeable, available, and effective. But if you’ve run out of appropriate and non-conflicted options, they can be the same person, or a manager, or a consultant.

And you certainly do not have to write each and every backlog item in the “As a … I want … so that …” template. I have yet to see a team where the exclusive (or merely frequent) use of this 20-year-old template helps. You do, however, want to have every backlog item address, implicitly or explicitly, these questions: So what? Who cares? How will we know we’re done?

So, on the spectrum of rigid to flexible, what do you put closer to the rigid end? Not the roles, artifacts, meetings, and definitely not context-free practices. Closer to the rigid side, you put values and principles: stuff to take a stand for, to emphasize, to permeate every action. For example, the Agile principles of “defer decisions to the last responsible moment,” “seek feedback assiduously,” “fail fast and cheap and maximize the learning from that,” and “people collaborate in cross-functional, semi-autonomous, self-organizing teams”. That’s the stuff that makes Agile agile and yields its benefits.

ONE LAST THING: Pragmatic leadership, as well as coaching and influencing others to act pragmatically in an Agile context, are a central theme in my course “Practical Agile Leadership.” If you see your teams reflected in my words above and would like to learn tools for increasing their Agility, consider attending the next session.