Implementing Agile the Right Way: 3 Steps to Avoid Agile Silos
According to Version One’s 10th Annual State of Agile Report, 95% of all organizations surveyed now practice agile. This is a direct benefit of all the hard work and proven success the agile community has put in for years. Universal Mind, in particular, has remained dedicated to furthering the success of agile by contributing to the agile community with years of empirical knowledge across many verticals, successfully releasing countless enterprise solutions.
With that said, let’s continue that tradition by helping you to either avoid the pain of replacing your current legacy silos with shiny new agile silos or put a few more pieces in place that can help expedite your transformation to becoming an agile organization, avoiding a common pitfall when starting from the ground up.
First, let’s establish a common understanding of what the term silo means in the context of software development. A silo, by definition, is a system, process, department, etc. that operates in isolation from others. Silos can exist at many levels in the organization, including large business unit silos and practice level silos such as IT or marketing, that don’t effectively collaborate with each other. However, many organizations start their agile transformation from the ground up by organizing individual scrum teams.
Without an understanding of how agile teams operate at scale, you may be quick to assume, based on the general definition of a silo, that the collaborative approach to software development, as defined by the Agile Manifesto, would solve the problem of silos. It certainly can when you apply that principle to a single scrum team but when trying to leverage multiple scrum teams aligned to a common mission, that begins to break down pretty quickly without some sort of program wrapped around it. It’s important to understand you are placing agile teams in an ecosystem (with a strong emphasis on the word “system”) that has not been designed to support or empower the agile methods.
This usually occurs when starting from the bottom up by replacing waterfall component based teams with high powered, cross-functional agile feature teams. The problem is those silos are just replaced, not removed, as the ecosystem has not actually changed. Our high powered agile teams are probably still surrounded with legacy processes that will not allow a real flow and the ability to align on a common vision. If you still see things like gating approval processes, a user experience team that remains isolated from execution, centralized decision making that does not empower product managers to make decisions and disparate backlogs with no global vision, it is a clear sign there is more work to do. To fully understand and reap the rewards of agile within your organization, we have to empower and surround these teams with an agile mindset from top to bottom. Your organization needs to empower a culture where motivation and incentives are derived from customer satisfaction.
If you have two or more agile teams operating on similar initiatives and you are either not ready to implement a Scaled Agile solution such as SAFe or it just does not meet the criteria for doing so, let’s explore how we can apply some concepts from the house of lean to achieve flow and help to optimize the whole. Your agile teams will require a good deal of help not only to break down the existing silos but to improve quality, predictability, employee retention, and the overall value of your solutions. Our focus today will be about breaking down those silos.
Here are three simple steps that can be applied to prevent or remove those silos:
Step #1: Create a Program Vision
One of the most important things you can begin to do to avoid agile silos is to create a “Product/Program Vision” that will serve as a guiding light for the team’s next iteration. In order to provide that level of clarity, we will need to have an up-to-date prioritized Program Backlog. The most efficient way to groom and manage a Program Backlog is Kanban. The Program Backlog, when fed by an agile portfolio, can easily align with the mission, vision, and values of the organization. This backlog should be able to clearly articulate the best path forward by including the proper business context and objectives, valid success criteria, achievable KPIs and the architectural and experience runway required to build the features that provide tangible value to the end user.
What value does a Product/Program Vision managed via a Program Backlog provide?
- We now have a location and general process we can align resources around. We can have an agile coach/scrum master administer a predictable set of processes on a common backlog that Business, Marketing, IT, UX and QA leadership can rally around and provide a cohesive vision to a multitude of scrum teams.
- By setting a program vision we can make sure all of the team’s backlogs remain loosely coupled. This ensures we don’t add any gatings back into the scrum process, enabling the team to decide how to best deliver value, yet remain aligned to an approved vision and set of objectives by product management.
- By setting a program vision we ensure that we are not duplicating task across multiple teams. If the teams are being utilized in a best practice of emergent architecture for things like global web services or adding systems capabilities, this will help maintain a transparent governance model that will provide a common place to understand who is doing what and why.
Step #2: Synchronized Cadence
Another way to avoid creating agile silos is to make sure the development teams are operating on the same cadence and synchronized to a similar schedule.
What value does working on the same schedule provide?
- To be able to take advantage of the emergent architecture we described above, we need to have the ability to resolve dependencies across multiple teams by understanding when they will provide their part. If the development teams are to be dependent on services or APIs to fulfill their mission of working software, they will need to coordinate efforts across multiple initiatives.
- When operating on the same cadence and synchronized schedule we can again make sure all of the team’s backlogs remain loosely coupled. (Are you seeing a common theme?)
- This also helps remove a silo that would be created when the team backlogs are loosely coupled by ensuring the leadership that helped to prepare the program backlog has the ability to communicate with the rest of the organization as to what value will be provided and when. By allowing teams to operate on the global vision yet remain independent, we give them the ability to move quickly and decide how best to provide that value. However, this does not remove the constraint of knowing when and how we will provide that value to our customers.
Step #3: Release Planning
My final recommendation to avoid creating agile silos is to plan together as a team of teams. One of the most powerful processes that SAFe prescribes is the release planning session. I have been part of many sessions and I believe this is where the real magic of scaled agile happens. In the spirit of lean approach, for those not practicing SAFe, here are a couple of ways you can take advantage of this level of planning without all the formality.
What value does planning together provide?
- In SAFe release, planning is when every resource is brought together to do a group sprint planning session and leadership is involved in order to make this session a real event. Approach can be simplified for smaller teams by having the resources that are managing the program backlog come together regularly with the Product Owners, UX and Tech Architects to talk about what objectives they would like to see accomplished within an agreed timebox. It would unify the vision and help with general agreement up front as to what can be done as a team of teams and most importantly be able to deliver on that commitment.
- A prioritized list of the top ten features and objectives can be used to drive a quick planning session that would ensure development teams are not left on their own to align to a common vision. All too often I see agile teams go into a never ending mode of delivering features that don’t align with a specific objective because they have no understanding of what is actually trying to be accomplished at a high level. So instead they do what they are built to do, which is to provide value based on current context as to what they believe will be of value to customers.
- By creating a unified program vision, it exposes the next challenge within the organization in that there is no agile portfolio to keep the pipeline full and aligned at the executive level. In the spirit of doing things the agile way through small iterations and learning cycles, the program planning session will help to continue forcing alignment all the way back up the chain to the overall business objectives of the organization.
In summary, I have a great appreciation for companies that are taking on any level of transformation that can lead to a better way of doing things, especially if they are selecting lean-agile methods to get there.
As an agile evangelist for Universal Mind with over a decade of experience in coaching, mentoring and problem-solving to help companies make this type of transformation, I want to be clear that the points I described above are just the tip of the iceberg. Using agile methods to develop software is a great way to build a better product, however, to be successful you must consider everything that happens before you actually start development. When it comes to achieving the agile mindset and providing sustainable value to your customers, your journey away from legacy practices, procedures and principles will be relentless. The fact that you have introduced agile teams is a great first step. Adding that program layer is the next logical step and one that is very achievable without the need of doing it the corporate way by calling it a re-org.
I hope this information helps immediately when applied. If results are not exactly what you were looking for right away, I can still guarantee you one thing - if you take the time to inspect and adapt what you’ve learned along the way, you will absolutely be able to do it a little bit better when applying those learnings back to your system and trying again.