Updated: Jun 1
Increasingly, organisations are trying to “go agile” using one of the many scaled agile frameworks on offer. These frameworks often promise that when you follow their recipes, delivery will be a dream and your organisation will explode with innovation.
Unfortunately, talking to the people behind the numerous case studies, we discover that things seldom work out as they had hoped, with many of the promised benefits remaining elusive. What’s missed is an understanding of the problem we’re actually trying to solve and the values, principles and approaches which will help our agility at scale.
What do we mean by 'Scaled Agile'?
The term ‘Scaled Agile’ is contentious at best, but for our purposes, we'll define it as the move from a few independent agile development teams within an organisation to:
Multiple agile teams operating within related domains necessitating coordination between each group.Technical and product work being collaboratively prioritised by teams and senior leadership.Teams spanning beyond technology to include elements of the entire business, creating a value stream capable of incepting, delivering and operationalising products.
What delivery pains are you trying to alleviate?
The fundamental challenge for organisations seeking to implement a scaled framework is that they have opted for a solution, rather than identifying and addressing their core problems. SAFe, LeSS, RUP, Nexus and all the rest are solutions without a problem. This is not to say that they are inherently a bad idea, but blindly applying any framework or method without considering context is begging for disaster. This is compounded by organisations not taking on a continuous improvement mindset, meaning the framework becomes the end state rather than the organisation inspecting and adapting its way to more effective delivery models. This is why it is so important that the problem is well understood before any changes are made.
Start by identifying your highest priority delivery pains and exploring the root cause of these pains.
Pro tip: your highest priority pains are not defined by the highest-paid person in the room.
Look to your teams to understand where the technical and process dependencies exist, and what their key pains are. Also, at a high level, map out the steps involved in getting a product out the door, from idea to production. Your pains in this flow are the steps which take time and don't give you working software. Some of these activities may be necessary, but the value behind them needs to be challenged. The conclusion of these assessments may tell you that scaling is not part of the problem at all.
If we confirm that scaling our agile delivery will help alleviate certain pains, there are certain things we need to be aware of before and during our transition. The following concepts are a mixture of practices, principles and values which I have found personally useful to focus on while scaling agile teams. It’s not intended to be an exhaustive list, nor will everything necessarily apply to your context. You may use this as a starting point on your scaled journey and adjust to suit your needs.
Get the fundamentals right
Software delivery is an inherently complex endeavour. Getting it right at the team level is mind-bending hard. The following are my key points to understanding existing agility at the team level, along with collaboration abilities and readiness to scale.
Agile Manifesto & Principles - As a whole, is senior management and the development teams aligned to the Agile Manifesto and its 12 Principles? If not, the change you’re introducing will likely conflict with their personal values resulting in a multitude of dysfunctions. You want them aligned and leading the journey with you.
Cross-functional Teams - Each product development team must be truly cross-functional, meaning they define, develop, test and deploy the product.
Small teams - Each team follows Amazon’s 2 pizza team size rule. This generally equates to 6-9 people depending on skills and experience.
Change your Rewards & KPIs - You current KPIs, Incentives and Rewards will enforce the status quo and prevent any lasting change from occurring. A great starting point is to look at how you might measure teams and departments based on their impact on improving speed to market, customer interaction response time and customer satisfaction.
Out with the old, in with the new - Don’t shoehorn Agile into existing methodologies and governance frameworks. This sounds like it’s a no brainer, but I’ve seen organisations attempt this time and time again. Take a new lense focusing on value add activities, constantly measuring the effectiveness of governance processes and adapting them, incentifying all staff members for shortening concept to cash (i.e. lead time from idea to getting it in the customer’s hands).
Visualise your Program - Create a wall space where at a glance anybody can appreciate what’s being worked on and take corrective action on dependencies and bottlenecks. Meet at this space regularly with key senior stakeholders.
Focus on your people - Trust your people and empower them to do their life’s best work. Support them in their personal and professional development by giving them ample opportunities to learn on the job and via formal training, as well as regularly coaching them on their career. Furthermore, give them ample authority to implement the changes they see necessary in order to be most effective. This is key to building an autonomous team which can coordinate effectively with other teams when scaling.
Be ready for pain - Agile is a silver mirror which will identify your organisation’s dysfunctions. It can be confronting at the team level, at the scale it will really show the madness. Ensure you regularly engage all members involved in these changes and provide a forum for transparent and regular feedback. If your team are not raising issues, be especially concerned.
Scale your delivery
Given the fundamentals are being addressed, it’s time to bring in broader change to optimise the organisation for delivery. None of these elements will happen overnight, but acknowledging this is the journey we need to take creates a path for change.
Understand why you want to scale - Be clear on the rationale behind scaling, the problem being solved and the objectives to be achieved. Set clear goals using effective metrics which represent real impact.
Communicate the why & get feedback - Once you understand the rationale behind the need for change, create a physical space with regular forums for members of the organisation to understand the problems, provide feedback and influence the changes being embraced. As the changes are introduced, share the results, learnings and metrics (if relevant) of the change in this space.
Keep projects short - Projects need to deliver value to the end customer within 3 months. If it is taking longer than that, you’ve sliced your program the wrong way.
Establish Feature Teams - Create stable teams around customer-centric features. This is where each team has the necessary skills, knowledge and autonomy to deliver a feature without being dependant on other departments or product teams.
Limit your Work In Progress (WIP) - Reduce the number of projects which are in flight to drive focus, increase quality and reduce the lead time (concept to cash).
Change the org structure - It’s likely your organisation will need to mold into a form which focuses on your products and customers, rather than by functional groups. Conway’s Law is a key risk on large cross-department/product projects as teams will optimise their work based on their current (and even old) team structures with little regard for pain they’re causing other teams. Instead, start to rearrange teams and other organisational structures to suit the work.
Stop doing business cases - Assess the current effort involved in creating business cases, the delay they impose on starting work and their accuracy (or lack thereof). Based on your assessment, communicate to management these deficiencies and explore better ways of prioritising projects.
Fund value streams, not projects - Rather than going through the process of funding individual projects every time you want to do something new, simply secure funding to support your product development teams on an ongoing basis. Prioritise work based on market forces, customer feedback and strategic insights.
Stop completing your projects - If you’re 100% complete based on initial scope, you’ve built things which people are not using or don’t want. Teams deliver high value early in projects while they work on the most important features. As they make their way through the backlog, the return diminishes. Once you’re producing little value, move onto the next high-value activity, and trim that backlog!
The role of external coaches and training
How can external coaches (like those from SKILLFIRE!) best help? Consultants can bring broader experience and potentially useful tools to the situation. They help draw an accurate picture of the current state, identify priorities, and help craft strategy. But part of the challenge of Agile is adopting the necessary mindset, and the more that the organisation can do for itself, the better.
The temptation is to buy into a strongly branded scaling methodology that feels safe, but there’s more to gain by committing to a long-term, continuing journey of change and improvement. By all means, make use of consultants and training courses as part of your over-arching strategy, but please consider using them to compliment internal championing and real leadership, not as the main event.
Go for the real deal, not the “just add water” option.
Nothing here is the answer to all of your woes, however focusing on these points will give you a clear rationale for scaling, empower your people to operate effectively and structure your organisation in a way which supports scaled agility. You may be reading this thinking “This is just agile”, and you’re right and that’s the trick! Agile techniques, practices and principles inherently scale, you don’t need a framework to do it.
“The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble.”
- Ralph Waldo Emerson
Each point in this blog is a topic in itself, so I’ll have a follow-up series exploring each further.
Tell me, which one most resonated with you? What have you found important which isn’t included here?
Acknowledgements, inspiration & further reading
A big thanks to Daniel Prager, PhD for his helpful input and insights!
The following articles and blogs collectively inspired this piece and provide some brilliant further reading on this topic:
Shane Hastie, Examining Different Approaches to Scaling Agile
Jim Benson & Tonianne De Maria Barry, Personal Kanban Basics: Why Limit Your WIP Series, Post 1
Neil Killick, The Horror Of The Scaled Agile Framework
Neil Killick, Manage Products, Ditch Projects & Programs, Coach People
Daniel Prager, Learn or Lose: Agile Coaching and Organizational Survival