We’ve spent a lot of time with various organisations and executives alike. Throughout conversations, we’ve noticed something that resonates with many of them; a desire to move to more Agile Ways of Working, an interest in evolving delivery functions and, for the most part, having executive support to head down that path. The problem is that many of these executives are heading down this path alone.

It seems such moves towards Agile are typically defined and led by the IT departments. This makes sense, given many principles in Agile delivery originated from software development. However, Agile is much bigger than the delivery it underpins.

Organisations are integrated in various ways. The bigger the organisation; the more complex these integrations appear. Projects will often touch every part of the organisation at some point or another, regardless of where they start. So, when a conscious decision is made to become Agile, we need to think of this as an Organisational Change Program in itself.

Rather than trying to ‘get around’ the intrinsic structures that make up a silo driven organisation, we must work through them, together, taking a collaborative and open-minded approach. We otherwise begin creating change that only widens the gap between organisational departmental silos.

Truth be told, problems will exist regardless of the approach taken to delivery. That is why we employ risk management strategies and drive decision making through steering committees; no project or organisation is immune to challenges. Interestingly, when we think about problems that occur with both Agile and non-Agile delivery environments, many of the key problems we find are quite similar in nature. For example:

  1. Teams and departments outside delivery are often out of touch with the delivery methods, frameworks and processes.
  2. Delivery teams forget that departments outside of their own won’t “just get it” and, as such, the gap between delivery and non-delivery teams widens.
  3. Changing delivery approaches involves a holistic view, a clear path to move forward and incremental steps to enable the change to be accepted and understood. Otherwise, you’re left with a lot of confused people, who pretend to know what they are supposed to do to avoid looking ignorant.
  4. Many methodologies like Agile are not about one individual, but rather teams. So, why then do we assume that one person can be responsible for driving enterprise-wide agility in organisations?
  5. We must remember that peripheral departments, functions and teams still have jobs to do. These teams will often rely heavily on the information, outputs and innovation from delivery teams to grow and run the business. Likewise, they will often be relied upon for inputs.

People are typically all working to the same organisational objectives. However, the internal divisions are also trying to meet their own organisational objectives. We need to come together, to ensure that when there is an organisational change such as implementation of Agile, that it suits your business and is not a prescriptive approach as one size does not fit all. Most interestingly, many organisations are the same in the mistakes they make; especially with something like a transition to Agile.

Our previous articles cover, lightly, some of these mistakes and how you can avoid them yourself. We’ve talked about how delivery teams need to be inclusively involved in our article on Leading Agile Transformation. In our last article, What does Agile mean to you,  we wrote about how some organisations are DOING Agile, and not BEING Agile. What about the broader teams? What about the broader organisation that supports project delivery, and that is supported by project delivery?

I mean, you wouldn’t implement a new HR system and only coach / guide / support the uptake of only a few departments, would you? That would be madness; people will miss out on their “pay days”, and inevitably (and quite quickly), there will be problems. When we think Agile, we need to think the same. We need to ensure we can reach the wider audience and bring them together. Otherwise, if limited in reach, it can introduce a plethora of issues like some of those we’ve seen firsthand:

  1. Executives will be open to Agile, but will begin to create makeshift structures when oversight is lost,
  2. Your ‘Agile’ people leave; the plan they were creating is based on their idea, vision and experience,
  3. Organisations attempt to drive a big bang approach; what appears calm on the surface is only brewing team dissatisfaction and angst, and
  4. You move to a new delivery model, dissolve governance, oversight, and support because you believe Agile is 100% self-governing (it’s not). You realise that it doesn’t work, and you revert back in the long run, only with less money and time wasted.

We’ve seen the good, we’ve seen the bad, and we’ve seen the ugly. Throughout every organisation’s journey to Agile ways of working, one must not underestimate the amount of facilitation and collaboration that is required to bridge the gap between delivery and non-delivery teams. Should we not do this, then we risk the many problems arising. We are working towards the same organisational objectives, so why don’t we try to put ourselves in the other person’s shoes?

At Agile Management Office, we understand there is complexity involved. One of our key principles is our 3 C’s (Collaboration, Coordination, and Consistency). In this short video, we explain why they are the core principles that underpin our method, and how it has helped us to succeed when facilitating, integrating and enabling capability within our client organisations.