Transforming to Agile: Turning Theory into Practice

At HP, our Configure-Price-Quote transformation is one of our biggest agile accomplishments to date. But I’d say that transforming to Agile itself, putting it into practice, and learning how to do things in a completely different way, was just as much of an accomplishment for us all. ?

The start of the journey

Our agile journey started in April 2020. We’ve just passed the one-year mark, where we went from the initial stages of mobilizing to the first set of agile-driven releases of our transformation program. As many may know, the start of something like this is about putting together all the pieces of the puzzle. In the beginning, none of us had worked in an agile way. So, we had to literally start from scratch because there was no internal point of reference.

The Power of Small

One of our guiding principles was the Power of Small. We started by putting together our team of key members who represented the Solution Management Team to provide the Product Vision (rep. Global Solution Owner), Governance & Control (rep. Agile Program Mgt. Office Lead), Product Engineering (rep. Global Solution IT Architecture Lead) and Management of Scrums (rep. Solution Scrum Master) for the program. As the Solution Management Team, we had to make sure that we were not only responsible for the overall engineering, program deployment and its day-to-day tracking, but also for helping a cross functional team transition in moving to Agile.

Life before Agile

In the past, our teams would create a business and technical requirement documents, which would typically have been put together by second guessing requirements from business conversations. This was then shared with IT who would do their sizing based on their best interpretation and translation of functional requirements to technical requirements. This could take a month or two. We’d then try to match that against our available budget and mobilize the required resources on the project side and the IT side to deliver it. Via a typical waterfall approach, the full capability would then be delivered only to discover that the outcome was not only misaligned to the original business needs, but that these needs had already changed in today’s fast paced world...too little, too late.

Life after Agile

During our Agile transformation, we learnt first of all that we can do without these silos, by ensuring that we were all part of one team empowered by cross functional leaders with a common objective. This was the Power of Small.

In today’s Agile approach, Configure-Price-Quote each is now considered a product in itself. In the past, we had considered them as one project. This made it far less granular and a lot more unwieldy. As part of our team alignment, each product is today assigned an individual solution owner, supported product managers and product owners. They ensure that user stories are well defined and prioritized in the team backlog. This helps streamline the execution of program priorities while maintaining the conceptual and technical integrity of the features. So, we can remain aligned to the product vision and continue to meet user needs. Each product follows a different release timeline for meeting its own product vision within the broader CPQ vision.

We also learnt that the success of going Agile can be accelerated by getting an objective coach who is not necessarily involved in the business. The Agile coach guided us especially in the beginning about what was agile, suggestions on how we could structure SAFe agile step-by-step through an agreed process and start on the journey to transforming to Agile.

Transforming to agile

We discovered that our project managers were being less effective because they were doing a regionalized project deployment. Instead, what we actually needed were product deployment leads, focused on successful deployment of global product releases to the markets. They could technically deploy a product in Europe even though they were based in Asia. This broadened their scope and understanding of the overall solution and product vision, making them more globally enabled.

This change proved a catalyst, transforming the entire team. With this, we started to formalize an agile framework. A balanced organization with product definition & planning on the left with solution owners, product managers and product owners; product engineering in the center with our scrum teams; and deployment and change management on the right with our product deployment leads and change agents.

This gave us a transparent view of everything coming in, providing an input into planning and engineering. This was then turned into new capabilities via product features to be deployed by our product deployment leads and change management team on the other side.

Such a streamlined way of working eliminated a lot of administration and hierarchy that traditional teams normally go through, with multiple levels of approval.

An agile education

With the introduction of these new roles and responsibilities, we began to train our team using everything that we had learnt ourselves and with the help of the agile coach. We also started to work together with our strategy and planning department and began developing training curriculums around agile.

We undertook a targeted training program over six to nine months, training over 50 team members throughout the journey and bringing them up-to-speed on the agile transformation. Once that was underway, the rest of the teams started seeing the astonishing benefits of agile and began their own specialized agile training.

Making steady progress

Of course, the Agile transformation did not get from zero to 100% in one go. When we began moving to agile, there were still some legacy waterfall requirements that were already in build-stage. So, what we did was to retain some of those legacy components, allowing the people working on them to keep delivering. But as capacity freed up, we began changing that to the new agile way of working. At the same time, our engineering Scrum teams started delivering new features via the agile approach and leveraging our DevOps platform for full transparency of user story progress.

As the transformation took place, we kept a gauge to determine what percentage of our delivery every quarter was done in the old way vs. the new agile way. The first quarter release was something like 90% to 10%, with 90% being the legacy component. By the next quarter, we were getting closer to a 40% - 60% mix. And by the third quarter, the legacy processes were down to 20%. And this quarter, I’m happy to report that we’ve had our first release that was 100% agile!

Less hierarchy, more transparency

As we moved to a more agile way of working, the traditional organizational lines faded and were replaced by agile reporting lines. As we became much more interconnected, hierarchy didn’t matter anymore. Now we were working as one team to deploy the program and develop new capabilities.

Among the other discoveries that we made along the way, we learnt ways to get better quality inputs. Rather than have our sales ops team second guess the end user, we now went directly to the end user. Bringing in design thinking in the vision stage helped us completely transform our product definition and planning. We learnt that if we applied design thinking in a phased approach, we could get a lot of information right from the start. This could validate our own thinking around our products and solutions and shape them before our IT scrum teams even started building on it.

Using virtual collaboration software like Miro, we started to explore ways of engaging with larger teams. Today, thanks to agile, we can basically showcase what the future looks like even before we start building it. We are also at least 95% closer to delivering exactly what the business needs in each release. Bringing in our additional UI/UX creatives around design thinking further helped enable our agile transformation through visualization with early prototyping.

Release Management via Agile DevOps Capabilities

Instead of relying on user stories that did not offer any transparency on the actual update or collaboration, we have now migrated our release management entirely to our Agile DevOps environment. This environment is completely transparent to solution owners, product managers and product owners. Everyone in the team can now see the progress at any point in the day. We can also see exactly how our requirements are tracking in terms of development. This is very important because when we work as one team, we can find out from each other exactly how we are progressing.

As we are developing these products and making the user base happy, we are also seeing more user adoption. We can now see the volume of the deals that are successfully converted to wins, and assess whether those deals have the same margin, or one that’s better or worse.

We can find out if they are using what we call instant price. Pricing, as you know, is one of the key products of CPQ. Instant price is a self-serve capability within the CPQ environment that doesn’t need extensive support from sales reps. This helps in providing better pricing visibility for the users, especially on the channel side. This in turn, increases speed to market and improves the overall CPQ user experience, allowing internal and external teams to spend more time selling.

Moving towards a new future

Today, we are still at the speed of delivering every three months. But as the agile transformation gradually permeates into every part of our business, I can predict that in probably half a year to a year from now, we should be able to do weekly or monthly release cycles. This means our whole agile transformation will accelerate further, enabling us to release capabilities much faster.

Here’s to a future that is 100% agile.

Walter