Don’t let agile create silos

Agile working brings many advantages in focused and rapid delivery, learning and iteration. However, we need to make sure that this focus doesn’t lead us into creating new “agile silos”.

Some examples from our recent client work

• An agile team in software development protecting its autonomy and the purity of process by being unwilling to commit to deadlines “it will take until we define it as done”. Whilst this may make sense viewed in isolation, this is not a message you can really communicate to an external customer looking for a fixed to their problem
• A HR member of a local agile team refusing to support a global functional initiative because the tasks were not on his agile team’s burn down list
• Managers being reluctant to change the priorities of Agile teams in their areas when the business priorities have changed significantly
• An organization insisting that all agile teams need to be collocated – leading to a lack of representation of different local cultures, talent and experience in their new centralized product development

The most sophisticated users of agile methodology such as Spotify understand that agile teams operate within a dynamic matrix. They use other structures, whether you call them business units and functions or tribes, guilds and chapters, to keep their agile teams embedded within the wider organization and manage the competing needs to (for example) simultaneously deliver the strategy, maintain governance, do the work and build longer term capability.

Agile team autonomy does not mean the freedom to ignore the world around the team. An organization is more than the sum of its teams and not all collaboration fits within a single team or a single location.

Are you seeing agile approaches leading to more silo behaviour in your teams? How are you keeping people connected to the wider organization?

Check out an integrated graphic on our agile & digital leadership learning path and training module contents.