RichardWhitehead

Richard Whiteheads' Blog

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.

agileIt 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

Traditional ScrumConsultancy Scrum
Inward facing (single company and product) Outward facing (external project and client)
Product based Project based
Product Owner experienced and knowledgeable about Scrum and the product Product Owner often needs to be identified and requires training about Scrum
Internal Product Owner External Product Owner
Developers are on a single team Developers often on multiple projects
Budget internally managed and fixed Billed on time. Time = money
Organisation has adopted agile Client often not interested in methods used to manage the project
Unlimited number of sprints Time/budget restraints
Constant velocity that’s easily calculated Velocity more difficult to gauge due to shorter projects
Team members are always the same Teams can be as agile as Scrum itself
Aligned on estimates Estimates often require re-calibrating

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!

Comments (1) -

  • Shane

    5/31/2018 8:28:41 AM | Reply

    Do you think "Consultancy Scrum" is easier to keep moving inline with true Scrum values, than it is with "Traditional Scrum"?  

    In a consultancy environment I find it easier to keep the Product Owner/Clients on track, because they are paying for our time and as a result their hold up's will cost them money.
    Where as traditional Scrum to me always battles against falling into a Waterfall approach, due to the fact the Product Owner/Clients feel less of a direct financial impact if you run over time, and are therefore less invested in the project and operate with less urgency.

Loading