Consultancy Scrum is very different from Traditional Scrum

Having come from a traditional Scrum background and moving into consultancy Scrum, I’d quickly noticed that although the problem it’s trying to solve is the same, the approach is vastly different and more complicated than the former.

Almost all of the articles and books out there are focused on traditional Scrum so it’s not as simple as reading a book and being able to make a start tomorrow. In this blog post I’d like to write about the most common differences that I’ve come across so far.

Traditionally companies use Scrum to manage and develop their own products using their own resources – they’re facing in-wards. Stakeholders, Product Owner, Scrum Master and the Scrum Team are all part of a single company. Sprints are unlimited, budgets and resources managed by a single entity and the teams never changed.

Using Scrum in a consultancy to deliver a project rather than a product means there are a few key differences in the way we approach the framework but these subtle huge differences can be the making or breaking of a project. We need the process to work, and work well every time, for both the client and vendor.

It needs to have supermaneuverability – ‘the ability of aircraft to maintain pilot control and perform maneuvers in situations and ways exceeding those that are possible using purely aerodynamic mechanisms,’ where the purely aerodynamic mechanisms are those of traditional Scrum.

Non-the less, the goal of Scrum doesn’t change: to get the most important stuff done first with more frequent, demonstrable, releasable software.

Below is a summary of the key differences and challenges there are with consultancy Scrum vs traditional Scrum

Consultancy Scrum is a bigger challenge than traditional Scrum because it’s more fluid, reliant on external input and every project has different dynamics. But that forces the teams to become more efficient and streamlined – and fast.

They can’t spend time in meetings about meetings or have retrospectives that last half a day. Every sprint planning, stand-up and retrospective has a direct impact on if the project is successful.

So where’s the best place to start with applying Scrum to a project? That’s a tough one and to be honest, all aspects of Scrum need care and attention. I know that putting the effort in at the beginning;  identifying and training the Product Owner, having clear project goals across everyone involved, a well groomed and beautiful backlog and as always – identifying those risks and dependencies with a plan to mitigate as early as possible is the best place to start (not forgetting having a great team to work with!)

Different teams and companies will have different approaches, it’s up to the team and Scrum Master to find what works for them.

If anyone knows of any other differences, has any advice or horror stories, it would be great to hear from you!