Agile long ago escaped the software sphere and set out to conquer the business world. Today there is a widespread belief that Agile can successfully transform global organizations across hundreds or thousands of teams and even the Harvard Business Review has blessed the idea by featuring “Agile at Scale” as the cover story for its May–June 2018 issue.
Capgemini has been helping our partners go Agile for many years. We’ve seen what it takes to make the shift, and we have had a lot of experience with the pitfalls and barriers that can slow it down. From the point of view of practitioners on the ground, is the triumph of Agile as inevitable as the headlines suggest?
Agile is spreading across the legacy landscape
Today, most organizations that use Agile use it for small, purely digital, front-office projects. Those that have seen Agile prove its ability to revolutionize time to market in fast-moving, disruptive environments are keen to see the same approach deliver benefits across the value chain.
This is a trend we have seen accelerating in recent years. Digital transformation is no longer just about building new apps, but about building on the legacy landscape to bring end-to-end services to customers more quickly and efficiently. A large part of our work as Agile practitioners and coaches has been in helping our partners achieve this transition from the first to the second, broader arena.
We’ve worked with a global fashion brand and an oil major, to choose just two examples, on highly successful programs to bring Agile at scale to enterprise software.
Is there an Agile big bang?
A lot has been written about the possibility of daring, thrilling Agile big-bang implementations in the industry press, but we are not seeing them on the ground. We are seeing large organizations, in Europe especially, approach Agile positively but cautiously. In every case, the organizations we partner with are selecting test-case projects and then moving gradually from there.
These test cases tend to be for business-critical applications but are not clustered in any particular domain. Even in cases where a client has expressed interest in big bang Agile at scale, we see months of proposals and workshops followed by cautious test projects. The reality on the ground is that we meet a lot more pragmatic IT managers than big-bang evangelists.
The challenges we typically encounter in Agile projects go some way toward explaining why Agile at scale is not as popular with CXOs as it is with industry commentators. A typical scenario involves a client seeking a solution for a requirements problem. Frequently, the expectation is that engaging a vendor with the expertise to implement an Agile approach is the end of the problem. In fact, for an Agile approach to work, the client must be prepared to make a significant and ongoing contribution. This includes reviewing each sprint and identifying a product owner to be part of daily standup meetings and to maintain an overview of progress toward the desired outcomes.
In client organizations with limited Agile experience, it can take some time for them to understand and accept the implications of this way of working. Without a full understanding of the approach from the outset, they can become frustrated and fall back on the waterfall way of doing things.
This often means we need to provide an Agile coach to help the client understand why product owners are critical, and then to work with those product owners to help them fulfill that role effectively in an Agile context. It’s not unusual to pass through two or three sprints, followed by lessons-learned workshops, before a project graduates to true Agile status and begins delivering true Agile benefits. Accepting and embracing the high level of collaboration and trust required for this to work is often the central learning experience for our clients. In practical terms, this is a big part of the cultural shift that is frequently referred to in discussions of Agile.
In other words, we do not usually see a need for change management as such in the implementation and acceptance of Agile, rather the culture of Agile grows organically in the organizations we work with by going through the process described above.
Of course, Agile often implies changes to other parts of the IT organization. We usually recommend DevOps as a natural extension of Agile, which is can be another layer of learning and change for clients.
Managing contractual expectations
In Agile partnerships, we also frequently encounter the challenge of managing contract expectations. Financial controllers default to fixed-price-for-project contracts for entirely understandable reasons. Unfortunately, fixed contracts are the least supportive of Agile methodology and carry the highest risk of project failure. Time and materials contracts are by far the best fit for Agile, and minimize risk, but they go against generations of expectations.
The answer to this challenge goes hand-in-hand with our broad approach to Agile partnerships – building trust and coaching clients toward an understanding of the commitment necessary on their side for true Agile. As part of this process, we offer a tried and tested path from a short-term T&M contract for a pilot project to fixed-price contracts for similar projects further down the line. This journey involves building up mutually agreed expectations based on the actual velocity of pilot projects, and an intermediary managed capacity stage.
Distributed Agile is the answer to increasing demand for Agile
A large proportion of our clients are globally distributed, and Capgemini is, of course, also global, so we have a lot of experience running distributed Agile engagements. At first glance distributed teams seem contrary to the spirit of Agile, and “Does distributed Agile work?” is often the first question clients ask. The answer is it can work very well, especially for clients that themselves have distributed teams, but the setup and learning curve can be more challenging.
For example, we partnered with a large pharmacy chain in the Nordics. The client had a highly demanding project and wanted to take an Agile approach both because there were a large and diverse set of customers to be served and because they wanted a future-proof product. We set up an onshore team plus an offshore Agile sprint team, but for the first couple of sprints we co-located the entire group with the client. Agile requires frequent and fluid communication, so this was a way of ensuring team members on both sides could immediately build the working intimacy needed for Agile to continue when part of the team was thousands of miles away.
This kind of approach works, but we have found that potential clients will sit through any number of case studies demonstrating its success, nod their heads, and still go away unconvinced. In almost every case, the clincher is taking clients to actual distributed locations and showing them Agile in action. They see the daily standups conducted via video conference and the collaboration tools in use and then they believe. The proof really is in the pudding.
At Capgemini we have what we call the Rightshore® model – we don’t describe solutions as onshore, nearshore, or offshore because we have the distributed strength to put together solutions that combine all three. This is often a decisive factor for clients because we can rapidly set up the kind off onshore/offshore hybrid that we deployed for the Nordics pharmacy project described above. It means we can meaningfully offer to start Agile onshore, then graduate to nearshore and offshore as clients’ confidence in the process grows.
There is no question that Agile is here to stay and set to continue expanding beyond the purely-digital, customer-facing applications where it first achieved success. We are seeing strong and accelerating demand for Agile expertise globally. What we are not seeing are organizations diving headfirst into Agile big bangs. Even when their ambitions are large, our clients want to start small and build from there. Part of this caution comes from a reluctance to accept the T&M contracts that fit much more naturally with Agile. So, from the vendor’s side too, it’s better to start with small T&M contracts, giving the client organization time to build confidence in the Agile process.
The often-discussed cultural adjustment to Agile is always a challenge primarily, we have found, because organizations underestimate the commitment required to achieve true Agile benefits. It is this process of realization that itself constitutes a critical part of the necessary cultural mind shift.
Please click on my LinkedIn profile to connect with me.