Do Not Overlook These Critical Signs When Scaling Your Agile Teams

As organisations and tech start-ups grow, adding staff is par for the course. But bringing in new people, and new skills, isn’t simple. Businesses can struggle to develop cohesively and efficiently as they scale their teams.

Agile principles introduced the concept of cross-functional teams, rather than focusing on role type. While smaller organisations, 5-20 staff, may scale easily, hitting 100, or 1000 staff, over multiple locations/timezones is where effective scaling decisions become crucial.

I’ve observed various ways that organisations structure their teams to avoid issues. Whether it’s by role, work type, feature/functional area, architectural layers or tech skills (referred to as Centres of Excellence), there will always be decisions and challenges you face.

The diagram below is an example of the various ways I’ve seen organisation attempt to tackle the problem.

In each variation problems have occurred. This is to be expected. But what are the signs they are occurring? And how do Kanban techniques/metrics allow us to identify and minimise them before they cause significant disruption?

Conway’s Law

Before I discuss the three critical indicators it’s important to start at the beginning. Anyone akin to delivering software at scale know that Conway’s Law is a regular feature. Problems and challenges in project progression can often be traced back to one underlying issue:

“How organising principles, across skills and functions of the development team, mirror faults and efficiencies in software development.”

This issue often links to common signs that indicate the potential cause of a critical project failure. By knowing this, and how it manifests into issues when scaling, you can adopt measures that overcome these problems. Here are things to look for when scaling-up:

(1) Demand Splitting

Breaking requirements into the lowest common denominator and spreading these across multiple teams is a strong indicator that Conway’s Law is affecting progress. Split-team delivery of a component should be the exception, not a standard operating process.

If this keeps happening it’s time to review team structures. You should approach this by building a system where a single group can deliver value without the compromise of splitting the requirement and handing off. This includes restructuring half-way through a project if necessary.

In one of my recent blogs I discussed how restructuring had previously been seen as failure of the the agile principles. Instead it should be considered an adaptive tool to complement the evolutionary nature of the development process.

(2) Hand-Offs

The visual tools offered by Kanban tell a visual story of your software development process. It offers crucial insight into the visibility and regularity of blockers preventing teams from making progress in their respective areas.

A common blocker is hand-offs between teams aligned by architectural layers. Just like Demand Splitting, occasional blockers are to be expected. If you’re seeing the same team holding your project up time and again, you have an embedded problem.

I worry about how much time I see project managers spend on dependency management and overcoming/working around the effect of Conway’s Law. If progress is reliant on dependency, re-architecting teams to remove this element is the safest path to success.

(3) Cycle-Time Data Patterns

Reducing cycle-time can be achieved by limiting work in progress, focusing on end-to-end flow, and removing blockers during the course of development. There is lots of data out there, and that I have myself, which shows this.

In the chart below you can see the measure of cycle-time variation fanning outwards and upwards. If you are seeing similar patterns across multiple teams it is another indicator that it might be time to review your team’s organisation.

By recording key data throughout the project, graphs like the one above can help you identify where problems occurring. Without the use of quantitative evidence, if can be difficult to find the precise area that projects are failing.

Conclusion

Tools within agile frameworks are iterative. They will not stop problems occurring, they will only minimise the number of issues you are likely to discover. Adapting and evolving the principles to your particular project will dictate the outcome.

Organising teams in a productive and structured way is crucial to project success. When things don’t go as planned, taking a step back, reviewing your cross-functional organisation, and changing things up, can give the headspace you need to achieve progress.

Don’t be afraid to make changes if you’re worried about the success of the project. Ignoring it is too risky. By being aware of the factors above, and planning redundancy measures should they happen, you can prepare to resolve them promptly, and efficiently, should they occur.

I’m passionate about innovating the software development process and supporting fellow agile practitioners. If there’s a subject you’d like me to write a blog about, let me know. If you like what you read, why not:

1. Give it a thumbs up and leave me a comment,

2. Tag one person you think would find it useful/interesting,

3. Make me smile, give it a share.

Cheers,

Ian

**This article was originally posted on my personal blog.**

About Us

Ian is the Owner of Solutioneers, an industry-leading agile methodology delivery partner. With 25 years’ experience, Ian has worked with national and international brands, including SKY, the NHS, JCB, MoneySupermarket.com, the Co-Op, and more, delivering software and technology solutions that increase efficiency, bottom-line profit margins, and work processes.

To understand how effective facilitation of software project management can help grow your business, and how we’ve brought our years of industry knowledge and experience to companies of all sizes, get in touch today. Call 01925 877980 or email [email protected] for more information.