By: Rick Pollick and Justice Conder
Building a great agile program is hard and an ever-evolving activity. It’s complex and requires system-level thinking with an intuitive understanding of engineering tradeoffs, bottlenecks, and flow dynamics. Much like a racecar driver, one cannot expect a driver to understand and be consciously aware of every detail happening in his car while he is racing down the track.
An interconnected system has to be in place allowing the driver to navigate the car given a few specific levers and controls. Following this analogy of building a race car, these are some of the steps we took to ensure the continued agility of our program following the onset of the COVID-19 pandemic.
Step 1: Define Workshop Location
“Remote-first means working remote is the default. It means making sure your remote employees are as much a part of the team as those in the office.” – Stack Overflow
Technology previously integrated into futuristic-feeling racecars has become commonplace in most modern vehicles. For example Disc brakes, carbon fiber, push-to-start, etc.
In the same way, the technology, processes, and innovation used by truly effective teams will eventually become commonplace. It is important to identify areas of change and best practices so that they can be appropriately adopted.
Many teams, especially those in the technology development fields, previously took advantage of at least some sort of remote work & access capabilities. However, in 2020 (due to a global pandemic), the unexpected happened. Many teams were faced with the task of shifting their mindset from co-located teams to fully remote teams. Inevitable challenges around communication/cohesion, system access, and scaling became the business concerns du jour.
The important thing is to realize that an effective agile team can be built anywhere. Just like a car can have its parts manufactured in different locations across the world, a modern team (or group of teams) can still operate in a distributed/remote manner. While the pandemic has been a truly horrific occurrence, it has also been a catalyst that has created a necessary reaction – forcing many teams to embrace a remote-first mindset. Some interesting takes on this shift have been expressed in the following articles:
- “What the Cloud was to 2008, the Distributed Organization is to 2020.” – TechCrunch
- “Our Economy Was Just Blasted Years Into the Future” – Medium
Now that organizations have had their teams’ “workshop” locations changed, it is important to organize the “workshop” tools in a way that promotes efficiency. These tools will be used to build out a chassis, which will support the entirety of a team and/or program.
A couple of key areas of consideration while shifting to a remote-first mindset:
- Define remote work expectations
- Increase & standardize communication channels
- Continuously review the benefits & pitfalls of current activities
Step 2: Basic Chassis Framework
“A chassis is the load-bearing framework of an artificial object, which structurally supports the object in its construction and function.” – Wikipedia
Building and implementing a team chassis revolves around the standardized use of tools and the implementation of events. Decisions and best practice standards should be set for a team, program, or group – with the expectation that the tools will be used in varying ways for unique teams and situations.
Essentially, the team chassis is the process framework that a team uses to deliver software. Regardless of standards or terminology used (i.e. SAFe, DAD, Scrum, XP), a team should establish explicit norms around their unique way of working.
For illustration: Nearly all cars use the same core elements, such as wheels, engine, braking system; and are also limited to the same laws of physics. Similarly, teams within a program (or even more generally) should operate using similar core elements, including a framework, KPIs, defined roles, etc. However, how these items are configured, used, managed, and reviewed can be unique to a team or program.
A couple of key areas of consideration for building a team chassis are:
- Implementation of standing sessions for routine ceremonies
- Standard recurring program-wide event calendar(s)
- Designated event facilitators
Step 3: Install the Engine
Similarly, to the build of a team “chassis”, there are norms and standardized frameworks which may govern individual teams. However, a team (or group of teams) should be able to define, refine, and use varying components within those constraints.
A real-world example of this variance is the comparison between the hybrid LaFerrari and the fully electric McLaren P1. Both are supercars, both have core elements of a car, both require manual operation, and both go VERY fast. For all intents and purposes, these cars have very similar output specs. However, the differences between car engines are intriguing.
- The LaFerrari uses a 6.3 L F140FE V12 (gas) engine & 1 electric motor and KERS engine (963 PS; 950 hp)
- The McLaren P1 uses a McLaren E-Motor engine (916 PS; 903 hp)
While the larger organization or program standardizes core expectations & preferred framework, teams should address needs through a focus on value. Being value-driven means different things to different teams. However, all teams should work toward producing a useful output or something that delivers value to the overall project/effort (similar to the production of components for a car or an engine).
A couple of key areas of consideration for building a value-driven team:
- Align teams around the end-user with User Stories
- Ensuring sprint/cadence reviews are focused on value to end-users
- Make explicit the role of component teams
Step 4: Bodywork
Focus on bodywork is when a team ensures their work is following an expected or engineered outcome.
For example, a car manufacturer must ensure that the vehicle that they are producing meets the specific standards governing things like the engine and the body shape/size. Similarly, it is important for a team, or group of teams, to understand different areas affecting a given project/effort.
In certain cases, teams may be asked to build (or design) a product that possesses certain qualities or characteristics. In other cases, teams may be asked to build (or design) a product that utilizes external teams’ components. The importance of cross-team collaboration and the configuration of ARTs (Agile Release Trains) becomes increasingly important to be aware of as teams and products mature.
A useful tool to ensure that projects are on-track, and align with the efforts of contributing entities, is a roadmap. Roadmaps can assist in the visualization of progress or events, as well as help teams juxtapose their throughput compared to the proposed timeline.
Step 5: Final Touches
Just like the paint, decals, and tinting added to a finished car, the final touches to put on a highly effective team are also important. Final touches can help define the car or team, call out the brand, and offer a guide to what was done (as well as what could change over time).
In the context of a team, final touches may include things like:
- A program-wide framework handbook covering prescribed norms and expectations
- The introduction of self-service tools eliminating bottlenecks and single points of failure
Conclusion
Building a world-class racecar is difficult and an ever-evolving activity; just like building a great agile program. Software is complicated; how much more the effort to rigorously predict its delivery. The complexities involving defining and standardizing the tools, processes, frameworks, and constraints are vast; it’s even harder as human beings are involved.
The intricacies of working with associated groups, and within the bounds of stakeholder expectations and timelines are tough. However, the ability to adapt and seek value at the team level will both help yield quality products and position the program for success.
This is why the job is never done. The greatest requirement of all, that has been covered, is the need to be flexible and always learning, changing, and evolving with the needs of the program and the marketplace.
If you’re interested in building a racecar agile program and would like to help us grow on this journey to mastering large scale software delivery, we would love to hear from you.
Contact us at agile@upmc.edu
