The success of an adaptive organisation lies in it’s organisational structures

The premise of Agile frameworks is promising. “We are uncovering better ways of developing software by doing it and helping others do it”. I love to interpret that as doing better software while having fun. Therefore organisations most recently started applying with mostly Scrum a Framework, with which they believe can get some quick wins. They sometimes hire external coaches and tell them to work with their team to implement and apply the Scrum Framework. And for the team itself it often works. If the organisation’s apply their Scrum based on it’s three legs and the Agile values, many would argue that a Scrum team is probably getting quicker and – if retrospectives and on top agile engineering practices are effective – also better results, than traditional organised teams. Nevertheless, at some point each team reaches a natural limit to further improve – the organisational structures.

Organisational structures define limitations of agile

In some organisations, the limits are reached earlier as in others. Those limits are usually defined by the organisation structures. Satya Nadella for example shifted Microsoft away from standalone software into a cloud environment, which ensured profitability. But more importantly it ensured that software releases can happen much faster. I was told once by a Microsoft employee, that the release time of Visual Studio could be cut down from once a year to once every three weeks because it was moved to the cloud.

Such a move to faster releases is a move towards the premise of agility: To break down complexity into smaller manageable portions. Due to faster releases, the organisation can learn and adapt to users much faster.

Agility continues with the what, not with the how

Many organisations apply to their teams an agile framework and think, this would make the difference alone. But after an organisation has understood and communicated, why they need to change, they should not just jump into making a lot of team adjustments. Rather it is about, what they want to deliver before they decide how they can deliver it faster. In most organisations it is product decisions, which fails to unleash the full potential of agile frameworks.

While teams are working on small iterations, develop software and release a potential shippable product increment every sprint, the product responsible persons or Managing Directors still insist on hard deadlines and inflexible scopes. So, once in a while, the team requires in the end again working over time and weekends to commit to a promised date, they did not promise. Or even worse: Top management requires teams to adhere to an inflexible scope because of an estimation made months ago.

Lean Product Development for continuous Product Delivery

The lean idea in product development such as Lean Startup does give a framework for organisations to break down nowaday’s complexity into small manageable units. Instead of investing over years into the development of a software, it helps to break down the uncertain into clear certainties. This certainties guide us to new decisions and the team develops the software continuously.

Agile Software Development and Lean Product Development go hand in hand. Ideally the results of experiments in a sprint -1 should go into the sprint backlog of sprint 1. Then the team can directly implement the results of constant verifications and ensures, that they are building right product as efficiently as possible. This is the foundation of a truly adaptive organisation: It’s organisational structures are all agile.

Nevertheless, this is ideal and the world does not always allow for such an approach due to:

1. Assumptions are not verified due to persevere decisions
2. Urgent customer requests
3. Bugfixing because of ineffective quality processes
4. Stakeholder pressure due to missing ROI or opportunities

Therefore, in one of the next blog, I will address the need of correct prioritisation.