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:
Let’s look at each of these areas in more detail.
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:
These are just a few ideas for conversation starters when defining your organization’s specific goals for Agile.
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:
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!
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.
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.