You’re Not Agile Just Because You Say, Think, and Feel Like You Are
Imagine investing thousands of dollars in exercise equipment and setting it up in the garage. Imagine then, after having maybe used it once or twice and letting it collect dust, you insist to a friend that you’re actually getting in shape.
That’s a clunky example, but it bears out when we see a lot of organizations that are—in a sense—“doing agile” performatively. A 2020 McKinsey survey found that 70% of the companies they spoke with were in the midst of a stalled agile transformation. Many respondents reported stagnating cultures where bottlenecks, a lack of vision, and “insufficient resources” remained problematic and stifling.
Why, when you’re deploying a culture that’s by design meant to unburden companies from those very things, do those people and management issues proliferate? Practically speaking, it’s because the doing of agile is always more challenging and requires time, patience, and action.
Anyone can rattle off the 12 principles of agile. What does that look like in practice? Let’s look at “doing” agile through the lens of the humble user story.
BEING: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Doing: “Why” Statements In Your Stories
It’s not about figuring out the quickest, most efficient way to get software into your customers' hands. It’s about looking beyond what they say they want and getting to the heart of what they can’t live without.
Boil down the essence of each story to a “why” statement. Namely: Why is this valuable for your users or buyers?
BEING: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Doing: Stories Are Options…Not Commitments
If you’re genuinely delivering products in an agile environment, your product owner should be able to reprioritize and shuffle based on the changing needs of your customers and competitive realities.
If you’re not, you’re just sticking to a stubborn “to-do” list that may be out of date by the time you deliver the thing you were building in the first place.
Contextualize stories in your product backlog as options rather than commitments. Put the power in the hands of the product owner to reprioritize any story on demand.
BEING: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
Doing: Commit to What You Can Deliver
When we set goals, we automatically also set up a biochemical chain of dominos. We are inherently wired to assume that goal, no matter how small or incremental, is essential to our actual (and literal) existence. Put another way, the minute we set ourselves on a path toward any event, whether that’s going to the grocery store, fixing the garage door, or delivering a new feature, we are gambling with our brain chemistry. We do the thing: We get a nice surge of dopamine? We fail…you get it.
In a truly agile environment, therefore, you don’t commit a story to an iteration unless you’re confident you can deliver. Long, drawn-out projects with a lack of an end-date communicate literal failure to us on a physical level. It’s easier to succeed when the horizon for success is near term.
BEING: Business people and developers must work together daily throughout the project.
Doing: Stories Are Promises for Collaboration
Going back to our little biochem lesson: Humans (and you know this already, but it bears repeating) are tribal. Functional teamwork is not just necessary. It’s how we’re wired for work.
You can tell the business side and the development side they have to collaborate all you want. As you try to do agile “things” instead of trying to do things in an agile way, remember that each story is a promise for healthy, productive, and successful collaboration.
BEING: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Doing: Hypothesis-Driven Stories
How you write stories is a baseline for both collaboration and motivation. So each story doesn’t have to contain specifics, at least initially. If you stay on the experimental side of the ledger longer, you’re that much more likely to invest in solutions rather than solving arbitrary problems that don’t help your customers.
Pro tip: Write your stories as a problem statement or hypothesis so the team can solve together.
BEING: The most efficient and effective method of conveying information to, and within, a development team is face-to-face conversation.
Doing: Stories Are Conversation Starters
Stories are a way to convey information between stakeholders on the team. Think of them as a way to encourage face-to-face conversations.
When you’re writing stories, remember you’re doing so with the intent of jumpstarting conversation. Use stories to maximize the amount of conversation that happens in real time.
BEING: Working software is the primary measure of progress.
Doing: User-Driven Stories
The single most important aspect of any story is the user on the other side of it. Working alone isn’t a measure of progress. Write stories that represent value to your users, rather than activities like testing or coding. That way, when a story is done, you’ve delivered some value.
BEING: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Doing: Do What You Can Within the Time You Actually Have
Agile processes involve sustainable creativity and development. If we go back to the biochemistry of success, it’s setting people up to feel like they’re achieving what’s set out in front of them. To increase the likelihood of meeting commitments, craft small stories with the intent of knowing how much you can deliver within a timebox (dopamine!).
BEING: Continuous attention to technical excellence and good design enhances agility.
Doing: Give the Team the Freedom to Experiment in EACH Story
Each company and its products will have a unique, or at least a dynamic, set of metrics that inform product leadership if the product is working…or not. Continuous delivery doesn’t matter if what you’re delivering isn’t remotely useful or well made.
Trust, freedom, experimentation, and failure are key components to a truly agile culture. What users and stakeholders needed six months ago (or what you assumed they needed, anyway) may have changed. To give customers what they need, give the team the freedom to redesign and improve the system within each story.
BEING: Simplicity—the art of maximizing the amount of work not done—is essential.
Doing: Write Small(er) Stories.
What does it really mean to maximize the work not done? If it was as easy as it sounds…
In practice, that means starting small, each and every time. Write stories to be as small as possible while maintaining some element of value. And don’t work too many of them at one time.
BEING: The best architectures, requirements, and designs emerge from self-organizing teams.
Doing: Allow Stories to Evolve Over Time
Organizations often feel obligated to inject efficiency and control into their systems to prevent chaos. However, dogmatic oversight can lead to sterile, uninteresting, flawed products. Resist the temptation to hand a fully specced-out story to a team. Their first attempt at delivery might not be a bulls-eye, but over time it will become something light years beyond what external management could describe.
BEING: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Doing: Find Better Ways of Making Small Stories
Your retrospectives are your opportunity to improve your practices. Is the state of your user stories helping or hurting your ability to deliver software? What can you do to improve them? (And please don’t say “Get better requirements specification up front!”!) Can you make them smaller? Can you structure them to make for better conversation starters?
Yes, we have this in visual form, too. Click HERE to download our “Being VS Doing” infographic.
If you want to talk to one of the members of our team about what we do and how we can help you do what you do better, contact us here.
Tag(s):
Agile
