10 tips for adopting Scrum to save your project

We’ve been involved in a number of projects now to move them from their existing project management frameworks to Scrum. The reasons for the move continue to be the same:

  • The project is still in analysis phase
  • The project’s longer term vision is relatively unknown so it isn’t progressing
  • The project’s wheels are spinning and the project needs to start delivering (but doesn’t quite know how)
  • The project lacks transparency of exactly what is going on, where money is being spent and what the outcome has been
  • The project is hemorrhaging money without producing results
  • The project’s environment keeps changing so it keeps doing analysis (and so doesn’t deliver)
  • Time and money is running out to produce something

1. Talk about the benefits of using Scrum, not how cool it is

When starting to talk about moving a project to Scrum, and why, it usually boils down to the following three elements:

  • Incremental, continuous delivery over all-at-once at the end of the project
  • Enhanced clarity and transparency
  • Enhanced control

Incremental, continuous delivery

A Waterfall approach only delivers a project’s outcome after everything has been planned, analysed and designed. If there’s a build of products involved (a document, a system, or what ever) then its released in one big lump at the end. Scrum instead delivers in small increments at the end of every 2 weeks (this timeframe is flexible but is set for the project). For stakeholders and project boards involved in a Scrum project our work has meant they will see benefits every 2 weeks.

Clarity and transparency

Scrum requires visualisation of the list of products to be delivered and the order of their delivery. The Team then works to that list, are required to announce what they can commit to (up-front) for that 2-week period, must visualise on a board what they are working on as they work on it, and lessons learned are held at the end in order to understand and learn from mistakes or poor estimates of commitment to work. In Scum, there is no where to hide.


Business Owners (often taking on the Scrum role of Product Owner) can change their mind about the order of delivery of products every 2 weeks at the beginning of each Sprint. They get to say what the acceptance criteria is for each product to which the team creates tasks to ensure delivery is done according to that criteria (and nothing else). In Scrum, when it’s run properly, there is very little wasted effort. The downside is that this demands great discipline from the Team and this is where a Scrum Coach is vital to the successful transition and adoption of Scrum.

2. Get a Scrum Coach

Too many projects I hear about who want to use Scrum don’t have anyone with a good amount of experience as a Scrum Master teaching the Team (and the project) how to make best use of Scrum. As a result, the project lacks the discipline required of Scrum, the Team fall back into old habits, Scrum’s benefits are not realised, and then Scrum is blamed for the poor result.
If you want to get the best out of Scrum you must find a coach who will:

  • Transition the project and set it up to use Scrum
  • Help the Team learn the rules of Scrum on the fly
  • Let the Team make mistakes — people really only learn from their mistakes, not their successes
  • Educate stakeholders — they need to support the project
  • Perform the role of Scrum Master — because no one else is going to have the skills (yet) to successfully take on the demands of this role
  • Review the Team’s performance, highlight where they are moving back to old, bad behaviours, and encourage them to unlearn these
  • Help the Team get better at using Scrum so they will eventually not need a Coach (you will always need a Scrum Master though)

3. Do a Scrum training workshop with the Team

If the Team (and senior stakeholders) haven’t used Scrum before, I’ve found it useful to start things off by establishing the ground rules of scrum, its roles, its controls, and its processes by:

  • Leveraging the Scrum Primer — a great document that sets out the basics
  • Talking about and using anecdotes from the New New Product Development Game (Harvard Business Review 86116:137–146, 1986) — to me its the core mindset for the philosophy of Scrum
  • Showing how Scrum works by giving participants a practical lesson based on a real case study — giving them a taste for the chaos that will occur when the project starts using Scrum with the reassurance that comes later of routine, predictability, self-management, close collaboration and a cadence for when change can be introduced to work.

What this does, in essence, is to ensure everyone is speaking the same language, has their terms right, and will start the real deal of using Scrum on a level playing field with the same expectations. Training, however, won’t teach them to know how to ‘do’ agile. The only way to know what to do is to cut your teeth for real on a real project. Don’t worry about failing, though, that’s why (as I remind my Scrum Teams) you have a Scrum Coach!

4. Move to a Scrum-based governance model for the project’s day-to-day execution

In a Prince2 controlled project, the project’s execution happens in a black box. When paired with Scrum, however, I’ve found roles are clarified and mechanisms for enhancing project tolerances and risk mitigation (over risk management) can be more easily realised.

5. Stick with Prince2 for the project’s controls and reporting

Inevitably, my experience has been that Project Boards require paper reports to feel comfortable that a project is healthy and proceeding according to plan. Scrum doesn’t articulate how to do this, but this is how I typically achieve this requirement:

  • Measure the estimates of complexity, how much the Team commits to in a Sprint, and how much it achieves in terms of matching estimates with delivery. In essence, this is just using burn-up/down charts.
  • Report to the Project Board that the project’s health is fine when estimates are within a 15% tolerance threshold
  • Report to the Project Board when milestones have been achieved
  • Report to the Project Board a forecast of milestones based on the Team’s velocity (the estimation of how fast the Team will burn through the list of Products in the Backlog)
  • Report to the Project Board and ask for assistance if the Team’s estimates are not within a 15% tolerance threshold — usually because of project impacts beyond their control that project executives need to intervene
  • Make it the responsibility of the Team produce the reports — they’re just another Product Backlog item

6. Set up a space for the Team

Scrum uses very visual channels to help communicate work in progress. It’s little things like putting up sticky-notes on walls that you would be surprised that aren’t allowed in some organisations.

  • Get permission to use a space dedicated to the Team’s work
  • Set expectations that the Team will be noisy with all their collaborative talk and action
  • Ensure the Team can use the walls to visualise work-in-progress

7. Create the Product Backlog

The old scope then needs to be transferred into a list of products and an order of delivery established that matches the needs of stakeholders and the project’s outcomes. Getting user-input into this process by doing a collaborative workshop helps to establish the expectation of what will be delivered and when based (in part) on their input.

8. Create the acceptance criteria for User Stories

It’s one thing to write up User Stories on cards and stick them on the wall. Without a clear acceptance criteria (ie: Definition of Done), the Team won’t know the expectations for a product’s delivery. I like to encourage my Product Owners to jot down anything and everything they can think of regarding what they’d “like to see” when the product has been completed. Importantly, though, I reinforce that this is not a predefined checklist to hand down to the Team, but a supplement to the User Story as a placeholder for a discussion. Thinking about Definition of Done early helps to clarify in the mind of the Product Owner what he really wants and needs so then he can walk into a formal Sprint Planning session prepared. As planning with the Team is underway, it’s highly likely that the Definition of Done will evolve and crystalise.

9. Visualise the Product Backlog

Putting the Product Backlog in a place where everyone and anyone can see it is important for project communication. Setting up expectations about what the Product Backlog communicates to passers by as well as the Team, though, is equally important.

10. Don’t do any more ‘design up-front’

Many designers and user-experience practitioners will expect to be able to do user-research while the project is being set up. Resist this urge. Doing some work to understand how to approach a problem or an ‘unknown’ might be useful (this is typically a refinement exercise), but if the ‘how’ is already known by the Team no one should then start doing the work. Some designers in my experience require a lot of persuasion to be fully integrated into the Team alongside Developers. The benefit to them is that a shared experience of analysis and design helps to increase acceptance of design solutions by Developers.

Now, you can start Sprint Planning and be prepared to explain why its important

Once you’ve gone through the 10 essentials, and put everything in place, the Team and the Product Owner can meet to plan what they can commit to delivering within the Sprint, and how they will go about doing it. 10% of the total time allocated to the Sprint is spent doing Sprint Planning. If the Sprint is 2-weeks in duration, then one full day is spent planning. For a 4-week Sprint, 2 whole days are spent planning. Some of my clients have suggested that this is a lot of preparation and not a lot of ‘doing’. Discussion of this type usually surfaces somewhere by someone as the project is being setup or transitioned. Spending this amount of time planning has the following benefits:

  • Creates great focus on what the outcomes required right now
  • Enables communication to senior stakeholders of what they can realistically expect in 2-weeks time
  • Provides transparency on the Team’s capability to deliver
  • Enables the Team to take onboard new work, changes in direction, and changes in scope in as little as 2-weeks time, should the project’s environment change tact and require action
  • Reduces waste — no action will be taken by the Team on a task that isn’t related to delivery of products in 2-weeks time

For a project that has been criticised for spending lots of money, without producing tangible outcomes, the later point in particular is especially effective in communicating why Sprint planning is so important to the project’s outcomes.


Setting up a Scrum project can take as little as a few days to establish a Product Backlog so that Sprint Planning can start. Sometimes, however, it takes a bit longer — new Team members have to be recruited, development and testing environments need to be bought and setup. Overall, however, even 4 weeks is a small price to pay for a project that has been going on for 6 months without delivery. The benefit is that you’ll now see outcomes in as little as 2 weeks.

About the author

Related Posts:

Groupthink: the bane of high performing Agile Teams

What makes an agile team great and why? After coaching a number of teams in Scrum, we’ve now seen a number that, after a some months now, could be considered high performers. Some of these go bad and reject any external criticism regardless of how accurate that might be. Why do these teams go bad? Groupthink might have the answer.

search previous next tag category expand menu location phone mail time cart zoom edit close