The keys to successfully navigating agile transformations

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.

If you found this video helpful, that’s great! Check out my books, Think Lead Disrupt and Leading with Value. They just came out early in 2021 and both are available on www.datsciencecio.com.

Hi, I’m Peter Nichol, Data Science CIO. Have a great day!

Previous articleThe secret sauce when staffing successful business relationship managers
Next articleHow to develop team capabilities by tapping into strengths
Peter is a technology executive with 19 years of experience, dedicated to driving innovation, digital transformation, leadership, and data in business. He helps organizations connect strategy to execution to maximize company performance. He has been recognized for Digital Innovation by CIO 100, MIT Sloan, Computerworld, and the Project Management Institute. As Managing Director at OROCA Innovations, Peter leads the CXO advisory services practice, driving digital strategies. Peter was honored as an MIT Sloan CIO Leadership Award Finalist in 2015 and is a regular contributor to CIO.com on innovation. Peter has led businesses through complex changes, including the adoption of data-first approaches for portfolio management, lean six sigma for operational excellence, departmental transformations, process improvements, maximizing team performance, designing new IT operating models, digitizing platforms, leading large-scale mission-critical technology deployments, product management, agile methodologies, and building high-performance teams. As Chief Information Officer, Peter was responsible for Connecticut’s Health Insurance Exchange’s (HIX) industry-leading digital platform transforming consumerism and retail oriented services for the health insurance industry. Peter championed the Connecticut marketplace digital implementation with a transformational cloud-based SaaS platform and mobile application recognized as a 2014 PMI Project of the Year Award finalist, CIO 100, and awards for best digital services, API, and platform. He also received a lifetime achievement award for leadership and digital transformation, honored as a 2016 Computerworld Premier 100 IT Leader. Peter is the author of Learning Intelligence: Expand Thinking. Absorb Alternative. Unlock Possibilities (2017), which Marshall Goldsmith, author of the New York Times No. 1 bestseller Triggers, calls "a must-read for any leader wanting to compete in the innovation-powered landscape of today." Peter also authored The Power of Blockchain for Healthcare: How Blockchain Will Ignite The Future of Healthcare (2017), the first book to explore the vast opportunities for blockchain to transform the patient experience. Peter has a B.S. in C.I.S from Bentley University and an MBA from Quinnipiac University, where he graduated Summa Cum Laude. He earned his PMP® in 2001 and is a certified Six Sigma Master Black Belt, Masters in Business Relationship Management (MBRM) and Certified Scrum Master. As a Commercial Rated Aviation Pilot and Master Scuba Diver, Peter understands first hand, how to anticipate change and lead boldly.