About Bobby Singh

Bobby leads the Tribe at Momenton. Our mission: “Enabling impactful change through technology and a relentless passion for delivering customer value.”

Why Spotify-ING your enterprise is not the answer

Overtime most organisations have headed down the path of Agile enlightenment. We have evolved quite significantly from Agile 101 thinking to successfully having applied agility at scale in complex enterprises – as a result many models have emerged and effectively sought to ‘codify’ what is built out by the heart-beat that represents your organisation.

More recently we have seen the rise of ‘frameworks’ that aim to guide Agile ‘transformation’ (I do dislike this word – there is just something ‘Clockwork Orange’ like about it). And the adoption of someone else’s Op Model – specifically Spotify or ING.

The problem with taking a ‘lift and shift’ view on applying someone else’s Op Model to your enterprise is – IT DOES NOT WORK. I could be wrong but I don’t think Spotify woke up one day and said lets create a Op Model that everyone can copy – what I’m pretty sure happen is they scaled organically as demand around their product increased and the culture that defined their organisation emerged. This is important to recognise as its safe to say they evolved their organisation and continue to do so and hence do not apply someone else Op Model but seek to learn iteratively on what is best for them.

Having said the above there are probably 2 key lenses you can apply when scaling Agility in your enterprise:

The Practical

  • Scale on cadence:
    • Introduce a mechanism to permit frequent feedback & planning loops in your enterprise. If we break it down moving a complex enterprise to regular planning cycles at least seeks to align frequently rather than standing up long running programs that carry on for years
    • Seek to align the organisation front-to-back. In other words don’t localise or associate Agile with Technology teams only – but seek to ensure planning across the enterprise is all inclusive – i.e. if your product has a marketing, sales or technology component ensure planning includes these groups. (you need full alignment)
  • Show case frequently – not just working software – but go beyond this and showcase a commercial outcome or customer/product oriented solution. Showcasing just working software does not necessarily equal progress or value.
  • Learn and adapt often – op models are not static (hell this is why most organisations restructure so often). I’m not saying restructure all the time – but what I am saying is seek to learn and adapt based on these learnings and evolve your op model against your context.
  • Be transparent – accept failure as a learning and opportunity to adapt. Do not seek to punish failure.

The Hard Stuff Lens

  • Culture is hard to scale – this is actually the core reason why you cannot lift and shift someone else’s Op Model. Large enterprises are riddled with complexity and lots and lots of people. Some people are just part of the system – I refer to them as ghosts in the corridors who have been there for years and have essentially given up after seeing change after change – how on earth do you scale this? WHY WOULD YOU WANT TO?!
  • You can however, look for willing minds and create an environment of ‘holacratic’ change.
    • This is effectively where the concepts of chapters, guilds etc can come into play. They effectively seek to move you away from traditional meeting formats – where you would typically get top down updates and a kind of ‘manager’ led meeting to a more community led and organic evolution of key areas of interest for the benefit of knowledge share and uplifting enterprise capability.
  • Don’t reward failure – don’t punish for it either. Create an environment where failure is taken as a learning opportunity. This can be in the form of a retrospective style view on your change journey. An important note to accept though is ensuring we are learning from failure and not making the same mistakes time after time.
  • Break down the barriers of hierarchical structures/management styles and seek to provide a flatter structure focused on leadership. Support this with clear vision and direction and give your people something to believe in – vision & purpose go a long way to achieving buy-in.
  • Drive your own change – we have a lot of consulting ‘snake-oil’ floating around at the moment. By all means consume it but drive your own change and lead it internally – probably the best example of an enterprise that has done this well in Australia is Australia Post. The team in the DDC (Digital Delivery Centre) were clear on their intent when setting down the path of scaling Agility in their enterprise. Their primary focus revolved around delivering outcomes for the customer and an autonomous culture centred on ownership (as in a sense of belonging). The managers became leaders and sought to remove the traditional barriers of funding, enterprise resistance and legacy thinking out of the way. So lead your own change!
  • Be wary of the licence for change – I don’t know quite how to explain this in a writing but I guess what I am effectively trying to say is change generally occurs in the face of resistance – this type of change is a rise up style and actually leads to an organic coalition of the willing being formed. When change is a licence and mandated as an Agile transformation then sometimes you get what were previous resistors as experts or passive resistance – I call these ‘wind-socks’. The danger with this licence is you don’t want to be sitting a year or two into your transformation and not delivered an outcome – as this is the sure fire way to ensure your Agile transformation stops and effectively gets seen as a failure. So anchor against an outcome and be conscious of the wind-socks.
  • On the flip side though you will also see the best come out in your people and tap into some genuine change agents who given the opportunity will drive and step your enterprise through its evolution.

Anyway I’m gonna wrap this up. In conclusion what I am trying to say is there are 2 key elements to enterprise change –

  1. The practical component – where applying practices and process will give your the tools for change but not necessarily allow the change to be sticky.
  2. and the cultural aspect associated with your identity (the hard stuff) – Cultural change can be tough but sometimes special things happen and people who want change in your enterprise will rise up and lead it despite the barriers presented.

Don’t simply think lifting and shifting someone else’s Op Model is the answer – use these models to inform what can be leveraged for your enterprise context and scale forward from there.

Bobby leads the Tribe at Momenton. Our mission: “Enabling impactful change through technology and a relentless passion for delivering customer value.”

Don’t throw away your PMs yet…

There is a common mis-conception that Project Managers (PMs) are not required when scaling Agile teams and a view that the miraculous unicorn of Agile Zeolotary will ensure team culture, ownership and delivery. Well i got news for you — that’s not the case and you need your PMs (for a little while anyway ;)). How they operate however, must change in-order for you to effectively support scaled Agile delivery.

In a traditional enterprise context the PM effectively drives outcomes through tasks and management against phases and milestones. If you want your Agile teams to be successful the PM needs to take a lens that is more outcome focused with a view on value delivery (i.e. keeping the customer front of mind). This is a massive mindset shift as traditional project management learnings lend themselves to providing assurance through phases and gates — thus creating a perceived confidence on delivery. The key is to move away from a schedule and phase driven mindset to a feature and value driven mindset.

This shift doesn’t negate the need for planning. Infact, it becomes front of mind for Agile teams. Through the various ceremonies this by default is covered and when working at scale key items relating to delivery are drawn up through a ‘bubble-up’ process (team-of-teams retros). The PM does however, have to recognise their place in an Agile environment, with one of the key responsibilities being to act as an interface to ‘non-agile’ teams or other systems of complexity within the enterprise.

In many traditional enterprises the system of works is riddled with complexity — typically coming from years of application complexity in ‘core’ systems. These things can’t change overnight!! So it is key this is managed and co-ordinated to ensure the slowest moving part in your system of works does not end up being the bottleneck to planning an end-to-end view on delivering for your customer.

 

A few practices that work:

  • Having lite-weight pipeline/pre-planning kanban helps to line up dependency platforms in your system of works. This in turn helps influence priorities of works.
  • Cross cutting initiatives should be planned together (across teams) not in isolation. (align where possible and synchronise the teams)
  • Plan to a known Horizon — forecast the rest. Pretty self explanatory really — only plan what you know and line up your cross platform dependencies. Forecast to a roadmap based on learnings and assumptions on complexity.
  • Go beyond your stand-ups. Implement a Scrum-of-Scrums (SoS). invite everyone that matters to achieving the outcome (ensuring the Pigs are the ones that speak). The SoS should be kept short and provide a snapshot view on the key focus areas for the teams.

 

A few practices that don’t work

  • Task managing teams. PMs you need to stop this shit!! A major anti-pattern to team collaboration and ownership
  • Seeing every deviation from a ‘mythical’ schedule as an escalation. Let the teams work it out.
  • Assuming a project is locked in stone in scope, cost and time. I have not seen anything delivered with certainty — hell my mail doesn’t come on time what makes you think your project is going to be done in 12 months?

Conclusion

The bottom line is PMs are still needed in Agile environments operating at scale. Enterprises are loaded with complexity with platforms and systems that have been built over time. Some are more Agile than others but this activity still requires co-ordination and alignment.

This is one of the new roles the PM starts to play — a shift from the traditional approach of task and resource management.

Bobby leads the Tribe at Momenton. Our mission: “Enabling impactful change through technology and a relentless passion for delivering customer value.”