How to be Agile
with SCRUM
Created by Sebastian Witowski
Welcome. In this presentation, I will talk about the Agile methodology called SCRUM.
It's a way of working on projects that is getting more and more popular nowadays.
I will explain why it's so popular, describe how it works and hopefully, convince those of you who are not using it, to give it a try.
IT Projects
I will be focusing mostly on the IT project as this is my main area of expertize, but you can easily take these examples to different areas.
Take a look at this report presented by the international IT research company called the Strandish Group.
They have analyzed projects in dozens of companies. As you can see, usually only a third of the projects is being finished on time and within the budget constrains.
Almost half of the time, companies have problems with delivering the project on time or within budget or even what they deliver is simply missing functionalities.
Also, a lot of projects were just canceled, costing the companies a lot of money for something that was never delivered.
The waterfall model
One of the reasons behind it is the wrong development process.
In many places, it's still very common to stick to the so called, waterfall model.
In the waterfall model, client first defines the requirements and then the design is created and implemented. After that, client verifies the project and it goes into maintenance phase.
Waterfall model comes from the times, where most projects were not related to the IT, for examples from the manufacturing or the construction industry.
In that scenario it makes perfect sense - if you want to have a house you first tell what kind of house you want, you approve the design and then the house is built. You can't say in the middle of the construction process: "Hmm, build the first 2 floors and then I will see if I want to have more" or "No, no, I actually don't need to have that basement".
Waterfall -the good parts
- Well defined requirements
- Defined start and end point
Of course, the waterfall model has advantages. It enforces the discipline - your client needs to define all requirements up front - before any line of code is even written. Based on those requirements, you can define the end date of the project. This is good for you - you deliver exactly what the client asked you and then you get the money. Unfortunately, with this approach there is a high chance that the next time, your client will select a different company that allows for more flexibility.
Waterfall - the bad parts
- Very little place for feedback and adjustments
- Expensive redesign, reimplementation, retesting
Yes, the lack of flexibility is the main problem of the waterfall model.
Once you commit to a design, there is no turning back. After the design is accepted, there is no more place for the feedback or the adjustments.
And in most cases, client doesn't know ALL his requirements at the beginning of the project which leads to expensive redesign, reimplementation and retesting.
Agile Manifesto
Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan
[Source: http://agilemanifesto.org]
This lack of flexibility encouraged people to try different approaches that in turn gave birth to the Agile Manifesto in 2001.
According to the manifesto, you should prefer the interactions than following the strict rules.
You should focus on creating working software and not the documentation.
Customer should be involved during the whole creation process and he should be able to ask for changes.
Agile ? But which ?
As you can see, there are many different agile methodologies. They all follow the agile manifesto, but each of them has a different production process, different rules and roles.
SCRUM
- A team commits to delivering working software in 30 days or less
- A time is scheduled to show that (the Sprint)
- The team meets daily for the updates
- The team offers their work for inspection and plans the next cycle
Today, I will focus on probably the most popular one - the SCRUM methodology.
In a nutshell, a team of developers commits to deliver working software in 30 days.
And by 'working software' I don't mean the complete product - it can be a part of the final product, but it has to be well defined before you start.
Then, the team is working on that product during the time period called sprint.
During the sprint, the whole team is meeting every day to say what each person did yesterday and plan the work for next 24 hours.
At the end of the sprint, the final product is presented to the stakeholders and the cycle starts again.
There are three main rules that you have to keep in mind during the sprint.
The first one - transparency - means that everyone knows what is going on. All the tasks for the sprint are visible not only to the developers that are working on them but also to the client, so he can provide feedback.
The second one - inspection - means that SCRUM users must frequently inspect the list of tasks so they make sure they are still progressing towards the goal of the sprint. The main tool for that is the daily meeting where everyone are reporting what they were doing yesterday and what they will do today. It sounds a bit scary to have a meeting every day, but don't worry, this one lasts only 15 minutes and it can be even performed when the team meets for the morning coffee.
The third leg of SCRUM - adaptation - is a combination of the previous two. If the client sees that the sprint starts shifting in the wrong direction or he wants to adjust the requirements, it's perfectly fine to do this in the middle of the sprint. This is the main difference from the waterfall model - there is always time for changes.
Ok, enough theory. How does a typical Sprint looks like in practice ?
Let's first explain the roles in the sprint.
The first one - stakeholder is obvious - it's your client that want you to do stuff.
Stakeholders don't participate in the sprint until the very end - they just come to see the results.
Stakeholders however, delegate one representative called a product owner, who will be actively involved in the whole sprint.
Product owner should be a person who understands the needs of stakeholders and who can decide on the priority of all issues.
He will be the person responsible for any profit or loss of the product.
There can be multiple stakeholders, but there can be only one product owner.
Next, there is the development team, which, as you can guess, are the people that will do all the work during the Sprint.
Last but not least, we have a SCRUM master.
He manages the process of SCRUM and makes sure that the values, practices and rules or SCRUM are being followed.
He makes sure that the developers team stays productive and there are no blockers.
He protects the team from the outside distractions.
So, he is responsible for following the SCRUM rules, but he can't be held responsible for the outcome of the sprint.
SCRUM master should be a person who knows the theory of SCRUM methodology and usually it's someone from the development team.
Each Sprint starts with the "Sprint planning meeting".
During that meeting, product owner meets with development team and the scrum master and they all create a product backlog list.
It's simply a list of ALL the tasks that needs to be done one day or another. Usually, every team has this kind of list somewhere, otherwise it's impossible to keep track of what they are actually working on.
You go through all the tasks one by one and discuss if it's something that you want to do in the current sprint or not.
If yes, then you move this task to the "Sprint backlog".
After the Sprint backlog is selected, you can identify the "Increment". Increment is the goal of the sprint - so all the tasks selected to be done in the current sprint. It has to be something that you can measure and verify.
Usually some tasks are related, so you can identify the increment better than just 'do X, Y, Z'.
For example, if your Sprint backlog is: write tests for files X, Y, Z, you could identify your Increment as "have more than 90% of test coverage"
After the planning meeting, the sprint starts. Now, for next 2-4 weeks, developers will work on their tasks and meet every day for the daily SCRUM. During the daily SCRUM, developers will synchronize activities, create a plan for next 24 hours and assess the progress toward the Sprint Goal.
At the end of the Sprint, everyone meets for the Sprint Review meeting. During that meeting, the Increment is presented to the stakeholders and the stakeholders are giving the feedback.
Based on this feedback, the Product Backlog is adapted for the next Sprint.
Right after the Review meeting, there is a Retrospective meeting in which, stakeholders are no longer involved. During that meeting, the team is evaluating the Sprint itself - what went well, what went wrong, what could be improved ?
SCRUM at CDS
- No backlog and inaccurate estimates
- Created backlog
- Grouped tasks
- Planned next sprints
- Correct estimates
- Happy users
But why did we decide to use SCRUM methodology instead of the waterfall model that worked so well for the past 10 years ?
Well, exactly for the same reasons I have mentioned at the beginning.
First of all, we didn't even have a clear backlog - most of the feature requests were in the form of e-mails or tickets in different ticketing systems.
Second, we were unable to correctly estimate the time require for some features to be released because we didn't know what other urgent requests will pop up in the meantime.
So, first, we started creating backlog - at the beginning it contained literally hundreds of requests.
Thanks to the clear backlog, we were able to group tasks together as we realized that it's faster to solve related tasks than to jump from one task to another.
After we have grouped the tasks, we were able to plan the next few sprints and sometimes shuffle them if there were urgent things pilling up.
Being able to plan next sprint allowed us to estimate when each new feature request could be implemented and as we found out, our estimations were now more accurate than before.
And that eventually made our users happy.
The benefits
- Cleaning the backlog
- Easier planning for the future
- Everyone learns
- Easy inspection
So what benefits we got from using SCRUM methodology ?
As I already mentioned, we managed to gather all the backlog in one place and slowly start cleaning it.
After a few sprints, we were able to estimate more accurately the time to deliver features.
Since each sprint was related to a specific topic, everyone had to take some tasks from that topic and this way, everyone was learning new things.
This was a huge improvements from the previous workflow, where people were specializing in parts of the system.
Now, everyone has at least basic knowledge of every part of the system.
And the daily meetings really encourage the communication in the team. Sometimes, it's had to focus during those long weekly meetings, especially if they are uninteresting to you, but if you are meeting for 15 minutes every day, it's very easy to keep track of what is going on.
You can tailor SCRUM to your needs
If you can, then I would really recommend you to try the SCRUM methodology.
You don't necessarily need to follow it by the book, for example we have adjusted the methodology to our needs:
- Instead of constant sprinting, we sometimes take a week of break if each of us get too many tasks that need to be finished (tasks not related to the sprints, that are hard to assign to someone else - for examples support tickets)
- Also, the person that is on support for the given week is only partially involved in the Sprint
Other methodologies (Kanban)
- No defined time periods
- Optimize the 'production line'
- Minimizing the parallel "work-in-progress" tasks
If you decide that SCRUM is not for you, there are other Agile methodologies that might be more suitable in your work environment.
For example, in Kanban you have no time periods like in Sprint. Instead, you are trying to optimize the logistical chain from a production point of view.
You try to produce enough resources to fulfill the needs of clients but not more.
You also monitor the various stages of different tasks and try to minimize the amount of tasks that are in progress at the same time.
Summary
- Try it, it's worth it !
- Modify it if you need.
- Take a CERN course to learn more
To sum up, if you have chance to apply the Agile methodology do your work and your are still stuck in the old waterfall model, try to convince your team to give it a try. It has a big chance of improving the quality of your work and making it more organized.
You don't need to follow any methodology by the book. If somethings gets in your way, just remove it. Also, fell free to borrow from other methodologies, if you find something useful.
If you want to learn more, there are Agile courses organized by CERN, you might want to check them out.
Questions ?
Comments ?
Thank you, any questions or comments ?
1
How to be Agile
with SCRUM
Created by Sebastian Witowski
Welcome. In this presentation, I will talk about the Agile methodology called SCRUM.
It's a way of working on projects that is getting more and more popular nowadays.
I will explain why it's so popular, describe how it works and hopefully, convince those of you who are not using it, to give it a try.
