Introduction to Scrum

Before we even start to talk about Scrum (it is not a acronym!), let me introduce the word agile. Many people nowadays heard about it, many say and think they are using it, but not everyone really know what it means to be agile. That's why this introduction is so important. Word agile and the movement started in 2001. Almost everyone in the IT industry have seen or read the agile manifesto text. It is shown on many occasions (presentations, workshops, articles), because it is short and simple. That is why many think that it is everything they need and it really hurts the agility.

If you want to think about agility, please read at least the agile principles. They give you better understanding that agile is not near cowboy coding and loosely management and working software in manifesto is about something that really (not barely) works. If you read it, you will find many places where it informs not only about management and interaction, but also about quality of code. When you get to know Scrum, you will see how well it aligns with the manifesto and principles. Also notice that Scrum alone is not addressing all principles. For some of them you need to get a closer look at the best engineering practices. That is OK, because Scrum is just a framework, not a silver bullet. It do not contain answers to everything you want to fix, because solution to the problem depends on who is asking.

Scrum in the nutshell

First, good news. Scrum is simple. Second, bad news. It is not easy. Many have fallen implementing the simple rules mentioned below. It is easy to explain, but very hard to get working right. You may also think that because it is simple, how much power it may have. A lot! Some companies stopped stopped to use it because they couldn't stand the disfunctions it was exposing all the time. You have to have a real desire to change. If you do it, you can count on at least 2-3 productivity gains and be driven by business value.

The elements

Scrum uses only three roles: Team, Scrum Master (SM) and Product Owner (PO); two lists: Product Backlog (PB) and Sprint Backlog (SB; there may also be a Impediment Backlog); and three meetings: Sprint Planning, Daily Scrum and Sprint Review. There is also two graphs: Sprint Burndown and Product Burndown. Simple?

Lists

Product Backlog is a prioritised list of stories (functionalities and non-functional requirements). Each story is a short description of the functionality, tells why it is needed and contains work effort estimates done by the team. Everyone can add a story to it but only PO is responsible for prioritisation.

Sprint Backlog is a list of stories and tasks selected by the team to be done in the current iteration (named sprint).

Roles

Product Owner is responsible for the Product Backlog (PB), its proper prioritisation and good shape. It is a client or its representative.

Scrum Master facilitates all meetings, teaches PO and the team Scrum rules and shields the team from interruptions. Also enforces compliance with the rules (for example to not show on demo something that is not really done).

Team is self-organising, cross-functional group that takes the stories and produces working software every sprint.

The cycle

The sprint takes from 1 to 4 weeks. It begins with Sprint Planning meeting consisting of two parts: on first, PO explains the stories and if they are not estimated, the team do the estimation, PO may reorder the PB seeing estimates. This first part ends with the team selecting the stories to be done on sprint. This takes no more than 2-4 hours. On the second part of the meeting the team breaks the stories in to smaller tasks. It also should take longer than 2-4 hours.

On every day of the sprint there is a Daily Scrum meeting taking max 15 minutes on which every team member answer three questions: - What did he do yesterday? - What is going to do today? - Does he have any problems?

Client or his representative is more or less available for questions or explanations within sprint, because some things may need clarification. In general you do not want to create the document for something that can be shown or explained when talking.

The sprint ends with Review Meeting that takes no more than 4 hours. The meeting also consist two parts: on first, the teams shows what accomplished, but it is always only a done, working software (no presentations). The PO at this meeting can ask for changes etc. that are transformed into new stories. The second part is the retrospective when the team is inspecting his behaviour and thinks about ways to improve itself.

That is all folks!

Simple, isn't it? You may start thinking if it works because of its simplicity. Yes, exactly because of the simplicity. Do you really think that 200 pages of rules work better? I do not think so. Also because everything is simple and not constrained there is much room for the inspect & adapt.

In the next entry I'll start to explain on some practical examples why it works. I'll also try to show some examples of waterfall thinking that stops you from being agile. Waterfall thinking is much harder to stop than waterfall process, so it is many times lurking in your mind any you may not even be aware of it.