Chances are, if you’ve been engaged with any IT development lately, you’ve heard of “Agile delivery” and its promise of delivering more value to the customer quickly and inexpensively. Agile originated as a software delivery method aimed at providing customer value faster, along with frequent stakeholder engagement, and continuous improvement. Agile methodologies present standard ways of developing software within teams, but Agile stakeholder and IT interaction models aren’t as easily defined, especially when scaling Agile throughout the enterprise.
Agile has been proven as a solution for websites or products that have strong customer-facing engagement, as end-user involvement and feedback is at the backbone of the Agile methodology. But what about groups that aren’t delivering for the end user and instead are powering the business itself? The Agile transformation path for these Enterprise Platforms groups is often less clear and can be a major hurdle for an organization to reach its Agile transformation vision.
We’ll take you through some examples of how the Agile journey for Enterprise Platforms groups differs from typical product-focused delivery, along with keys for success in three key areas: value delivery, operating model, and Agile mindset.
VALUE DELIVERY:
Process versus Product
Enterprise Platforms are crucial to an organization. The core business functions they power include marketing, sales, financials, billing, client service, and HR. Each business function is key to the success of product development, but the functions operate differently from product development and therefore need a different approach during an Agile transformation.
The focus of an Agile transformation for Enterprise Platforms is more about process enablement than product development. The goal is to enable teams and their business partners to deliver valuable front- and back-office capabilities that will, in turn, support the rest of the organization’s product delivery.
While a product group’s goal is often to deliver something that’s cutting-edge or market changing, there may be less creative license with delivering internal business capabilities. You must balance taking operational business processes, compliance, and legal matters into account (e.g., Sarbanes-Oxley, documentation requirements) with quick responsiveness to user feedback.
However, rapid learning cycles are crucial to Agile, so some level of experimental failure is necessary. For these enterprise functions, this requires careful examination of where such rapid learning environments are stood up. Even more importantly, it requires setting new expectations with appropriate business partners, so they can trust that delivery teams will maintain good practices, leading to quality outcomes.
Another key tenant for Agile transformations is encouraging the teams to adopt an iterative development cycle. This often means working in two- to three-week “sprints,” during which an entire cycle—from requirements through delivery—can occur, and goals may be achieved iteratively over multiple sprints. For Enterprise Platforms the key is to break down larger business support processes into smaller increments of value that teams can deliver over a series of sprints. It is crucial to create shared understanding with technology leaders and business partners that in the new Agile model, the first few iterations of delivered work may remain foundational, as the ultimate value is delivered incrementally. This requires an adjustment of expectations from traditional methodologies in which all the work is delivered in one “big bang” functional release.
This new delivery cadence presents a unique need for change management and training. From an end user perspective, there is a delicate balance between enough training to understand key new functionality as it’s released, against too much training to be absorbed. One way to check whether the training and release cadence is working for business users is to implement another key tenant of Agile transformation: feedback loops and regular improvement cycles.
By providing a mechanism to give and receive feedback, organizations are able to quickly identify what is working and what needs to change. For example, a pulse survey conducted on a new feature released to sales teams leads to a quick value outcome measurement and the ability to pivot as needed based on feedback.
OPERATING MODEL:
Federated Stakeholders
One of the most challenging parts of an organization’s Agile transformation can be aligning to a new operating model. Agile operating models ideally limit the number of decision-makers to enable faster and clearer decision-making. Enterprise functions, however, often serve multiple business areas with federated stakeholder groups, thus violating the principle of small team size and a minimal number of decision-makers. This requires the organization to align to a new structure of decision rights and makes the operating model definition more challenging. Multiple cross-enterprise stakeholders for the same capability or business process also make the teams’ backlogs complex and leads to competing priorities.
An effective operating model defines a limited number of business and technology leaders who are jointly accountable for decision-making at each layer of the organization. Although these leadership teams are ultimately responsible for setting the direction and making decisions, they pull in other business and technology partners to inform and advise on the best path forward. This model of clearly defined accountability through joint leadership teams is a crucial step in gaining alignment at executive leadership levels and transparency throughout the organization. Additionally, leadership at the team level must be empowered to own the team’s backlog and make daily priority decisions with support of scaled leadership throughout the organization.
A robust change management plan is essential for an Agile transformation’s success, especially related to operating model shifts. As almost every business and technology partner’s daily responsibilities will change, the proper training and communications are needed to avoid ambiguity and misunderstanding. If people don’t clearly know what’s expected of their new roles, then frustration and mistrust will likely occur, and the Agile transformation will sputter out before it really begins.
Executive leadership sets the Lean-Agile example throughout the organization. It’s crucial that executive leadership is collaborating and aligned, or the lack of consensus/direction will trickle down and hinder the teams’ ability to deliver on goals and cause resistance to the transformation. Team members, managers, and business partners all need to understand their roles and responsibilities, and how they interact with each other within the Agile operating model before it can be effectively stood up.
A fundamental way to build acceptance of a new operating model is to provide forums and groups that enable sharing of lessons learned and support as people grow together in their new roles. For example, Centers of Excellence (e.g., Quality, DevOps) and Communities of Practice (e.g., Scrum Masters, Architects) foster peer-to-peer relationship development to help drive an Agile mindset shift and successful role changes. These groups need to be developed early and actively nurtured during the Agile transformation efforts to allow for feedback loops, support, and shared learning to take place and evolve throughout the transformation.
AGILE MINDSET:
Collaborative Journey
One of the main success drivers of any Agile transformation is breaking down the “business versus IT” mentality and removing organizational silos. Business partners should be included directly within the teams; for Enterprise Platforms, that includes “process manager” and “process owner” roles. They serve as the main business contact to the teams, providing business process context and making day-to-day priority decisions.
By including business partners within the teams, they’re able to learn firsthand and understand the technical foundation that is critical to enable business processes. They can then share this knowledge with other business partners who may have competing priorities, to better align and plan towards the organization’s common goals.
As one Enterprise Platforms senior business leader described the benefits, “I was in sales and I always looked at technology and said, ‘Why can’t they just get this done? Why is this taking so long? Why haven’t they delivered this? The client needs it.’ So, what I learned the hard way with a little bit of an ego—like, ‘I know the client and you don’t’—I learned very quickly that the technology teams work really, really hard and the amount of work that it takes to build something is real. So now that I understand that pain I’m probably the biggest advocate for technology in our delivery model.”
While it’s a huge success to have business engaged and bought into the development process, it’s also crucial that other, more ancillary business partners, who help deliver or ultimately consume the work buy in as well. Other business groups—including business readiness, training, communications, market readiness, and legal—all need to be educated on the Agile delivery model and the new expectations for their partnership in delivering work.
Conclusion
There’s not a one-size-fits-all Agile transformation solution for every company or team. Each organization needs to define its Agile journey based on a set of factors, including its business functions, stakeholder landscape, and delivery model. However, every organization can benefit from joint, cross-functional leadership teams throughout the organization. This will not only enhance decision-making and prioritization efforts, but also break down silos, build transparency, and improve alignment.
At the core of an Agile transformation is the Agile mindset—business and technology team members, managers, and partners all need to be bought in and collaborate to achieve success. An Agile transformation is a journey—organizations need to continually inspect and adapt—conducting retrospectives to learn key insights and make improvements as needed.
