I recently became a certified Scrum Master, to enable me to implement the methodology with DEPT®’s Digital Operations Services (DOS) team.
“What’s Scrum,” I hear you ask. “Is it the new buzzword in delivery and management? Is it just another word for Agile Management?”
Well, no and no!
What is Scrum?
Scrum has been around since the early 1990s. It’s a process framework based on empiricism, which employs an iterative, incremental approach to optimise predictability and control risk.
The Scrum process drills down through complexity to centre on building a product that meets business needs. The team and stakeholders work to formulate and assess requirements to deliver a working product incrementally. The team self-organises to deliver the prioritised cases in the sprint in the most efficient way.
The flexible and holistic nature of Scrum methodology enables a group to tackle problems and deliver products and changes of high business value.
Scrum Agile focuses on regular and clear communications, working products, collaboration and responsiveness to change. This means it’s perfect for our Digital Operations Services (DOS) team, who are tasked with delivering improvements, fixes and changes to our clients’ websites.
Why is Scrum right for DEPT®’s DOS team?
DEPT®’s DOS team ensures our clients’ sites are always live (that is our utmost priority), whilst tackling problems and changes to help them maximise the benefits from their digital estate. We always work closely and collaboratively with our clients to ensure the work we deliver is in-line with their business goals.
Pre-Scrum, the DOS team would accept bugs and changes without much detail, and it sometimes felt like the ROI on the work being delivered wasn’t as impactful as it could be. There weren’t set delivery dates so, occasionally, there were bottlenecks when clients weren’t available to test the releases we were making, leading to delays in delivery.
These were key areas I wanted to change within DOS to make the work more efficient and effective, whilst ensuring that we help our clients to provide ROI on their digital estates in a rapid and meaningful way.
The three scrum personas
There are three key personas in the Scrum team – Product Owner, Scrum Master, and the Scrum Team.
At DEPT®, these are usually:
- Product Owner – the individual responsible for the site on the client side
- Scrum Master – me!
- Scrum Team – the DOS team
There is a product backlog made up of stories added by the Product Owner (PO), and they prioritise and maintain the backlog. The PO bridges the gap between their company stakeholders (of which there will usually be many), and translates their requests into requirements and acceptance criteria.
The Scrum Master ensures that everyone follows the rules and practices under the Scrum Framework. They facilitate daily meetings, aid the PO in preparing for meetings, and support the team in removing impediments and restrictions.
The Scrum Master and Scrum Team have daily stand-up meetings to provide updates on what has been achieved in the last 24 hours, what they plan to work on in the next 24 hours, and any obstacles that will stop them completing the work.
The Scrum Team own the sprint backlog, decide what they can deliver and when, and break down the stories into tasks with the Product Owner, making it an efficient and collaborative relationship.
What’s a story?
Product Owners are responsible for writing the ‘User Story’ – this is information which captures the description of a feature or fix a stakeholder requires, acceptance criteria and the reason for the request. Stories are a good way to get stakeholders to really think about their request – why they want it, and exactly what it is.
There are also ‘Epic User Stories’ – these are large pieces of work that will need to be broken down into smaller user stories before they can be delivered in a sprint. It covers the who, the what and the why, and will also include acceptance criteria, for example:
- Who: I am a site user who is looking to find where to contact customer services.
- What: I want to be able to find the details quickly.
- Why: So that I can contact them about my query without frustration.
The User Stories are then passed to the Scrum team to estimate them.
What’s a sprint?
A sprint is a set length of time in which the Scrum Team agree they will deliver a number of stories, to provide a product to the PO. This is recommended to be anywhere between two weeks to a month.
I’m pretty sure that if you were to ask a team what they define as ‘done’, you’d get a load of different answers. *Cue my opportunity for a quick Scrum joke…*
Knock Knock.
Who’s there?
Done.
Done who?
Depends on who you ask.
Within DOS and under the Scrum Framework, ‘done’ means that the work is completed with developer testing, fully commented, and documented with a deployment plan.
Once the sprint is completed (and done!) the team confirm the stories that have been completed.
The Product Owner and stakeholders review the work and feed back. Of course, they will have ideas and comments, and this will help inform the next sprint of incremental changes to complete.
At the end of this review, the Product Owner will confirm that the sprint is ready for release, and this will go live across the site. And then the cycle will start again.
How are we approaching the move to Scrum?
In one word – tentatively. Scrum principles and processes are easy to learn about, but are a lot harder to implement. Whilst we have been using some aspects of the processes already, such as daily stand ups and time boxed sprints, we’ll be focusing these on Scrum principles further.
Firstly, we’ll be looking to work with our clients on the benefits of Scrum for delivery, and work with the stakeholders writing up Stories. We’ll then gradually bring in different estimation techniques for these and, after a period of time, move to a full Scrum Framework.
Continuous improvement
The team will complete a retrospective on what went well, but also what we could improve. For example, did we have a bottleneck in QA? Was the acceptance criteria not completely clear (and not questioned), leading to mixed feedback? The team will review this and adapt for the next cycle. We take every sprint as a learning experience, and always seek to continually improve.
Moving to Scrum will be a learning curve for our team, but one that we are all keen to do – we’ll keep you posted on the lessons learnt!
