Developing software in a team can be a hassle, so one should spend some time on researching different development methods. Scrum is a lightweight framework for project management, focusing on flexibility and openness.

I wrote the following to further improve my own understanding of the subject. Even if you have never done any programming, you can still take advantage of the methods and ways of thought described here.

“Simplicity -- the art of maximizing the amount of work not done -- is essential.”- the Agile Manifesto

I don't really want to write a lot about what Scrum is, because you could just as easily read the Wikipedia articleWikipedia - Scrum. I want to write what I think about Scrum, advantages and disadvantages. However, to follow this article I encourage you to watch the video below, since it will give you the jest of it in only 8 minutes. To further motive taking the time: many large computer-software companies use Scrum today. This is not a fad, but something that most experts believe has come to stay. At my workplace, we have recently started with Scrum, and we think it is very exiting.

Video by Hamid Shojaee, blog at ShipSoftwareOnTime.com.

Now you know the basics of Scrum; or actually: you know pretty much everything there is to know about Scrum theoryScrum Alliance. After watching this video an experienced software developer will have many unanswered questions. This is because Scrum is only a small piece of the puzzle. As with all puzzles, we need to lay down several pieces to get the whole picture. Some possible pieces, such as eXtreme Programming, will be discussed later in this article.

The advantages of Scrum

What are the effects of using Scrum? Remember that one of the requirements were quick, iterative releases. After each sprint the team will hold a sprint review, or demo. The clients are welcome to attend, to see how their product is progressing, and give comments to the developer team. This means that any changes to the specifications that the client makes, and they will always have some changes as the product evolves, can quickly be incorporated in the development process. The much used waterfall model is not as flexible to changes, and should therefore not be used to solve complex tasks.

“Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.”- the Agile Manifesto

Remember the daily scrum meeting? Each day the entire team meets, and each team member should answer three questions: What did you do yesterday?, what will you do today?, and are there any problems hindering your progress? This might seem stressful to many, having to prove that you are working and progressing, but in a good team this is not a problem. The positive effect of these meetings is transparency. Scrum encourages openness in every part of the process. Everyone are invited to follow daily meetings, though they should never interfere. The team is encouraged to let people know what they are doing by posting sprint retrospective summaries in their work environment. Any problem that one of the team members have will quickly be apparent to the other in the team during the daily meeting. Together, they can solve the problem faster.

There is no project leader in Scrum. The team should be completely self-organized. From the video you might remember the Scrum Master. While this role might sound like a project leader, the Scrum Master is there only to enforce the rules of Scrum, and help the team by removing any problems that might arise. He should act as a buffer between the team and any distracting influences. This is another very important point in Scrum: the team shall not be disturbed. Humans do not work well if they are continuously interrupted by customers or management.

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”- the Agile Manifesto

In fewer words, I feel that Scrum recognizes the typical problems that occur in a development process, and solves them by encouraging flexibility, openness and team work.

Agile development

While Scrum is an interesting subject, I want to take a step back and talk about the term Agile. You see, Scrum is one example of an Agile development methodologiesThe Agile Manifesto. What all Agile methodologies have in common is that they are based on iterative development, self-organized teams and that the specifications will change. Other words to describe agility can be flexibility, or adaptability. Quickly adapting to a change in the requirements is a key functions in a good development team.

How do you measure progress? In an Agile process, a piece of code that does not work is worth nothing at all. This is an important motivator for writing simple code, and addressing only the highest prioritized features first. At the end of an iteration, or sprint in Scrum, the team will deliver a piece of working software. Something that can be demonstrated to the stakeholders at the sprint review. What should the team do if they discover that there is no way they will be able to complete the assigned work before the end of the sprint? We never extend the length of the sprint, that is nonnegotiable. We should never decrease our coding quality to reach a goal, this will only hurt us later. The best way to finish all our tasks is to let some of them disappear. By disappear I mean: move them to a later sprint. The client might not get all the features they wanted this sprint, but at least they will get some that works. Remember: working software is the only measure of progress.

“Continuous attention to technical excellence and good design enhances agility.”- the Agile Manifesto

Extreme Programming

You might have noticed, that for a software development framework, Scrum did not say much about actual programming. As I said: you have to have several pieces of the puzzle in place to get the whole picture. This is where Extreme Programming (XP) enters. XP takes common sense to an extreme level. XP says: if testing is good, everyone will test all the time; if simplicity is good, we'll always leave the system with the simplest design that supports its current functionality. Imagine a control board with dials for the different practices, and you simply turn all the dials to 10. It turns out, that used correctly, XP will reduce risk, increase efficiency, and make development fun again. "Working more hours" does not necessarily mean "producing more output". Does this sound too good to be true? Perhaps, but while there is some criticism, for example that XP will only work with experienced developers, or that there will be a lack of documentation, many large developer companies use variations of XP today.

Lean

Lean software development features many similarities to Agile, and the two can be combined on many areas. Lean is built on some simple arguments, such as: eliminate waste (unused code, delays, bureaucracy), decide as late as possible, deliver as fast as possible, empower the team. This last point is very important in my opinion, and it is also important in Agile, Scrum and XP, as well as at my workplace.

“Think big, act small, fail fast; learn rapidly.”- Lean slogan

There you have some of the pieces in the puzzle in place. Taking the time to research these different development methodologies, and determining how they can work together is very important. There are many important lessons, but I think the most important is that people are not resources. People need more than just a list of tasks. People need motivation and a higher purpose to work for. We go to work to have fun, and to live. We need challenges and interaction with other people. This is also the first point in the Agile Manifesto, which reads:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.

That is, while there is value in the items on the right, we value the items on the left more.

I think that is a good conclusion to this article. Feel free to share your opinions on this matter, or ask questions.
Thank you.

Sources:
Scrum certification course.
Extreme Programming Explained - Kent Beck
Scrum and XP from the Trenches - Henrik Kniberg