It’s easy to tell when a project needs rescuing.
- After many, many months, the project is still in analysis phase.
- The project’s longer term vision is relatively unknown, so work has yet to progress in a meaningful way.
- The project’s wheels are spinning, there’s lots going on, and people are busy, but there is pressure for the project to start delivering something.
- The project lacks transparency – 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 business analysts keeps doing analysis and collecting requirements, UX practitioners keep doing user research, and solution architects keep designing and re-designing. As a result, delivery is stalled.
- Time and money is running out to produce something.
How do you help these initiatives to get moving? Changing from an ad-hoc or waterfall way of working to a contemporary framework, like Scrum, can bring the momentum that executives need. Here’s our 10 top tips to making the move to Scrum.
1. Start by talking about the benefits of using Scrum over Waterfall, not how cool agile is
When starting to talk about moving 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 of actual progress over % complete of tasks
- Enhanced control to pivot and adapt to change over following a plan that is set in stone
Incremental, continuous delivery
A Waterfall approach only delivers an outcome after everything has been planned, analysed and designed. If there’s a build of digital products involved (a document, a system, or whatever) then its released in one big lump at the end. Any change management also typically occurs at the end based a business readiness. This ultimately delays the value that stakeholders receive.
Scrum instead delivers in small increments of business value every Sprint (typically 2-weeks). The decision to release an increment is part of the responsibility of the Product Owner. Stakeholders can see that increment, provide feedback, and provide insights into changes in their environment at the conclusion of every Sprint in the Sprint Review. This increases transparency regarding the state of delivery.
Clarity and transparency
Scrum has specific artefacts and events that the Scrum Team use to build transparency.
- Product Backlog – the list of all of the work that is known (at any point in time) to achieve the Product Goal. The Product Backlog can be added to at any time, but is formally adapted at Sprint Review through feedback from stakeholders and the whole Scrum Team.
- Sprint Backlog – the list of all of the work (features and tasks) needed to achieve the Sprint Goal, which in turn will deliver a step toward the Product Goal. The team inspect this artefact every day in the Daily Scrum to assess progress toward the Sprint Goal and adapt the Sprint Backlog to ensure it always reflects the team’s plan.
- Increment – work that has achieved the team’s quality criteria (Definition of Done) and can be potentially released to stakeholders and users. The team inspect the increment at Sprint Review.
When Daily Scrum occurs every other day or less frequently, transparency of the plan to achieve the Sprint Goal suffers.
Control and flexibility
Agile creates enhanced transparency through seeing an increment of the product by the end of each and every Sprint. The result of inspecting potentially releasable product increment is having true insights about what to do next – continue with the plan or pivot to something else, whether its due to a change in the environment, standards, compliance needs, or a change to what users and stakeholders value. Having stakeholders contribute to that decision in Sprint Review is key.
2. Get help from an experienced Agile Coach
The State of Agile surveys each year highlight that many agile initiatives fail due to lack of experience.
To do agile well requires experience. If you want to get the best out of Scrum, find someone with experience with agile who will:
- Help executives and leaders to establish guardrails for how teams will self-manage.
- Help managers establish agile governance, particularly, how Scrum Masters will work with their teams and be accountable for the effectiveness of Scrum.
- Transition teams from Waterfall and help them to set up to use Scrum.
- Help teams learn to apply the rules of Scrum on-the-job
- Let the team make mistakes – people really only learn from their mistakes, not their successes
- Educate stakeholders – they need to support the evolution of their product
- Review the Team’s agile capability maturity, highlight where they are moving back to old, bad behaviours, and encourage them to unlearn these.
Agile metrics for project management reporting
Use real time data modelling on your teams agile behaviours and get forecasts of cost savings.
3. Train teams and create consistency
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:
- The Official Scrum Guide – a great document that sets out what Scrum actually is written by its creators, Jeff Sutherland and Ken Schwaber.
- 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 on real work. Don’t worry about failing, though, that’s why (as I remind my Scrum Teams) you have an Agile Coach!
4. Move to a product-based governance model
Agile roles are different to traditional governance. Scrum’s role in particular focus on product development not project management. This improves speed to decision-making.
5. You still need reporting
Inevitably, my experience has been that Project Boards require paper reports to feel comfortable that any initiative is healthy and proceeding according to plan. Scrum doesn’t articulate how to do this, but this is how I typically achieve this requirement:
- Understand the amount of Product Backlog the team can turn into an increment each Sprint (velocity).
- Use the velocity to forecast when items in the Product Backlog will likely be done, including specific milestones.
- Create and use a roadmap for reporting, one that visualises month-to-month what is likely to be delivered out of the Product Backlog.
- Report on the health of the product, including technical debt and defects or rework.
- Make it the responsibility of the team produce the reports — it’s really just another Product Backlog item.
6. Set up a space for your teams
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 teams’ work.
- Set expectations that the team will be noisy with all their collaborative talk and action.
- Ensure teams can use the walls to visualise work-in-progress.
7. Create the Product Backlog
The old scope then needs to be transferred into a single, rank-ordered list of work. A Product Owner also needs to be nominated to ensure that it always (and continuously) reflects the most valuable outcomes for stakeholders, users, and the organisation, at the top.
Getting user-input into this process by doing collaborative workshops helps to:
- Create transparency about what is of value.
- Create transparency about what is currently known that will contribute value to the product’s goal.
- What can be delivered and when based on the actual capacity of the team.
8. Create the acceptance criteria for Backlog Items
It’s one thing to write up User Stories on cards and stick them on the wall. Without a clear acceptance criteria (and a Definition of Done), teams won’t know the expectations for a product’s delivery. I like to encourage my Product Owners to consider:
- Business rules – are there any specific rules that need to be met?
- Process steps – what logical steps need to be followed to complete a process?
As items are refined over time, it’s highly likely that the acceptance criteria will evolve.
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. Stop doing ‘big up-front design’. Do iterative design balanced by intentional design
Ad-hoc and Waterfall work tends to reinforce work in functional silos. UX people undertake user research; business analysts then collect and document requirements; and then, when all of these activities have defined everything that is known at that time, delivery commences. The cost is delayed value at due to a focus on comprehensive documentation that will likely be out-of-date when a change is requested by stakeholders when they get to see parts of the working solution.
As soon as “enough” is known about users and requirements to start a Sprint, then start the Sprint. Scrum Masters have an important role to encourage the team to be cross-functional over working in this traditional functional silos. Each item the team takes from the Product Backlog, and plans, should then receive the treatment of design, build, test, functions. This means design is done in small parts, rather than all at once upfront. What stops those pieces from becoming disconnected? The key is to be:
- Mindful of the Product Goal. Let the Product Goal define what is added to the design and what can be left aside for now.
- Balanced in using intentional design and emergent design. Some design will probably need to be done upfront for each backlog item before it gets to a Sprint. This can be done as part of Backlog Refinement. Allow the remainder of the design to emerge as the team works on the item.
Conclusions
Setting up a Scrum Team can take as little as 1/2 a day to establish enough of a Product Backlog using techniques like Storymapping 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 acquired and setup. Overall, however, even a few weeks of setup is a small price to pay to get a project into delivery when it’s been going for months without seeing progress. As soon as the Scrum Team starts Sprinting, you’ll see outcomes in as little as 2 weeks.
M
