Kickstarting Your Agile Transformation: A Step-by-Step Guide for Executives

A top-down view of a spiral staircase
Peter Reynolds

Client Partner

Peter Reynolds

This is the third post in our series on Agile for Executives. Read our first post and second post for more information on how agile can transform your organization for the better.

You are ready to go. You’ve read all the books, heard enough success stories, and learned the right terms. You’re readyto start your agile transformation—but how do you start?

You set the standard, cast vision and lead into uncertainty, champion collaboration and flexibility, and focus on theuser and their outcome.

With such a daunting task, a numbered list always helps.

How do executives set the standard?

After reading up on culture and process, it might be tempting to think that agile applies only to the engineering department. This is not the case.

Agility impacts every corner of the organization, and you get to hold the wheel. These first few steps enable you to lead the way in your agile transformation.

1. Eliminate the Whirlwind

I once worked at a company that put the engineering team in a literal hallway. Every few minutes, someone would walk by on their way to the next meeting, more often than not asking about the status of some ticket or requesting a new feature along the way.

The worst offender in this case was the CEO, who communicated direction changes via drive-by comments and made impromptu changes without involving the proper channels. As you can imagine, this created a chaotic environment for both the engineers and the product itself. This classic comic illustrates the impact of those interruptions well. Be wary to take inventory of yourself too — Sometimes you are the whirlwind.

Every additional voice pulling the team in a different direction creates dissonance and drag on the enhancement of the product. Requests predicated by, “While you have the hood up,” “If it’s a small lift,” and “This just came up but I want it” lead to unvetted items at the top of a queue, often interrupting the outcome-driven priority. The impact of work driven by these interruptions instead of outcome-focused planning is the same no matter how large or small the request:

As an executive, you have the authority to eliminate many of the interrupt-driven features and miscellaneous requests that have far-reaching impacts on the product team. Instead, set goals around outcomes, not output-oriented tasks. Support targets of “X metric of user engagement” and “Y use case” instead of “X amount of tickets” or “Y feature as originally designed”.

2. Empower the Product Owner

As mentioned in a previous post, the entire system depends on trusting the Product Owner to listen to all stakeholders and rank priorities based on everyone’s feedback. Empowering them to communicate and keep the team on track means you’ll take a step back from the day-to-day direction of the team. Giving them authority to set priority based on feedback means ceding some control over the direction of the product.

Trust the PO to hear every priority and pick the ones with the best user outcome. Don’t circumvent this process by going straight to an engineer with a new idea or a feature request. If you subvert the process, others will too. Communicating new requests thoroughly to the PO and backing their priority rank shows trust in the individual and empowers them to do their job well. This takes humility, trust, and an open-handed understanding that sometimes you *don’t *know best about the shape or impact of certain features.

3. Understand User Stories

User stories identify the user, define their goal, and link that goal to a grander outcome. By refining and iterating through user stories, you keep the focus on the user and prioritize the stories centering around the most important outcomes. As the product team works through these user stories, they keep the user’s context and goals as the centerpiece of the solution and design creatively flexible solutions. Writing user stories requires empathy for the user and their experience. As the organization begins to ask for new features in the format of the user story, the entire organization is forced to put its users first.

4. Embrace MVPs

Teams hit deadlines by slashing scope and focusing on “vertically sliced user stories’’, meaning they deliver one piece of fully functional software at a time rather than a huge feature set in a pile. MVPs, or Minimally Viable Products, describe a minimum set of features required to meet the basic user interaction goals of a product. An MVP delivers the fewest number of user stories possible to achieve the desired outcomes.

An 80% solution often resolves the user story, leaving more space for the next priority and experimentation. MVPs open up the platform to feedback faster, meaning you can measure and prioritize outcomes faster. Insistence on a full feature set before testing and delivery limits your windows for pivoting and feedback.

5. Abandon the Iron Triangle

This might be the hardest suggestion to implement, but its cascading effects make it the most important. The Iron Triangle describes cost, schedule, and scope as the three defining features of a project. Using different terms to describe the same shape, you may have heard “Between good, cheap, and fast, you can pick 2.” DockYard CEO Brian Cardarella explains some complexities of this adage as it applies to the Elixir world here.

Whichever terminology you use, the concept remains the same: cost, scope, and timelines are interconnected, and adjusting one affects the others. Boards and investors need to financially track investment and profit along certain deadlines, making this a constant conversation for executives like you. How then can we abandon it?

Agile provides freedom from this iron triangle. Rather than far-off deadlines, agile practices transparency through regular inspection and adaptation. Rather than a fixed scope at project outset, agile presents MVPs and partial solutions repeatedly iterated and adapted, slashing unnecessary scope along the way as feedback comes in and the market changes. Rather than a fixed lump project budget and a steady burnup rate, agile works best with titrated month-to-month “drip” funding as the product goal adapts to user and stakeholder feedback.

The iron triangle contradicts the agile mindset as it speaks about scope and schedule in fixed terms. Instead, an agile organization understands that scope should change over time and that will also shift schedules.

The ability to pivot quickly and listen to users means abandoning strict deadlines and “big-bang” style releases. Agile works in fluid scopes, consistent stakeholder feedback, and adaptive budgets. Restrictions around any of these three aspects consequently restrict adaptability, quality, and ultimately user outcomes.

Why should I do this?

Abandoning certain staples of the business world and loosening your hands from the reins takes courage and commitment, but the entire organization and every stakeholder will reap the benefits.

Constant feedback and focus create products adaptive to market changes rather than a guess at what the users might want in 12 months. Focus on user outcomes creates products that real people will use instead of products designed for hypothetical users. Servant leaders build trust and create spaces to innovate and experiment. The result is healthy work cultures centered on people, an environment without a constant grind for more output.

Given a safe, collaborative, and non-hurried environment, engineers and product teams alike develop sustainable, stable, and engaging products. And you, as an executive, get to lead the charge towards this better organization.

Ready to start seeing the benefits of agile for your products? Get in touch to learn how our team can put agile to work for you.


Stay in the Know

Get the latest news and insights on Elixir, Phoenix, machine learning, product strategy, and more—delivered straight to your inbox.

Narwin holding a press release sheet while opening the DockYard brand kit box