Hamish King

Hamish King


Thoughts and ideas from a consultant trying to improve the enterprise through better lean/agile principles, sensible design and pragmatic solutions.

Hamish King
Author

Thoughts and ideas from a consultant trying to improve the enterprise through better lean/agile principles, sensible design and pragmatic solutions.

Share


Our Newsletter


Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

}}

Tags


Twitter


4 key principles of scaled agile success

Hamish KingHamish King

// Update: I'm revising this post 6-months later to add some additional thoughts that have taken much longer to surface!

Having been a major part of a large technology operating model redesign for almost a year now, there are some key principles that I believe are key to the success of any large agile transformation.

1. Train, support and coach everyone in the organisation

People are the most important part of the organisation and are the ones doing of all the work. We are all creatures of habit and as technology professionals we are often in the business of changing others, we are very resistant to change ourselves.

So it is simply not enough to provide some one-off training and leave everyone to find for themselves (as often happens).

Training: On the training side there should be role-based training available, different levels, 'learner journeys' and tailored role-based training options available.

Coaching: Once the training is completed, there needs be someone (preferably multiple!) around to help put this training into practice. The coaching should always be contextual (which is difficult to do in the classroom) and applied, building upon those concepts learned. Coaching can be proactive and reactive; proactive as a team is new and needs stronger guidance and gradually moves towards reactive as the team becomes more familiar and the coach can respond to queries and take a backseat role.

Its also incredibly important to genuinely provide training, coaching and ongoing support for literally everyone - not just delivery teams, or development managers. Management are often passed over in agile training (predominantly due to time restraints) but it in order to embrace and support true agility, everyone must be on an equal footing.

2. Single iteration cadence

This one is straight out of the SAFe playback but an important principle (one we picked up during our early stage research - well before we starting looking at SAFe) .

When you have a decent number of agile teams working (10+) it is highly likely that they will have some form of dependencies between them. Even more important when dealing with 50+ or 100+ teams; having a consistent iteration length and timing (i.e. 2-weeks, Wed -> Tue) enables regular alignment and integration between any and all that need to.

It also has the benefits of predictability (book meetings well in advance) and allows for integration with external suppliers / vendors working to different timings / methodologies.

Teams will push back. Some prefer 3 weeks, some 4. Stress that this is to enable enterprise collaboration between teams and that a 2-weekly cadence is not the same thing as 2-week release into production. It should be potentially-shippable but not every team wants to or should release after every iteration.

Also ensure the start date (i.e. Mon or Wed?) of any iteration change is appropriately considered. Starting an iteration on a Friday maybe isnt the best idea, neither is starting just before a holiday break.

3. Single portfolio/backlog management tool

This one always brings up a lot of contention and heated debate. People almost fall into religious camps when it becomes to tooling as everyone is coloured by their own experience.

The important thing here is not which tool, but only that there is only one! Trying to co-ordinate backlogs within an ART across multiple backlog management tools - possible but difficult and will pose all sorts of unnecessary integration challenges.

Single, consolidated portfolio view of epics and features across multiple backlogs? Again very difficult to achieve without

4. Measure and report progress

Another one we picked up in our research from speaking with other organisaitons going through an agile transformation.

If a baseline of current is measured, even at a high level, it will be much easier to show the impact that agile is having (or not having!). Without some concrete measures of what things like 'time to release', 'cycle time' etc looked like before the transformation it is very difficult to quanitfy and show the benefits even if subjectively and andeoctbly they appear to making a big difference.

Anti-patterns (or distractions)

Hamish King
Author

Hamish King

Thoughts and ideas from a consultant trying to improve the enterprise through better lean/agile principles, sensible design and pragmatic solutions.

Comments