5 Beliefs Every Agile Journey Must Avoid

What are the beliefs that are guiding your organization’s Agile journey? As you’ve probably witnessed, those underlying beliefs influence how people behave on a daily basis, and when they are well aligned with Agile principles, then the pursuit can prove quite beneficial. When there is a stark misalignment, flawed beliefs in Agile can (and will likely) result in a challenging pursuit and even a failed Agile adoption.

What have you experienced in your organization?

High performance Agile organizations share a powerful and principled belief system that leads to increased value, innovation, vibrancy and a healthy element of delivery predictability within the workplace. I’ve also found that these inspiring companies are able to identify and address flawed Agile beliefs that introduce friction against the organization’s pursuit.

Here are a few that I’ve seen play out in a number of organizational contexts:

5 Beliefs Every Agile Journey Must Avoid

Belief #1 to Avoid

We need to compare waterfall and Agile to see which is better.

This belief can lead an organization down a fruitless path of endless opinion-littered debates that waste time, money and energy. When an organization has a sense of urgency for change, then it must invest its resources into changing, not trying to compare and prove that one approach is better than another. Besides, an organization can quickly examine a number of publicly-available comparisons that are available for review and learning.

To better understand the comparison of business outcomes between sequential delivery (waterfall phases with delivery at the end) and Agile (iterative, incremental, continuous value delivery), consider turning to insight-filled works like The New New Product Development Game, this flexible vs. sequential development approach study, and the latest research from The Standish Group. The groups behind these studies have done all of the hard work of comparison for us. Use the conclusions in these (and other) works to decide if an Agile Journey is the right pursuit for addressing your organization’s sense of urgency.

Belief #2 to Avoid

Agile Teams must ‘commit’ to their User Stories at the beginning of a Sprint.

I once encountered a skeptical manager who told me something like: “I believe that *my* Teams must deliver all the User Stories that are ‘committed’.” Careful  … this is a dangerous belief that often leads to challenged business outcomes. When I first encountered this supposedly “Agile” setup, I quickly discovered that the manager was pressuring the Teams to make scope commitments each Sprint. In this situation, no one actually committed to anything except for the manager (who, under organizational pressures, made an unrealistic promise on the scope).

Not only were the Teams consistently falling short of the “commitment” (thus deteriorating Team morale and eroding the predictability element of Agile), the evolving Product was littered with increasing numbers of defects and mounting technical debt.

How do you see this? Is it a recipe for Agile failure?

This flawed belief is in direct conflict with the 3rd value statement from the Agile Manifesto:

Customer collaboration over contract negotiation

In Agile Teams, commitment is a shared value between Team Members —- not a rigid contract between the Teams and management. Once this is understood, it opens the door toward a goal-oriented way of working.

What’s so great about Goals?

In Scrum, for example, Teams craft and strive to meet a clear short-term business Goal each Sprint, which informs mid and long-term Roadmap Goals – all with full alignment to the Vision of the Product (or Project or Program – depending on your organization’s terminology). Goals introduce an element of flexibility, which guides Teams to deliver meaningful and valuable business outcomes on a consistent (i.e., predictable) basis. Most organizations tend to click the “like” button on this delightful rhythm – customers, users, business stakeholders, technology stakeholders, and the great Teams that are empowered with delivery responsibilities.

Continuing on the Scrum example, Teams share a commitment to each other to operate and behave in a way that maximizes their chances of reaching these Goals. When commitment is embraced as a value, then Teams are much better positioned to consistently meet the incremental Goals that ultimately realize the Product’s Vision.

How do you feel about this?

Belief #3 to Avoid

Agile Teams do not have fixed constraint contracts.

We should not confuse Disbelief #2 with the lack of contracts. Agile organizations are often faced with a contract (or an urgent situation) that has either a timeline or scope constraint.

For example, one company I coached had an urgency to deliver the first release of a next-generation app before its competitors, so they had a time-constrained Release Goal. In that situation, they invested extra up-front effort understanding the essential Features needed to deliver a competitive and cohesive first Release into the market. Once the Agile Teams were formed, they worked under the contractual constraint to deliver the first Release within the understood timeframe. To make this work, however, they had a high degree of flexibility to collaborate with the business on two fronts:

(1) the flexibility to deliver essential Features at varying levels of maturity — depending on what was possible within the time frame.

(2) the flexibility to change the Feature list in the Release Backlog — as everyone learned more, they worked together to adapt the Release Backlog to ensure that the highest-valued Features would ship with the first Release.

This flexibility was essential for delivering the first Release within the constrained time frame. I encourage your organization to learn more about the notion of Agile Contracting and how you can structure contractual relationships to operate in this manner.

How do your contractual relationships look right now?

Belief #4 to Avoid

A Daily Stand-up requires the Agile Team to stand, so the meeting will be short and focused.

At first glance, this might sound reasonable. In fact, many organizations’ Agile cultures have adopted this ubiquitous behavior. However, I have observed an alarming number of organizations where the Daily “Stand-up” was nothing more than a group of Developers standing in a circle and reporting their status to a manager who authoritatively stands in the middle of the circle. If this describes your Daily Stand-up, then watch out – because the person in the middle of the circle is not behaving as a Scrum Master and you’re missing out on the pursuit toward high performance, self-organizing Team behavior.

One of the big organizational changes in an Agile journey is the profound shift away from Team-level command & control project management and toward the emergence of small, empowered and self-organizing Delivery Teams. In Agile, daily progress & planning responsibilities shift to the actual Delivery Teams who are doing the work. In a Daily Stand-up event, the Teams don’t have to stand to maintain focus and discipline. Rather, the Teams must fully understand the purpose and intent of this event, which in turn guides their focused and disciplined behaviors during the event.

So, what is the purpose of a Daily Stand-up? It’s designed to provide a transparent and focused environment for Delivery Teams (i.e., Scrum Development Teams) to inspect their progress and adapt their plans in a way that maximizes their chances of reaching their shared Goal with the days that are left in the Sprint. The idea is to reach this outcome in roughly 15 minutes or less. If they choose to physically stand up to do this, great. If not, that’s fine too. In this event, a Scrum Master’s job is to teach and mentor Agile Delivery Teams on how to facilitate this event on their own … to the point where the Scrum Master doesn’t even need to attend.

What do you think of this?

I invite all of us to fully understand The Scrum Guide, which is the official definition of Scrum from the written words of the co-creators, Ken Schwaber and Jeff Sutherland. This will help avoid anchoring Disbelief #4 in your organization. As stated in the guide, this empirical event is called a Daily Scrum, not a Daily Stand-up – although it’s not the name that matters; what matters is fully understanding the purpose and intent of the event (i.e., the “why” behind a Daily Scrum).

If this daily event feels like a wasteful status meeting in your Teams, then consider re-aligning the name of the event and start mentoring around the actual purpose/intent as defined in the Scrum Guide. You might be surprised how quickly it can take hold and launch your Teams to a higher level of delivery performance.

Belief #5 to Avoid

<Insert a common misconception here>

What have you all learned about the beliefs that guide a successful Agile journey? What beliefs pose a danger toward that pursuit? Please share your thoughts on the 5th Belief That Every Agile Journey Must Avoid in the comments section below, so we can all learn from each other.

__________________

If my writings resonate with you, please consider spreading this message so we can energize and inspire the entire professional world together. I invite you to ‘Follow’ my professional journey through LinkedIn. I am also on Twitter.