Are you trying to transform from a waterfall methodology to a more agile process in your organization? Is your organization launching agile initiatives throughout the company? They’re both tough challenges. I have some insights for you.
Hi, I’m Peter Nichol, Data Science CIO.
There are some questions you need to ask yourself before starting a new agile initiative. What’s the business driver? What’s the business problem that you’re trying to solve? Start by defining the fundamental business problem. Define the “what” that you’re trying to accomplish. Often, we run too fast and don’t take the time to understand the requirements.
You’ve heard about changing wheels on a moving car and changing wings on a flying plane; well, we can apply these near-impossible feats to agile transformations. When you think about agile, you must identify the opportunity you’re trying to solve before introducing a new methodology to the organization. The art of agile doesn’t solve anything in a silo. It’s the operating model and the interactions that agile enables that allow resources to work more effectively—but only if they have a shared goal.
Changing the wings on a plane in flight creates unnecessary challenges, and so does the introduction of a new agile methodology. Both present similar organizational challenges. Here’s how to stay ahead of the waves.
Understand how “agile at scale” affects workforce management
When we introduce agile, one of the biggest obstacles is culture and organizational change. You might think it’s the tools to run a Kanban or drive an effective Scrum meeting, but that’s not the case. If you want to be a leader in an organization and make an impact, consider the fact that people generally are averse to change. (They more likely hate it, but we’ll use “adverse” to be polite.)
People don’t like to change. I recently spoke with a CIO of a large health plan in the United States that has lofty goals. The company just received board approval for a multi-year, $500-million agile transformation initiative. This initiative will ripple throughout the organization and is anticipated to be so disruptive in securing enterprise-wide adoption that it’s assumed 20% of the staff will be turned over during the three-year transformation.
This information almost blew my mind. However, I then started to realize, you know what, this estimation probably isn’t unreasonable given the high degree of organizational change being introduced into the environment.
Define and monitor sprint velocity
Managing sprint velocity with a single team is a skill taught in just about every agile course. Here we’re talking about monitoring the sprint velocity of multi-teams that are multi-cultural, multi-functional, multi-role, and multi-location.
Most environments embrace the concept of hybrid teams. These teams consist of internal employees, contracted individuals, and various vendor partners offering resources as they can. Resources tend to ebb and flow in the team. For example, consultant A performed Sprints 1, 2, and 3 but then became sick or had personal issues. This resource was quickly replaced with consultant B, who’s been engaged on zero sprints within that department or even the organization. This happens across a team of 150 resources and with dozens of vendor partners. In parallel, we discover that, shockingly, our sprint velocity—the pace of throughput or output—starts to vary and generates unpredictable results. This is a genuine challenge and occurs in virtually all environments due to the human factor of work.
Align the funding to work performed
Another obstacle that comes to mind is funding that disrupts agile flow; it’s not all engineering-side challenges. The orchestration of work is at the heart of how agile operates. The wrong funding model can make agile extremely difficult to implement successfully.
One of the biggest challenges when launching agile initiatives—especially large-scale transformations—is funding. It’s a fundamental part of agile. Usually, organizations perform top-down funding. Funding is established by a leadership team that defines a budget for projects that cover the scope and cost of the initiative to be executed in theory. That model has its challenges, but, generally, it works. It doesn’t, however, work with agile.
Agile focuses on achieving results that the business owner immediately defines. What’s different here is that agile considers that those needs, wants, desires, and, ultimately, the requirements may have changed since that funding was secured three or nine months previous.
Agile needs to be supported with a funding model that supports iterative, short bursts of work. What will be completed is always defined in the sprint. However, all that work scoped in sprints, EPICs, or release trains is less defined. This model directly conflicts with the idea of a tight budget. I’ll submit that these agile components can be added up to show how the budget will be spent. But the reality is that the velocity is forecasted in, say, Sprint 12. The velocity isn’t a known fact today. We’ll estimate it, but we don’t know. This could either pull in our timeline or extend it. This is where contract management for agile is critical. I’ll be covering that in a future #CIOmindset discussion.
Allow the work to evolve from business partners
Lastly, waterfall and agile have established a separation in how work is sequenced. In waterfall, we have this mental process break where everything has to be in order, and everything has to be sequenced. In our new transformation initiative, we’re now agile. We want to be hip. We want to leverage the latest technologies and methodologies to deliver value. Yet, when we queue the work, what do we end up with? We end up with a linear Gantt type of roadmap that doesn’t allow for edits, iterative designs, or unscripted or unplanned activities. Ironically, that’s precisely where agile provides value. Value is harnessed in the methodology’s ability to flex, adapt, and evolve based on new or changing business needs. Agile teams change near-immediately; i.e., within a week or two, not in months “once this phase is completed.”
Agile doesn’t always equate to high performance
Suppose you envision a traditional project delivery. You might think of multiple gating processes, continual delays based on who’s involved, or even producing outcomes no one cares about; e.g., a system goes live with no users.
Without question, the single biggest obstacle for agile transformations is piss-poor performance. There, I said it. Everything that agile touches don’t immediately turn to gold. It requires leadership with previous experience shepherding companies through these types of transformations.
Leaders are often excited about the potential of agile and spin up agile Scrum teams or SAFe teams without a SAFe Program Consultant (SPC) or similar role. As outlined by SAFe, the SPCs are change agents who combine their technical knowledge of SAFe with an intrinsic motivation to improve the company’s software and systems development processes. They play a critical role in successfully implementing SAFe. How will we ensure a smooth transformation if no one is certified who can teach what the heck is going on with agile or if resources charged with the transformation aren’t adequately trained? The bottom line is this is just another factor that introduces unnecessary risk into our transformation initiatives.
We, as leaders, have a duty to ensure that resources understand agile principles and the tools and techniques to make them operate efficiently independently.
Launching agile successfully requires focusing on efficiency
What does it take to be efficient? There are three major things.
First, you need executive support. Without it, you’re not going very far. I’m not talking about a manager-champion who went through a bunch of different agile classes. I’m talking about a leader at an executive level who buys into the concept of agile and the powerful benefits it can bring to an organization when implemented effectively.
Second, take the time to clarify what “done” means. Define “done.” Don’t focus on when you think this project or the whole initiative will finish. Focus on the interim steps:
- When are features due to be released?
- When will EPICs be signed off?
- When are the value streams planned to be completed and validated?
- How does your organization define done?
Agile has an interpretation of done. Often, this is from an agile or purist viewpoint. Alternatively, we have the company’s version of done. Rarely do the two match up. Take a minute to understand what’s envisioned as an end state.
Third, don’t scale while moving. If you have five people, great. Build an agile methodology around those five or 10 resources. If you have a team of 100 or plan to grow the team from 10 to 100, 200, or 500, think about scale today. Define a roadmap of what scale looks like for your organization, and build that vision before you start to develop and bring teams on board.
The goal of agile methodologies is to produce consistent results, whether we’re talking about Scrum or SAFe.
As you think about introducing a new team, a new agile approach, or have been challenged with transforming from waterfall to agile, start defining what it takes to produce consistent results.
If you found this article helpful, that’s great! Check out my books, Think Lead Disrupt and Leading with Value. They were published in early in 2021, and both are available on www.datsciencecio.com.
Hi, I’m Peter Nichol, Data Science CIO. Have a great day!