Scrum is perfect for small, remote teams working on complex software products. But its rapid rise in popularity has meant that Agile Project Management with Scrum it is often not fully understood, even by those who have been exposed to it.
In this series, I hope to clear up some of the confusion around terminology, while providing a clear framework on how we implement Scrum across the majority of the projects we deliver at Scalable Path.
The Dawn of Agile
By deciding to build your software with Scrum, you are also embracing the Agile methodology. Agile was a response to a problem: software projects were coming in over deadline and over budget.
Probably the most famous cautionary tales comes to us via Microsoft: Windows 95 was late. Windows 2000 was late. Windows Vista was seriously late. All of these releases were built using a traditional project management method called Waterfall.
- Planning
- Design
- Development
- Testing
- Delivery
The Waterfall method has a long, distinguished history, but was found lacking for software development in the Internet age. An age where products become dated quickly and are often in a permanent state of evolution.
Today, Microsoft has fully embraced Agile. This is because Agile turned previous approaches on their head, well on their side at least.
Chart: Waterfall vs Agile
Agile encourages releasing software incrementally, instead of trying to deliver it all at once near the end. The diagram above clearly illustrates the fundamental differences between Waterfall and Agile. It is this incremental style which that has led to Agile systematically sweeping through the software development landscape. So much so, that less than 10% of projects currently use the Waterfall project management approach.
I find it easy to think of Agile as the guiding project management philosophy and the Scrum framework as the specific rules and directions used day to day.
How does Scrum work?
Scrum works by breaking each project up into bite-size chunks, prioritizing them and delivering them in short bursts called ‘Sprints’.
Scrums and sprints? Yes this was indeed based upon the game of Rugby. You can read more here if you are interested. But I digress…
The popularity of the Scrum framework likely stems from the way it deals with complexity and change. In does this in a similar way to how you or I would when faced with lots of work and not much time.
The Product Backlog
Write a list of all the tasks or features you would like to complete. In Scrum these issues are often called ‘User Stories’ and describe the user of the software that the feature is for, what they want to do and why.
Estimation
Every user story is given a score based on its assumed complexity. Common estimating methods include t-shirt sizes (S, M, L, XL), powers of 2 (1, 2, 4, 8) or the Fibonacci sequence (1, 2, 3, 5, 8, etc). We favor the Fibonacci sequence at Scalable Path and wrote a short article on why it is useful when developing digital products.
Grooming your backlog
Stories in the backlog are then prioritized by the client, based on their importance to the business. The stories near the top of the backlog need to be defined enough in order to begin working on them. It is less important to fully define stories that are low priority and not likely to be developed soon.
Sprints
Once the user stories in the backlog are sufficiently prepared, the Scrum Team can decide together on a subset of the stories that they think they can complete in a short period of time. These stories are put into a sprint and the development team focuses only on these issues for the duration of that sprint.
Most Scrum coaches recommend sprints to be one or two weeks long. We tend to run ours for two weeks, partly because of the overhead that comes with every release. A two-week schedule halves the percentage of time we spend doing deployment and releasing. If a project has mature automated testing and deployment, releases can be done more frequently without incurring overhead.
The period you opt for will be unique to your Scrum Master, client requirements and team. Here are some thoughts that should help you make a more informed decision:
- Remember Scrum is about fast feedback and improvement. Shorter sprints speed up feedback.
- High-performance teams often work better under pressure. Shorter Sprints provide this pressure.
- Each Sprint should be an independent shippable product. If your team is newly formed or you are working on larger tasks, you may need 2 or more weeks to achieve this.
At the end of a sprint, you should have a new version of the product. Then the process repeats and the next set of most important stories are pulled into the next Sprint.
Why is Scrum so popular?
There are a few key reasons that have seen Scrum become such a popular framework:
Iterative Development
Scrum embraces the agile MVP approach championed by Eric Ries: start with something simple and add to it over time. Scrum comes with baked in guidelines that assumes requirements will evolve – and so it is flexible when this happens. This is in sharp contrast to traditional project management approaches that shun change because of it’s high perceived cost.
Multi-disciplinary
Scrum encourages a multi-disciplinary culture where roles overlap (which is why it is so popular with startups). This approach is very effective at reducing ego within individuals and giving people a much better understanding of the value of other roles.
Scope can change
Agile “welcomes changing requirements, even late in development”. It’s even built into the Agile Manifesto. The client feedback that follows every Sprint is ideal for clients who get to ensure the project stays true to their vision and provide timely insights as the software evolves. But it also gives the development team the ability to innovate without sacrificing too much time or budget.
Better Communication
When you develop iteratively, you can take on board valuable feedback throughout the process. A lack of client communication on a Waterfall project might not become apparent until the product is the final QA stages. With Agile, any issues are likely to surface earlier on as features in a particular sprint are tested. This regular collaboration between all stakeholders is one of the reasons we recommend using Scrum for remote or decentralized teams, where communication needs to be part of the process.
Transparency and Accountability
Agile is built on transparency, and Scrum epitomizes this by keeping all tasks and communications visible to everyone. While transparency is vital to the correct functioning of a Sprint, it also has the added benefit of increasing the performance of team members. Harvard Business Review’s 2013 employee engagement survey revealed that 70 percent say they’re most engaged in workplaces that encourage transparency.
Who does what in a Scrum?
The Product Owner
If it’s your product that is being built or maintained, then this is you. You have the vision for the product, you know who the customers are and how the product will fulfill their needs. You also understand how the product meets your business and market requirements. If this paragraph is speeding your heart rate up, don’t worry, we wrote a guide on being an awesome Product Owner which you can read here.
As Product Owner, one of your main responsibilities is to manage the Product Backlog (This is the umbrella terms for all the User Stories mentioned previously). You have to ensure everyone in the business and the Scrum team agree and understand these features.
The Scrum Master
Scrum can be challenging to do well, and a Scrum Master’s job is to make sure the team follows the process they have decided upon. For example, the Scrum Master will schedule the daily standup meetings, ask questions of the development team, make sure meetings don’t go too long, and remove “blockers” that may be preventing developers from proceeding with their work. Scrum Master may be a member of the development team who has been trained in Scrum (e.g. a Certified Scrum Master) or may be a dedicated project manager.
The Development Team
The Development Team, which is typically up to 8 individuals, has a simple goal – to work together to develop the product.
An Agile team is self-organizing, which essentially means it is the role of the team to identify which competencies they are lacking for any particular project. But you do need a few key roles to get started. Typically a Lead Designer and Lead Developer will give you the knowledge to identify any remaining positions.
Ceremonies
Ceremonies are simply the Scrum term for ‘meetings’. The use of the ritualistic terminology should give you an idea of the importance these have within Scrum.
Agile guidelines typically list 4 key ceremonies. For a new project (or team) we strongly suggest you include each into your sprint process. They help ensure that the projects stays on track, that all members are fully informed and that your team will become more efficient at delivering work.
Over time though, as both projects and teams evolve, these set requirements may start to appear overly rigid. Agile, as it’s name implies, should not constrain you. We tweak the process for many of our projects as we become more familiar with the optimal way they should be run.
Sprint Planning
This ceremony is attended by the development team, scrum master and the product owner and occurs before each sprint. The scrum master should encourage collaboration by all members to ensure full team buy-in.
The aim of the sprint planning is to clarify every story that will be pushed live in the sprint. To facilitate this, the product owner will have prepared and prioritized the product backlog. Each item is then discussed individually and the team estimates the effort involved. This process continues until an agreement is made on what stories can be completed in the upcoming sprint.
The Daily Standup
As its name suggests, this ceremony occurs every day and is attended by the development team, the scrum master and the product owner.
“We sometimes tweak the frequency of other Scrum ceremonies, but always ensure we hold our Daily Standup. It is essential to the success of every project.” says Damien, CEO at Scalable Path. This meeting should be no longer than 15/20 mins. In fact, the use of the name ‘stand up’ was chosen so that, when meeting in person, teams would remain upright to encourage a short discussion.
Topics to be covered should be limited to:
- What was done yesterday
- What is being done today
- Any blockers or questions they might have
The product owner is there to answer any questions about how the software should function (or if necessary, take notes to get answers to questions later).
Sprint Review/Demo
The sprint review meeting is an informal round-up of all completed stories and a demonstration of the new product increment. By ‘informal’ I mean no slides should be used to guide the direction of the conversations.
Included in this meeting are the product owner, the development team, the Scrum mater and often stakeholders from the client who want to see output of the sprint.
If any stories were not completed, these are discussed ad the product owner updates the product backlog for the next sprint.
Retrospective
There is a natural tendency to skip the Retrospective in the rush to start the next sprint. But doing so regularly will affect growth and performance. Each team needs time to reflect on how they can become more efficient and adjust their behavior accordingly.
The Retrospective is, at its core, about how the team can optimize the way they work together. This should not be limited to discussions about the flow of stories through the process but should include anything that affects output: from the attitude of the team through to the software being used.
If you feel you need a framework for this part of the meeting then you may want to categories all issues raised into the following buckets:
- Start doing
- Stop doing
- Continue doing
The retrospective is attended by the development team, the scrum master and the product owner.
Conclusion
In this article, we’ve briefly looked at the history of the two major project management methodologies: Waterfall and Agile. We then demonstrated the key differences between them and why Agile now dominates the software development landscape. Finally, we walked through the three roles that exist in every Scrum team and the four prescribed ceremonies.
Hopefully, you now have a good high-level understanding of how Scrum works. In the next article in this series, we will build on this when we look more deeply at how the Product backlog and User Stories have redefined the more traditional requirements document.
Are you looking for help with your next software project?
You’ve come to the right place, every Scalable Path developer has been carefully hand picked by our technical recruitment team. Contact us and we’ll have your team up and running in no time.