What To Do When Agile Turns Rigid

Gil Broza - March 2, 2016

You can find this article and many others at http://www.projectmanagement.com.

Agile has been advertised as cheaper, better, faster. And to boot, agile is touted to come with a clear process, a set of documented practices, tools and even certified consultants. So tempting that it has become the new darling in organizations large and small.

But here’s the rub: business improvements don’t always follow, while unpleasant side effects sometimes do happen. As a consultant, I am frequently called upon to help when an agile implementation isn’t quite meeting expectations. And although my clients struggle in different ways, early on they started using one of the popular agile lifecycle management (ALM) tools.

They use Scrum, doing their best to fulfill its expectations for practices, artifacts and roles.
They follow many of the “best practices” associated with agile.
Despite the framework’s built-in continuous improvement loop, their process improves little--they just try harder.

Agile is Not a Prescription. It’s a Mindset.

Agile is a specific approach to work. As such, it guides our decisions about what to work on, planning the work, engaging people and performing as teams, doing the work and working better. We reflect this mindset in team structure, process design, practices, tool choices, meetings and artifacts--all the visible elements of work that yield results. Think of each element as being on a spectrum, from rigid to flexible. Most teams I meet place too many of their work elements--especially the Scrum mechanics and those “best practices”--on the rigid side.

At the root of these teams’ rigidity is a conviction they all share: To be agile, we must organize ourselves a certain way and perform specific practices in certain ways. Both the teams and their management honestly believe that following certain prescriptions qualifies them as agile, and therefore they’ll achieve the promises of agile. In my experience, you cannot be agile if you’re being rigid about its implementation. Rather, you’ll be agile if you apply its mindset.

The Agile Mindset

Here are some ubiquitous examples of “haves” and “shoulds,” and what the mindset would guide you to consider instead.

Stand-up meetings: You do not have to stand up every day at the same time to answer the same three questions. The point is to frequently coordinate team activities to maximize the likelihood of finishing and delivering by the end of the iteration. The team can accomplish this with a single open question: “What’s the best progress we can make in the next 24 hours toward our iteration goal?” This question invites collaboration and doesn’t emphasize individual contributions and plans.

Writing backlog items: You do not have to write each and every backlog item by plugging it into the template, “As a ..., I want ... so that …” I have yet to see a team where the exclusive (or merely frequent) use of this template helps, even as training wheels. In fact, I encounter too many instances in which this fill-in-the-blanks exercise results in titles that are verbose, awkward or simply redundant. Instead, write briefly and communicate: What’s valuable about this work item? What problem or need does it address? Who cares? How will we know we’re done? Use these questions as a checklist--avoid the template--for mindful results.

Sprint planning: You do not have to spend hours in sprint planning, analyzing and estimating every micro-task. (Especially in software development, where it’s devilishly hard to determine the tasks and numbers correctly.) Some teams find that useful, others go mental with boredom. What’s important is to collaboratively identify enough meaningful work that can fit in the next iteration. It’s also important to not make that determination too early or too micro so it stifles adaptation. Some teams achieve that by constantly maintaining a list of the most likely items for their next iteration, and when the time comes to plan that iteration, they go with a gut feel of how much of that list they can accommodate.

Task ownership: You do not have to have a single person own a story or a task. Your ALM tool might lead you to think that, but that’s just a tool limitation. Worse, it opens the door to individual accountability, which in agile matters less than the team finishing valuable stuff and delighting their customer. Enable people to collaborate and to shift work items among themselves. In fact, with more brains on the task, the deliverable is more likely to be on target.

Picking a ScrumMaster and Product Owner: 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 work queue from a business standpoint, and someone to help the team succeed 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--a team member, a manager or a consultant. That’s being pragmatic.

Recurring demo meetings: And lastly, you do not have to have a recurring 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 he’s already seen everything. Go after the real goal, which is to receive actionable feedback about built features from people who asked for them a while back. There are so many ways to get that feedback!

So, What Makes “Agile” Agile?

On the spectrum of rigid to flexible, what do you want to put closer to the rigid end? Not the roles, artifacts, meetings, templates and definitely not context-free practices. Closer to the rigid side, you put values and principles: matters to take a stand for, to emphasize, to permeate every action. Examples include 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 “collaborate in cross-functional, semi-autonomous, self-organizing teams.” That’s what makes “agile” agile--and yields its benefits.

About the Author

broza gil Gil Broza's mission is to make software development more effective, humane and responsible. He helps people pick up where Scrum left off, especially on the technical and the human sides of Agile. Gil is the author of "The Human Side of Agile", the definitive practical book on leading Agile teams to greatness. Any given day, you can find him coaching, consulting, training, speaking, facilitating, and writing. Get Gil's popular 20-session mini-program, "Something Happened on the Way to Agile", free at OnTheWayToAgile.com.

You can find this article and many others at http://www.projectmanagement.com.