There are many approaches to transition to Agile from more traditional software development methodologies, like waterfall. Some organizations’ transition can be easy while others find it difficult, and in some cases, even impossible, reverting to waterfall or less iterative approaches along the spectrum. The key, I’ve found, to mastering an agile transition is finding what works for your organization and what your team members feel comfortable with. If neither are happy, and you can’t find a balance, then Agile in your organization will most likely fail.  

The first thing to realize is that there isn’t a one size fits all way to transition to following Agile practices. First, you need to understand what Agile means to your organization and the team members who will be the practitioners. Talk to team members, project stakeholders, and executives to develop an understanding of their expectations and what they expect to achieve and use that to help shape what Agile will look like within your organization. Creating a cross-functional team to help you with the transition can also help by bringing to the table voices from all teams impacted by this shift in methodologies. They can act as champions within each of their functional areas.

Here are three initial areas I’ve found as helpful starting points when creating an organization-specific definition of Agile:

• Metrics - Establish clear metrics and goals that can be measured at the onset and throughout the effort to track your progress to becoming an Agile organization
• Organizational Support - Put in place a support system that spans all organization levels from individual contributors to executives and project sponsors; everyone needs to be on board. This support will look different in every organization, so find your champions and leverage them to support your transition.
• Empowered Teams - Having teams empowered and trusted to work independently towards defined goals and allowed to fail fast is critical. In my opinion, it is key to making Agile work.

Let’s look at each of these areas in more detail.

Establishing the Right Metrics

To start a transition to Agile, one of the most important aspects is to have clearly defined metrics and goals around what the organization is expecting to achieve from embracing Agile.  Many believe that Agile is delivering more at a faster rate, and while that may be one possible outcome, is that really the goal your organization is trying to achieve?  Knowing this early in your transition is crucial, along with gaining alignment upfront on those goals across your organization, use your cross-functional support network, more on that next.  The outcome of defining these goals is to help identify which goals and metrics work for you and which ones may work against you.

Some goals or metrics to discuss with a cross functional team and gain alignment on could include:

• ‍Revenue/Conversions – Does moving to Agile help you deliver more, so therefore the expectation is more revenue or conversions? Tying revenue and conversion metrics directly to Agile may not be a good decision; just because you are doing more work faster doesn’t mean the work is leading to a better product in the end. You may actually be delivering a worse product faster and negatively impact your revenue/conversion metrics; though you can fail fast and pivot if needed once you are using an Agile approach.
• Speed to market – Is the goal to get small incremental changes to your product to market faster, learn and adjust the product, or is it to deliver something completely new all at once?  If the latter, then you may want to consider something other than Agile as you may only have one shot at delivering and need to do so in the least risky way possible. You should also weigh the market risk of waiting for a big bang verse getting something to market fast and achieving market mover advantage.
• Product Quality – If you increase the speed of delivery, it also requires you to increase your testing and oftentimes shortens QA cycles, which means you do increase the risk of introducing defects; are you OK with that risk? No matter how much automated testing you perform and how good your QA team is, there is more chance of increasing your defect count when producing more at a faster rate.
• R&D – Is a goal to try and quickly push through new ideas? If so, you may want to move your Agile team outside of your current organizational structure fully so they can independently prove ideas. Once proven, ideas can be moved back into your primary delivery team/s using their methodology, agile or otherwise, to productize and commercialize.

These are just a few ideas for conversation starters when defining your organization’s specific goals for Agile.

Building Support

Organizational Support will be a key factor in the success or failure of your transition to agile, so build a wide support network as early as possible.  This network will help you throughout your journey and provide support in many ways you may not have thought.  Some example support areas include:  

• Funding – Funding often has impacts on how teams operate and how work is performed. Agile must have a focused and dedicated team/s, in my opinion, which many times challenges the traditional team and work funding models used in organizations. Partner with your finance team, make them part of your transition team even,  to help establish a funding model conducive to funding and tracking your costs when operating in an agile environment.
• Resourcing –  If teams outside of your immediate organization request support in an ad-hoc manner, you will need your resource manager/s or sometimes senior level management to help push back on these groups to work through a product owner to create a backlog item.  This “noise” can be one of the biggest disruptors that agile teams face when someone tries to squeeze something into a sprint after the sprint has been planned and locked.
• Executive Buy-in - Support from your top-level executives is key for any organizational transition, Agile included. Educating them on what Agile means to the organization as defined by your transition team and your goals is the first step, quickly followed by asking for their support during this transition. Having a well-informed executive lend support to an Agile transition can often help remove other barriers like funding, resourcing constraints, and achieving buy-in from other groups who may not be as excited to try something new as you and your team/s are.

Now that your organization has defined Agile and you have a support network spanning all levels of the organization, it’s time to empower the team/s to deliver!

Empower the Delivery

With a set of clearly defined goals and a support network in place, your teams using Agile should now be empowered to execute. To achieve the goals your organization has defined for Agile, your teams need to self-govern and make decisions in real-time as they complete their work. One of the reasons more traditional software development methodologies are slower to deliver is tied to the number of controls, stage gates, reviews, and approvals teams need to go through, which is not agile. Agile also doesn’t mean teams operate in chaos; instead, teams should be empowered to internalize traditional methodologies’ checks and balances by making them a part of how they operate.

For organizations transitioning from a very rigid approach, this may be one of the hardest aspects of the transition.  Executives and/or management oftentimes do not feel comfortable empowering their teams to self-govern and make decisions about a product’s forward trajectory, but this can be detrimental to teams effectively operating in an agile manner.  Executives or managers who feel they need to be involved directly in a team’s delivery should have an exit strategy after a few sprints to allow the teams to move into a self-governance model.  The ability to self-govern not only will teams to achieve velocity, but also creates a sense of ownership and pride in their work.    

No Immediate Success

‍
I have seen agile be very successful through my experiences, but it wasn’t something that was achieved immediately. In the agile transitions that I have been involved in, it took approximately two years before we could confidently say that Agile was working for us, and teams were operating in an agile manner. During these transition periods, we also had to make adjustments, like modifying sprint cadences to allow enough time to develop code and thoroughly test to ensure we were not impacting our stability and uptime SLAs. In one instance, we initially didn’t have the necessary executive buy-in, which led to many conversations about what was being delivered and when, which could have been avoided had we clearly defined and communicated our approach and goals through our support network or had day one executive buy-in. These were instances where we failed quickly, learned from our mistakes, and were empowered to pivot and continue on our path of meeting our ultimate goal of running an agile organization.