This is the first in a long series of articles on Scrum which are meant to serve as guidance for tech startups who are eager to start working efficiently and deliver functional products as soon as possible.
We have been implementing the Scrum methodology for some time and would be very happy to share all its main steps and little secrets with you.
The sole purpose of this series of articles is to best serve your needs and shed light on what many believe is a very complex, difficult to put in place and time-consuming process. We’re hoping that, after reading these articles, you will understand that it’s not even a fraction as complex as what you are currently doing.
Defining Scrum
As defined by the Scrum Alliance, Scrum represents:
“a simple yet incredibly powerful set of principles and practices that help teams deliver products in short cycles, enabling fast feedback, continual improvement, and rapid adaptation to change.”
Another definition, given by the International Scrum Institute, states that Scrum is “a lightweight agile project management framework mainly used for software development. It describes an iterative and incremental approach for project work”.
For us, at Thinslices, Scrum represents our project development framework aimed at maximizing the value we can deliver to clients, by:
- Being Agile in addressing Software Development needs that “pop-out” out of their experience driving a Lean oriented Business Development process;
- Helping them be structured in their approach;
- Offering a good blend of flexibility and predictability;
- Stimulating participation of a well motivated Software Development team, resulting in ideas that positively influence the course of the Product in the Market;
Although initially designed for suiting the needs of the software industry (as the leading Agile development framework), the Scrum methodology is now used by publishing agencies, by consulting groups and many others.
Why do you need Scrum in the first place?
Basically, you are not happy with the way your team performs. Despite the fact that they are constantly complaining of having an overcrowded schedule and doing massive overtime, they only rarely manage to deliver on time.
Furthermore, in the days before the release date your team practically moves in the office and the stress levels reach the maximum limit. Why? Because everybody is terrified of the next call with the client when they don’t yet have a shippable product increment ready. More pressure is put on you and your team!
The chaos at work causes mental exhaustion, dissatisfaction and frustration among team members. As a result, there’s a high risk of experienced developers and QA engineers leaving the company.
Bottom line, nobody is happy and you have the feeling that you’ve tried everything by now and nothing seems to have worked for your company.
If you’re facing a similar situation and you’re not too discouraged to try a different approach, Scrum might actually make life easier for every member in your company (and that includes you!).
How did we figure out we needed it? What was not working?
Scrum came as a logical choice once we understood the profile of our client (Mobile Product oriented Entrepreneurs) and the value of the Lean approach in the Modern Global Market. Thinslices adhered to the principles behind these frameworks quickly after its first steps, based on the previous experience of its founders in using other models.
The difference between the Old Way and the Scrum way
The old way often refers to what is known as Waterfall development. It’s called ‘waterfall’ as this type of development is often planned using a Gantt chart – you complete one phase (e.g. planning) before moving on to the next phase (e.g. development).
The Old Way
- The project manager is the one making plans and decisions (driving the way), while requirements and analysis are done by architects.
- Tasks are assigned to the team which means that its members are never fully involved in the whole process. They can only do implementation, such as low-level design, coding, and testing. As a consequence to this approach, the team is not engaged and can’t see the big picture.
- Testing is not done until the end, which means any issues remain unresolved until the last phase of the project. And oftentimes there’s not enough time to fix them before deployment.
- You’re glued to an initial plan and any “surprise” that may come along the way, highly impacts the result.
- You don’t realize any value until the end of the project (when you deploy)
- You don’t seek approval from the client until the final phase of the project – there’s a high possibility that their requirements might have changed in the meantime.
With the Waterfall methodology, you will rarely manage to re-visit a phase once it’s completed. That’s why there’s a lot of pressure on you and your team to get things right the first time. This approach presents a high degree of risk, is often more costly, and generally less efficient than more Agile approaches.
The Scrum way
- The ScrumMaster is only a facilitator, while the Product Owner can only define what to do. The team has the authority to decide how to do it. The plan and the decisions are made by the team, who is fully in charge. Not only can they see the big picture, but also be part of it. After working in this way for some time, the team becomes proactive and energized.
- Testing is performed constantly, which means that issues are solved along the way, clearing the path to deployment.
- The team doesn’t need to stick to an initial plan, since the Scrum methodology relies on flexibility and allows adjustments as work requirements change. In other words, by reprioritizing the tasks, new features can be added without altering the workflow.
- By placing the team in charge, developers get to devise ideas and come up with solutions. Individual work and constant feedback are thus sustained and encouraged. During sprint reviews the entire team makes suggestions and thinks of ways to improve the workflow.
- There’s value in every sprint. At the end of each iteration, you have a shippable product increment ready.
- Communication is enhanced between all parties through defined roles, clear requirements, and tasks.
By focusing on delivering fully tested, independent, valuable, small features, the Scrum methodology is far less risky than the Waterfall approach. The good part is that if one feature is messed up, this should not have an impact on another feature.
The difference as seen by Thinslices
We have passed these three stages to reach the point where we are now:
- Early days chaos inspired by doing what needed to be done - I'm hardly able to characterize these days by using a model
- Trying to do Scrum - everyone doing Scrum now knows what it’s like having been in the early adopter group
- Doing Scrum
As a consequence, the difference is roughly absolute in terms of structure, quality, and predictability.
Scrum Roles. All for one and one for all!
The Product Owner (PO)
- is, usually, the client. He’s in charge of capturing and conveying the value proposition of the product to the development team, thus maximizing the result of their work. He is responsible for prioritizing the list of features and writing short descriptions of all the functionalities (he manages the product backlog).
The Scrum Master (SM)
- has the task of removing any impediments that hinder a team’s accomplishment of its sprint goals. The best Scrum Masters are real team players, who receive as much satisfaction from facilitating others’ success as their own.
The Development Team
- is not just an executive organ. Instead of receiving its tasks from the project manager, the team decides, self-dependent, which requirements or User Stories it can achieve in one sprint. In the Agile approach, the team becomes a manager. It makes up the tasks and is committed to delivering incremental functionality at the end of each sprint.
Scrum Ceremonies. A brief description
The Sprint Planning Meeting is attended by the PO, the Scrum Master & the team to plan the activities for the next sprint.
The Scrum Backlog Grooming takes place regularly. The team, including the PO, meets to "groom the product backlog". This implies removing stories that are no longer relevant, creating new stories, re-assessing the priority of stories, and assigning or correcting estimates.
The Daily Standup Meeting is time-boxed to 15 min and it takes place at the same time every day. The team meets to bring everyone up to date on the information that is vital for coordination: each team member briefly describes any "completed" contributions and any obstacles that stand in their way.
The Sprint Retrospective meeting is facilitated by the Scrum Master. During the Retrospective, the team discusses the just-concluded sprint and determines what could be changed that might make the next sprint more productive.
The Sprint Review takes place on the last day of each sprint. The purpose of the meeting is for the team to show the customers and the stakeholders the work they have accomplished over the sprint.
Something to look forward to...
In our next article, you will be introduced to several Agile tools that you can use for a successful implementation of Scrum within your company. As you will probably see, choosing the tool that best suits your needs is no easy thing. That is why you must arm yourself (and your team) with patience, flexibility, and openness.