How to achieve benefits from agile transformation

Recently, I got the opportunity to participate in our Czech PMI Chapter event and answer questions from the audience on how to approach agile transformation, what the expected benefits are and how to achieve them. I would like to follow up on and dig a bit deeper on some of the topics that were opened at the event.

The general expectation from conducting an agile transformation is strengthening your ability to quickly adapt and respond on an enterprise-wide level. If a company wants to get more efficient, there are several related topics that need to be addressed simultaneously—and they go far beyond the way of work of individual agile teams (company culture, strategic skill set development, performance management systems, efficient alignment of multiple teams accessing the same technological platforms and many more).

And for any initiative that is aimed at bringing improvement, transformation success is determined by knowing why and where we want to get better. We need to be clear on what benefits we would like to achieve and then set the main focus of the transformational efforts to start the journey.

In this article, I would like to share my practical experience with three areas that are listed by the 13th Annual State of Agile Report as the most frequently achieved benefits. These are:

1. Ability to manage changing priorities (reported by 69% of research participants)
2. Project visibility (65%)
3. Business/IT alignment (64%)

1. Ability to manage changing priorities

Let’s first take a look at why we would want to improve in managing the changing priorities. What is the impact if we don’t react and adapt the resource allocation?

To put it simply, without the ability to manage changing priorities, we continue what we were doing regardless of the circumstances that tell us to abandon our current initiatives and start doing something else.

To change this, we need to overcome the following three aspects on a company-wide level (needless to say, each of them is hard enough on its own):

• Reaching cross-department agreement on what is the most important thing to do at the moment
• Resource re-location in case we need to focus on an under-resourced area with the priority, which may mean temporarily re-directing resources from some other teams
• Changing the mindset of people responsible for defining and delivering initiatives from “only full scope makes sense” to a value-based roadmap with initiatives bringing value on their own

To tackle the first two points, instilling a “one team” attitude with your senior management team is a must. They are supposed to be a team, too.

I often see an investment of energy and resources into team-building on the level of agile cross-functional teams, but the area of management team-building does not have the required attention (or we simply expect that these senior people will catch up by themselves).

Yet any continuous disagreement or defensive attitude on the senior management level may take a direct toll on cooperation with cross-team levels—and hinder any willingness to think outside the box when resources need to be redirected. Priority alignment and resource allocation are often facilitated by a quarterly business review (QBR) process closely linked to the objectives and key results (OKR) of company departments.

To be successful in the third area listed above, it’s necessary to fully embrace the iterative way of delivery with a primary focus on customer value. I always find it helpful to demonstrate with examples of how value is built build up by incremental steps where technology is the enabler, not the goal.

In order to achieve the mindset change, allow enough discussions until the matter is clarified—and support your teams by coaching.

2. Project visibility

Project visibility means transparency with what we are doing, where we invest our resources and why the particular initiative was launched. Such visibility should also include open feedback on success of delivery—leading to improvement of quality of our estimations, the ability to maintain work-in-progress limits, and staying focused on delivering customer value.

Achieving such transparency is typically a matter of choosing the right communication tool and having a team that helps collect and communicate this information across teams. But the more important question is: How is project visibility helping with enterprise-wide agility?

As one of my colleagues recently stated, project visibility brings a lot of understanding of what is being done—but it can also show weak spots. Personally, I could not be happier to hear that comment out loud. Awareness of the weak spots and their acceptance is the first step to improvement.

To fully embrace project visibility, we need to provide our teams with a safe environment that supports fast learning and a fail-fast attitude. In other words, we need to grow trust in sharing opinions, establish trust between the teams themselves, and coach senior company management toward adopting a servant leadership approach.

3. Business/IT alignment

Reaching business and IT alignment is at the heart of establishing cross-functional teams with business and IT experts (ideally collocated together); this alignment should be organized around products and customer journeys rather than around IT systems or infrastructural components.

But there is a common pitfall: Organizational change alone is not enough to achieve alignment. Starting a transformation with a large re-organizing and insourcing newly defined roles may create frustration with people. They may not see themselves as being ready to take on their new, transformed jobs and join new teams with an agile way of working.

But for now, I would rather focus on something that may bring significant benefits even if your teams stay separated into business and IT: To break down the path to alignment between business and IT experts, let’s first focus on the language they speak together.

The language in which the business expectations are formulated is the first indicator of whether a common objective is there or not. How many times have we heard: “Users can’t express them clearly and constantly change their requirements” or “Once again, new IT functionality did not give me what I required.”

In such situations, user stories are a great help. A user story shares who, what and why is needed. User stories do not contain a description of the solution, but rather clarify the expected customer value that we want to achieve by delivering the story.

Thinking and talking this way rather than expecting functional specifications from the business user makes a big difference. By mastering communication in user stories, the teams manage to establish a common objective—creation of business value. The IT team’s expertise remains in designing the solution, while the business team’s responsibility is to figure out what brings value to customers. User stories act as the connecting element that makes equal sense to both teams involved—and yet lets them flourish in what they do best.

To summarize, based on my experience with different approaches to bring business and IT units closer together, I prefer to design an alignment culture by establishing a common language and helping people prepare for the change as the first step. Organizational redesign should then be used to support the culture and make the cooperation even easier, but I see that as an enabler rather than the transformation objective itself.

This article was published by me on www.projectmanagement.com in December 2019.