When I meet new people in an informal setting, say at a friend’s BBQ, there’s a little bit of me that’s thinking, “Please don’t ask me my occupation.” Don’t get me wrong, I thoroughly enjoy my job and feel very proud of my achievements in this profession, it’s just a difficult one to explain, especially to people who aren’t involved in software development.
“Hi, I’m a Scrum Master” I say. This introduction is usually met by confused faces, or the assumption that I like playing rugby. But what actually is a Scrum Master? What value does the role add to a business and to its clients? To answer this, we need a quick history tour on software development. Stay with me folks, it’s interesting stuff.
Prior to the Agile approach, many software development projects followed a framework called Waterfall. This took its name from how the work flowed down different stages within the entire development cycle. Imagine water running down steps and you’ll get the reference.
The stages were: Requirements Gathering, Design & Architecture, Implementation, Integration & Testing, Deployments & Maintenance. All very robust in their own right, however this structure made it difficult for things to go back up stream. It was liable for scope creep because additional things were discovered during different phases of the process. And it wasn’t iterative, which meant the project was delivered in full at the end rather than in stages, therefore the overall timeline could be very long.
Although Waterfall had many success stories and still has today, it also had some failures. Take the Virtual Case File system as an extreme example. This was the project name for an attempt to bring the Federal Bureau of Investigation’s IT infrastructure and software into the 21st century. Starting in 2000 as a $380 million contract, it was finally scrapped in 2005 having lost $104 million in taxpayer money, with absolutely nothing delivered. [Source: Wikipedia]
Off the back of these failings, a number of people decided to come together to review and retrospect the software development process and from that… Scrum was born.
Scrum is a form of Agile software development. ‘Agile’ as the definition of the word suggests meaning “Able to move quickly and easily”.
A great early example of Agile working would be Toyota’s car manufacturing plants in Japan in the 1950s. The company wanted to improve their manufacturing output, so the guys at the top decided to do something unheard of at the time, they asked the factory workers how they should improve things. In my opinion, this was the start of it all. Bottom up leadership, getting the person with the most hands-on knowledge, then providing them with the tools and environment to achieve their goals.
They started to use display cards to represent tasks within their workflow. This enabled them to visualise the work in progress and better still, visualise the bottlenecks. With this visualisation, they could act on the problems quickly and reduce bottlenecks to improve output. This resulted in the birth of Kanban, which in Japanese can be roughly translated as “Card you can see”.
To me, Scrum is an evolution of this. It takes a lot of the principles of Kanban but mixes it in with a further understanding of human habits and how people work together as a team. Things such as motivational drivers, ownership, early feedback, communication and size of team.
The nature of what we do at Researchbods means our approach needs to be agile, allowing us to deliver value to clients as early as possible. The ‘project’ is to continuously develop our proprietary software platform ex-plor – an online insight platform that allows clients to create a data relationship with their customers. The platform needs to work seamlessly for all involved and continuously evolve with the addition of new features.
Areas for development come from: client feedback, market research trends, advances in technology, platform members, community managers etc. Some changes are major and need to be broken down into several stages, some are smaller and simpler to tackle. In both cases the Scrum approach allows them to be progressed and released more quickly using an iterative process which we call sprints.
Scrum team: our team is made up of highly skilled developers, testers, product owners, deployment and data engineers, with our main shared goal of improving the ex-plor platform.
Product backlog: essentially this is the ‘to do’ list with new items coming in from various sources and stakeholders. These requests are logged and stored centrally to help us keep track.
Sprint planning: we discuss the items from the product backlog to understand the value that each one offers to our clients. Only then can we prioritise what should be done in each sprint. It’s important to be realistic about timings here so that we can manage expectations with stakeholders for upcoming stages.
Sprint backlog: our product owner prioritises the items for the next sprint, making sure the team agree that the work is achievable within the sprint timebox. This can then be communicated to the rest of the business and clients to provide visibility.
The sprint: we currently work in a 4-week sprint, but it can be 2-4 weeks long, although a consistent approach is essential. During this timebox we plan, develop, test, review, deploy and retrospect our work in order to consider it ‘done’. At the end of each sprint we should have a shippable increment of the ex-plor platform that can be released to our clients.
Daily scrum: a 15-minute timebox each morning to discuss items of work within the current sprint. This facilitates communication amongst the team and keeps a focus on the priority work. We use our kanban board to visually monitor progress and communicate any changes to the plan as early as possible.
Sprint review: once the sprint is complete this is an opportunity to provide feedback to major stakeholders on the work achieved. The session takes advantage of the short iterative cycle to gain early feedback and incorporate any comments into the next sprint.
Sprint retrospective: reflect on the previous sprint and openly discuss the good, the bad, and the ugly. This is not about the work delivered, it’s more around the process, tools, environment and team. The aim being to continually improve ways of working and increase efficiency.
So, with all this in mind, a Scrum Masters role is to understand the Scrum process inside and out, coach the team on how to use it and embed the value it offers. We can help to resolve impediments, which are things that prevent the team from progressing or completing their work. We encourage the team to use past experiences to improve how they could work better next time round. We coach individuals to be self-sufficient, giving them autonomy to make decisions and own their workload, while maintaining a team mindset.
An Agile approach to software development means responding, working and delivering at a very fast pace. Scrum enables us to tackle workloads in a highly controlled and considered way, ensuring each sprint delivers real value in achievable and visible timescales to all involved.
