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 is the business driver? What is the business problem that you’re trying to solve? Start by defining the fundamental business problem. Define the “what” it is you’re trying to accomplish. Often, we run too fast and don’t take the required time to understand the requirements.
You’ve heard changing wheels on a moving car and changing wings on a flying plane; well, we can apply this near-impossible feat to agile transformations. When you’re thinking 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. That is only if they have a shared goal.
Changing the wings on a plane creates unnecessary challenges, so does the introduction of a new agile methodology. Both present similar organizational challenges. Here how to stay ahead of the waves.
Understand “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 changing. I recently spoke with a CIO of a large health plan in the United States. They have lofty goals ahead of them. Their company just received board approval for a multi-year $500 million agile transformation initiative. This initiative will ripple throughout the organization. This transformation initiative is anticipated to be so disruptive to secure enterprise-wide adoption that it’s assumed that 20% of the staff will be turned over during the three-year transformation.
This new information almost blew my mind. However, then I started to realize, you know what, this estimation is probably not 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 or multi-teams that are multi-cultural, multi-functional, and 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 out of the team. For example, consultant A performed Sprint 1, 2, and 3 but then became sick or has personal issues. This resource is quickly replaced with consultant B, who has 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, that pace of throughput or output starts to vary, and results generate 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 just 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 primarily 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 ago.
Agile needs to be supported with a funding model that supports iterative types of short types of bursts of work. What’s going to be completed is always defined in the Sprint. However, when 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 add 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 Sprint, say 12. It’s not a known fact today. We will 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 up 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. In irony, that is precisely where agile provide value. Value is harnessed in the methodology’s ability to flex, adapt, and evolved based on new or changing business needs. Agile teams change near-immediately, e.g., 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 experience shepherding companies through these types of transformations previously.
Leaders are often excited about the potential of agile and spin up agile scrum teams or SAFe teams without a SAFe Program Consultant 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 are not adequately trained? The bottom line this is just another factor the 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 which you’re not going very far. I’m not talking about a manager champion who, we all can think 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 its interpretation of done. Often this is from an agile or purist viewpoint. Alternatively, we the company’s version of doing. Rarely do the two match up. Take a minute to understand what is envisioned for an end state.
Third, don’t scale while moving. If you have five people great, build an agile methodology around those 5 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 onboard.
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.
Hi, I’m Peter Nichol, Data Science CIO. Have a great day!