This article was written by Nazhin Beiramee, Jazmin Childress, Becki Hyde, and Nick Weiss.
How do you, as a large organization, undertake an agile transformation while maintaining the autonomy of each team? How do you build the momentum that creates successful, lasting cultural change? Which problem do you tackle first, and which metrics should you strive to impact? How do you scale and create governance for this new way of working?
VMware Tanzu Labs (formerly Pivotal Labs) has over 30 years of experience helping organizations delve into answering these questions and successfully transforming their software delivery practices. We do this by partnering with our customers to deliver a small but meaningful outcome (a pilot), then enabling them to incrementally build on the success of their pilot to shape the organization's culture and adapt to their constraints.
Since 2017, Tanzu Labs has partnered in over 250 government engagements that have become models of the modern public sector software factory, providing better services to constituents. Customers are now building better software, delivered by thousands of productive (and happy) engineers, engaging millions of users.
Organizations that successfully scale are able to increase their code quality, ship value faster, and get better software outcomes. However, those successes are not without challenges. Scaling the success of one product team to multiple can be daunting, yet is worth the return on investment. Here are the three phases of transformation we've seen our governmental customers experience, and what to watch out for along the way.
Phase 1: Create a pilot to deliver a mission outcome quickly
Whether your goal is to reduce costs or deliver a better experience to constituents seeking services, it is important to start small and think with an experimental mindset that is open to learning and continuously iterating. This will help reduce risks and increase the odds of success.
An initial experiment should include the following pieces:
- Software development team
- Problem to solve
- Hypothetical solution
- One to two success metrics
- Path to production
Balanced team
A balanced team (typically 8–10 people) should be composed of influential people who want to try something new and evangelize to others. A typical team should include a product manager, a product designer, and anywhere from two to six software developers.
The right problem
The problem this team solves should be small but meaningful to the organization and deliver the wow factor that will inspire others to adopt a new way of working. The problem should be acute, but not impossible, ideally creating working software in a short period of time, often within six to nine months.
While a problem has likely been identified in order to fund and organize the tiger team, it is important to give the product team autonomy to understand, validate, and potentially reframe the problem. Teams should have the opportunity to pivot and iterate on the solution as new information is learned and the problem landscape evolves, remaining focused on the outcomes being accomplished and value being delivered, rather than a predefined solution.
Define success
It’s important to clearly define qualitative and quantitative metrics for success for your pilot so that it can’t be written off as a fluke when the time comes to influence change at scale. Once these metrics are identified, it is beneficial to track and regularly assess them. Mission metrics or other metrics styles (e.g., Google Cloud DevOps Research and Assessment [DORA]) help communicate ways the team has been successful in both their approach and outcomes. Later, when looking to scale, these metrics will help sell the impactfulness of this new approach.
Clear path to production
To prove the value of this experiment and gain future adoption for this new way of working, it is critical for the pilot to make it into production. Commonly, government agencies experience many challenges, typically dependencies falling outside of their team that either drastically slow down the process, taking over 18 months, or halt the process of moving to production entirely.
Establishing a clear path early in development helps prove that it’s possible to get the pilot into production. If getting to production hurts, do it more often by testing and delivering leaner slices of code and automating the process when possible.
Getting to production also keeps up momentum by building traction with stakeholders and users. Adversely, the longer the team waits to get into production, the more features and complexity that will be included in the pilot. This increases the likelihood of the team building the wrong solution or one that never gets delivered. Unfortunately, in these cases, the experiment is unable to successfully scale across the organization and becomes the scapegoat for not continuing.
Phase 2: Define your practices and build critical mass
At this phase, it is important to focus on building a learning and self-sustaining organization as you scale. You have proven the art of possibility for some—but likely not all—aspects of a new way of working. Your first experiment was a success and has led to a pilot that delivered impactful mission outcomes. As you look to recreate this process for a few more opportunities, what should you be keeping in mind as you expand?
Assess how the first team achieved success
Resist the temptation to avoid hard conversations about what made this experiment successful. Pause and evaluate what activities worked for the balanced team, and define the practices that future teams can adopt. That starts with learning what worked well and how we work well.
- What did we learn?
- What challenges did we encounter and how did they come to be?
- How did we navigate it?
- What values does the team hold dear?
- What approaches did individuals take that won't scale and need to be changed?
- How can we share what we learned so we can grow the organization?
The insights from these conversations will uncover core values and practices that you want future teams to abide by. Document these insights, share them with the next team, and maintain the experimental mindset that added to the success of the pilot.
Additionally, it’s necessary to foster a culture that provides a comfortable place for your individuals to learn and want to work by ensuring psychological safety. When teams do not feel psychologically safe, they will not take the risks you need them to take in order to learn, grow, and deliver value. Yet, when vulnerability is encouraged on teams, it increases innovation and boosts employee engagement.
Empower the first team to own and drive the culture
As you scale, intentionally build on the practices and culture you want by letting the first successful pilot team help seed and teach the second team. Not doing this will leave you questioning why the first team worked and the subsequent teams did not. It can be hard for external people to cultivate a culture if they were not part of the first successful team. Without clear leadership driving this new culture and the support of the first team, it will be easy for future teams and the organization itself to revert back to old ways.
Assign leaders at the portfolio level as the aggregation point
As you plan to expand into multiple teams, you will have numerous outcomes to drive toward, resulting in new challenges. For example:
- Teams are working together to deliver value, but they’re not delivering the desired outcomes.
- Great software is being shipped, but your downstream teams are raising red flags about missing data, broken integrations, and other negative results.
- Product teams are being slowed down by the need to manage communication dependencies, orchestrate technology, and handle cross-cutting features.
- Product managers are overworked, and there’s conflict between product teams over priorities and resources.
This is the time to identify new roles to facilitate the work of multiple product teams working together and make certain that teams are aligned on the mission of delivering shared product outcomes. A portfolio leadership group comprises representatives from each discipline who cultivate the strengths of individuals on teams and carry a unified vision to ensure effective practices flourish.
Define the practice through a vision
A defined vision, mission, and set of principles clarifies what you want your organization to accomplish and helps every team member align their daily work with what is important to the whole organization, allowing them to make better decisions. US Digital Services is a good example of describing the future they want to create and the core beliefs that guide their decisions.
Government employees should be involved in creating these artifacts since they are the ones you are enlisting to change their way of working, will be owning the established practices, and will be accountable for carrying them forward (along with leadership). As you solidify these artifacts, solicit feedback in safe spaces and forums and be prepared to address and/or iterate on input that is offered. Socializing the artifacts deepens everyone’s understanding of the core values of the team and maintains alignment on the team’s goals.
Phase 3: Establish culture and processes that become the new normal
At this stage, you’ve likely had several successful products launched that are delivering value to constituents. It’s time to start thinking about what needs to be done to scale and standardize this way of working organizationally. If true culture change requires a behavior change over a period of time, and we’ve identified the behavior change we want to replicate, think of this step as the opportunity to permanently remove existing organizational blockers and turn the trail that was blazed into a paved highway for future teams to travel quickly and easily.
After you establish the organization's vision and mission, these are other successful strategies to scale your organization.
- Create organization-wide goals – At least one goal should focus specifically on the cultural change and process itself, and not just the outcome. While this can feel counterintuitive with how much we focus on outcomes over outputs, this is an area where the process itself benefits from careful nurturing.
- Communicate direction and strategy – To realize the vision and mission of an organization, an object-oriented roadmap can communicate where the organization plans to go, high-level strategic initiatives, and how progress against those initiatives will be measured. It accounts for uncertainty and enables the team to learn and adjust.
- Establish and implement the practice of lean governance – Lean governance practices are especially important in government organizations so that decisions are made as quickly as possible, enabling teams to move fast. We have found that legacy methods for governance limits a product team’s ability to deliver value quickly.
- Help others help you! – Work with executive sponsors, finance teams, HR, and other organizational units that own processes that are important to a team’s success. Work with these departments to adapt to the leaner way of working your organization is driving towards. Funding models may need changing, hiring and onboarding processes may need revision, and consideration for each of the elements on this organizational roadmap is a great way to ensure long-term success.
- Measure progress – To avoid a frozen middle predicament where team and middle management goals do not align (i.e., on time, on budget, on spec, etc.), organizations should develop a set of business and excellence metrics. With the latter being owned by all organizational employees, and not contractors, it can ensure that the organization continues to develop through measured progress as a whole, rather than succumbing to blockers derived from the conflicts of individual contributors’ personal success criteria.
- Iterate – Iterate on organizational attempts at transformation as well as the metrics that are defining success at product and organization levels. We’ve found it to be especially true in the public sector that if a contract’s verbiage front-loads success metrics or product specifications, and is unwilling to iterate on those expectations regardless of what is learned in the discovery phase, it prohibits pivoting towards meaningful work and value delivery.
Learn about Tanzu Labs
At Tanzu Labs, we partner with organizations all over the world to accelerate the delivery of software and modernize legacy applications, while reducing operating costs and risk.
If you're looking for more advice on ways to scale your organization's ability to deliver software in the public sector, we’re here to help. Watch the replay of our webinar "Transforming Service Delivery in the Public Sector," or download our free white paper "Service Delivery Modernization Pilots That Scale."
