Why are so many large organizations failing at agile?
If there is one message on agile development I hear most often, it’s that the benefits of this fast and flexible approach, are very hard to achieve at scale.
Many organizations have learned from successful trials how agile can be the ‘antidote to disruption’, delivering business value earlier, releasing updates more frequently and improving customer satisfaction. But they struggle to turn these small wins into an enterprise-wide and repeatable process that can tackle complex integrated programs.
Why? I believe that confusion about what agile is, and how to achieve it, lies behind the problem. By arming yourself with a better appreciation of what agility really means and how it works in practice, you can hugely boost your chances of scaling successfully and avoid rolling out ever more discrete agile projects.
There are three phases to a full agile transformation and each phase builds on the last. The starting point is the single scrum team; 5 to 10 professionals (developers, product owner, scrum master) who work in a series of two to four week ‘sprints’. The aim is to build something basic but functional - the minimum viable product - and get it in front of end-users as quickly as possible. Involving the customer/end user as much as possible is key to ensure the best answer to the client’s need.
The second step in scaling agile is the program layer; a move to multiple scrum teams, still working independently but towards a common, more complex product goal. And beyond that lies the ultimate prize of the truly agile organization, a business-wide transformation encompassing strategy, governance, decision-making, budgets, and incentives, all re-configured to match the pace and fluidity of agile development.
Many organizations I speak to are confident that they have nailed phase one. But they struggle to scale, because they try to get from simple single-scrum-team projects to the highly complex organizational transformation level in a single giant leap. There is a vital but often overlooked intermediate step - the program layer - that must be addressed first.
Agile can help you discover new customer insights and quickly act on them. It helps you prioritize based on what’s commercially important to develop. It enables you to pull the plug on features or products that customers don't want, before you have invested heavily in them. But expecting to convert success of a few discrete agile projects straight into a full-on agile business transformation without tackling the program layer first, is like trying to ski a black run when you have only just mastered the nursery slopes.
Agile does require different processes, but it also requires different ways of teaming, a different kind of leadership and a new agile mindset. Although it often originates within IT, agile is not just an IT approach, it’s a new way of working, with its own distinct culture.
People who are used to working sequentially in their own silos, must learn to work collaboratively across business boundaries, towards new customer-focused outcomes. Product owners in an agile environment are part of the development team - scope is fluid and red or green light decisions must be made on a daily or hourly basis. The old ways where management reviews progress against a fixed scope every couple of months doesn’t work.
In short, scaling agile requires a complex combination of new approaches, new organizational structures and a new mindset. If the processes are hard to get right, the cultural change is even harder. Quick successes with phase one, scrum-level agile can make the jumps to phases two and three seem more straightforward than they actually are.
So, think carefully about why you want to be agile, but also about how, and when. What do you want to achieve from implementing agile at scale? Which parts of your business are most agile-ready, which are least - and how can they learn most effectively from each other?
Those of you interested in more detail should take a look at the latest report from the Capgemini Research Institute, Agile@Scale, for an in-depth analysis of the challenges and rewards involved in tackling the three phases of scaling agile, and for some inspiring examples of businesses that are at the cutting edge.
Scaling agile to the program and ultimately enterprise level is a journey, not a destination - and as with all journeys, a clear-eyed understanding of the terrain ahead of you is the key to the smoothest possible ride.
Managing Director - Banking & Financial Services & Global Head of Bid Management at Nityo Infotech Services
4yAgile is not a new concept, it's been around for a long time. Organisations struggle in my opinion because of their mindset(s) and declaring everything as Agile, when clearly it is not. Still many people around that do not grasp the basics and this is a challenge.
IMMEDIATE AVAILABILITY (part time) - 20+ Years Exp. (16+ with SFDC) Independent SFDC Consultant at Chicago Cloud Consultants LLC. Gen available from 105 - 120+ / 1099 . No employee roles. Contract Only. New Dev Only.
5yCompanies love to spew it as a buzz word these days which is typical of social media to sound "cool" but don't want to invest in something that will reap benifits 6 months from now but will not increase the current quarters sales. Theory vs reality
ex Capgemini Snr Project Manager Not currently working and enjoying it and a grandad. and not currently looking for work
5yAt small scale it works for priduxr development assuming a reasonably sound environment base and data base and getting the organisation from top down to buy in including all the nuances of contract negotiation if third parties involved however once you scale up and you apply agile to areas that are not necessarily fitting for agile such as the base technology environment or data migration etc then you get a conflict on the development side where the business work to see this and that and development can work out their stages to deliver but what happens is the Migration plans together and not least understanding impact of dependencies. And of course managing the resulting blame culture
Born in 317 ppm. Training program director at Capgemini Invent, délégué syndical Cfdt, fresqueur de la fresque du climat et du numérique
5yOne of the big risk I see - when I meet project managers on my trainings - is the availability of the product owners. Organisations don't always allow this person the right amount of free time to participate and react at the right speed. You end up with twisted sprints to comply with the time constraints of the product owner and miss the goal.
Product Manager | Driving Innovation in B2B & Healthcare Sectors | Agile & SAFe Certified
5yFor me Agile is “Fail Fast model”