Introduction
Scrum is a framework (not a process) which is to be used for product development. Although it has become quite famous for software development, it can be applied to any product being developed, which requires intellectual work. Mass production elements do not require Scrum. This article, however, will focus on Scrum and its appliances to software development.
As stated in the previous paragraph, Scrum is a framework, which means the following: Scrum tells you what to do, but not how to do it. Here is the strength and the weakness, at the same time, of this framework. You will notice that the framework is very easy to understand, really, it is straightforward. The caveat lays on how to implement it correctly. Whenever a team tries to implement Scrum, they notice how hard it is to follow it to the letter, basically due to two factors: firstly, intense people interaction and discussion is essential, and this is something that usually is not trivial, especially among software developers; secondly: Scrum throws in your face the problems you are facing, not giving you a clue how to solve it.
Waterfall processes, such as CMM, are based strongly on documentation; the idea is to leave the development process as independent as possible from the people involved. Therefore, such processes were much easier to follow because you, the Team, is told exactly what to do. Scrum, takes the opposite approach: it focuses on people - they are the pillar of the development process. The is a great mindset change, in my point of view, because one of the core problems of CMM-like processes is that they completely ignore the people involved, which leads to enormous problems, such as: not enough documentation no matter how much you wrote it, lots of contradictions in what was written and what was coded, and so on.
As mentioned before, Scrum throws the problems at your face, giving you no solution for that. This is interesting because since paper-oriented processes hide these problems, especially when they were people related ones. Whenever Scrum throws you these matters at your face, you have two options: either recognize and face them or blame the methodology you are following, ignoring what is really in front of you. This usually is related, as mentioned, to people issues. Maybe members of the Team do not get along, maybe you have a client who is too hard to deal with, maybe the ScrumMaster or the Product Owner are not adequate.
Although hard to execute, Scrum has some advantages that make its usage really worth. It embraces change: this is something which is one of the biggest problems in waterfall processes. Whenever anything needs to be changed, a long analysis had to be made, documents modified, for at last, modifying the product itself. Moreover, change is not welcomed in these processes - it is always something to be avoided. Scrum on the the other hand, embraces change, it welcomes it. Scrum recognizes that in software development change in natural, it means that the product is being used.
Another advantage was something just discussed: the problems the framework shows you. Scrum is an excellent tool for diagnosing problems. It is truth that it does not tell you how to solve it, but sure it points you the issues to solve.
Iterative development and delivery is something pretty nice Scrum has as well. Instead of showing the product to the client when it is finished, in the Scrum framework the product is to be delivered constantly. With that, constant feedback is requested and the changes suggested are soon incorporated to the product.
Finally, although this was a long introduction, hopefully it has convinced you to keep reading this article in order to understand better how Scrum works. Next the Agile Manifesto is going to be discussed, so you can understand the pillars of Scrum. After that, a overview of the process will be presented. Continuing, a detailed explanation of each member of the framework will be given along with a detailed explanation of each part of the Sprint. Finally, the main artifacts and miscellaneous concepts will be explained and everything will be put together along with a final discussion.
Agile Manifesto
The Agile Manifesto has a set of principles that are followed by Scrum. Below are these principles and you will notice that a few of them have already been discussed in the introduction.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Although they are pretty self-explanatory, they will be discussed next.
The first one, "Individuals and interactions over processes and tools" was mentioned in the introduction. It states that the software development should have its focus on people rather than on tools and paperwork. This recognizes that people are the key for the success in a product, not the paperwork created or the tools used. In Scrum it can be observed throughout the framework. In the Review the idea is that the whole Team suggests and acts to improve the software development as a whole. In the Planning Meeting, the Team decides how to implement the software and decides whether it is possible to do the amount of work required for the Sprint.
"Working software over comprehensive documentation" defends the point that instead of a big amount of documents to analyze and describe the product, the focus should be much more on the product itself, on its development. It does not mean no documentation should be created, but only enough so the product can be built. In Scrum a deliverable and shippable product has to be delivered after every Spring, even the first one. If you wish to document something do so within the Spring and while the product is being developed. This certainly prioritizes the software over documentation.
"Customer collaboration over contract negotiation" states that, instead developing the product strictly based on a contract, it should be built based on the user constant feedback, so it can be more useful. Here is the recognition that the users do not know what they really want until they start using the software. After interacting with it, constant feedback is provided and the development is molded according to that. In Scrum, after every Sprint there a delivery so the final user can give constant feedback. This clearly makes the end user collaborate quite a lot with the product being developed. Note here that, a minimum scope can be define so the product soul, if I may call it, still exists. However, if is agreed, not even that is necessary.
Finally, "Responding to change over following a plan" talks about constant changing in the process being used - there is no fixed process being followed. For Scrum, in the Review Meetings, the process is discussed and improved. It is assumed that it is never something perfect - constant improvement is required. Thus, there is no final plan here, never.
Overview
Here is presented an overview of the whole process. Although you may not be familiar with all terminologies here, they will be better explained in later sections. The idea is to give you a general view of the process so when you read the next sections, you will have a better understanding on how each piece fits into the whole framework.
The picture above is the classic representation of the Scrum process. Firstly, the Product Backlog is defined, which is basically a list of features to be developed. For each Sprint the Product Owner selects a set of features to be developed which the team has to agree to do. This set of functionalities is called Sprint Backlog. After negotiating these features, the team has a Goal to achieve for the Sprint, which is basically the set of what was agreed. The meeting where the work for the Sprint is presented, the Team and the Product Owner agrees on the Goal, and where the features are broken into tasks to be developed, is called Planning meeting (How exactly the Team will break and develop the tasks are not part of the Scrum framework).
After the Planning Meeting the Sprint starts with the Team members developing the tasks for the Sprint. The Sprint duration varies from Team to Team and there is no fixed rule for determine that. The only thing that is highly advisable is for the Sprint to have the same duration, as long as it is enough. During the Sprint, there is the so-called Daily Meeting, which is a 15-minute meeting where the Team provides their tasks status and raises a flag in case there is any impediment. Meanwhile, the ScrumMaster is responsible for solving any impediments that may arise.
In the end of each Sprint, the features are presented to the Product Owner who has to approve or not what was shown, in the meeting called Review. Finally, in the Retrospective meeting the Team, ScrumMaster and Product Owner discuss what should be improved in the overall process.
Roles
ScrumMaster
The ScrumMaster is responsible for making sure the team understands and follow the Scrum framework. He or she is also responsible to resolve all impediments which may arise. See that this is no easy task.
The ScrumMaster has to explain, and most importantly, convince the team to use the Scrum process, without having any authority over them. Of course, the team knows that they have to follow the framework, but to do so accordingly they have to follow the ScrumMaster leadership, which is imposed solely based on argumentation, something hard to do. Note is natural that the ScrumMaster helps the Team improve the development process and appliance of the Scrum framework by the Team, in the Review Meetings.
Even harder is to remove impediments. It means that anything that is avoiding the team or the Product Owner to have their work done, is to be sorted out by the ScrumMaster. Note that this could be an issue with the client, with third-party-providers, other teams or even with managers. Therefore, the ScrumMaster, would have to be quite skilled in order to know how to deal with this variety of areas effectively. This probably is the harder task a ScrumMaster can have because he or she may have to deal with situations which he or she have no power to intervene thus will have to be quite creative on how to solve the matter.
Product Owner
The Product Owner represents the voice of the client. It means, he or she knows exactly what the client wants for the product to be developed. In a perfect world, the Product Owner would be the client him or herself, however in real life this is almost impossible.
The Product Owner is fully aware of the features to be developed, the priority that each one has in the product and must be able to answer all questions regarding the product; after all, he or she represents the client.
The Product Owner is responsible for maintaining the so-called Product Backlog, which is a list of functionalities to be implemented. This list is ordered by priority. The way these features are described is up to the Product Owner to decide, meaning that the Scrum framework does not dictates how what it should be. Thus, it can be Requirements, Drawings, Use Cases or User Stories. Nowadays, the most common methodology to describe these functionalities in Scrum is User Stories.
The Product Owner is also responsible for deciding what are the features for each Sprint. This is to be negotiated with the Team, however the Product Owner is fully aware what needs to be implemented and needs to guarantee that everything is done accordingly.
In the end of each Sprint, the Review Meeting, the Product Owner approves or rejects the features implemented. He or she can also give suggestions for subsequent sprints based on what he or she has seen in the review.
Finally, the Product Owner is responsible for planning the releases. As he or she is fully aware of what the product needs to be, he or she is the natural choice for that task.
Although the Product Owner is the ultimate responsible for the product´s features, it does not mean that or she cannot discuss the product´s functionalities with the Team. On the contrary, it is highly recommended that the Product Owner gets as much feedback as possible from the Team, since they are the ones developing the product and they can give valuable suggestions.
Team
The team is a set of people who develops the product. There are responsible for designing, implementing, testing and fixing bugs of the product being built. One may argue they are the ones who get the job done.
It is obvious, but they do have to follow the Scrum process. Note how the two other members fit into the Team purpose.
The Product Owner feeds information to the Team about the product being developed. The Product Owner makes sure the Team is following the correct path and assures the quality in the final product is good (this has nothing to do with code, of course).
The ScrumMaster leads the Team to follow the Scrum framework as close as possible to its principles. The ScrumMaster also holds review meetings and help the Team improve the development process and the appliance of Scrum itself by the Team.
Sprint
Sprint is the basic unit of development. If you wish to add a new feature to the software, you will have to wait for the next Sprint. A Sprint encompasses the following procedures of software development: planning, developing the product, daily meetings, a review to show a demo and a retrospective to discuss what is going well and what can be improved.
After one Sprint is finished, the next one starts, until the product is finished. So, by dividing the development process in Sprints, a request for change is opened. Whenever the final user has a feedback to alter what was created, or even what will be developed, he or she can request it and it can be implemented in the next Sprint. Note how natural this is in this framework. There will be no hassle since no big analysis or not a lot of paperwork will have to be worked on. Of course, there may be room for analysis regarding the impact in the product and its code, but that is as far as it goes.
One of the hardest questions to answer is: "how long does the Sprint take?" This is a hard question because there is no definitive answer. Some Teams take one or two weeks, some Teams take one month. So, the point is, the Team has to experiment to see how long it is necessary. This sounds strange for someone who comes from more orthodox software methodologies, but Scrum is a lot about trial and error, because there is no correct and unique answer for everything, and this is a classic case of that: Sprint Size. Therefore, for a Team to find out how long a Sprint should take, the Team has to try several alternatives.
Now that you are aware of how the Sprint works, the next sections will describe in details each phase of the Scrum framework.
Planning Meeting
This where the Sprint begins. The Product Owner, selects a list of features to be developed from the Product Backlog. The ones which are to be developed here are stored in the so-called Sprint Backlog. The Product Owner, presents these functionalities and their priorities along with the Sprint's Goal (explained in details later) to the Team, who agrees or not to develop all these activities, reaching the presented Goal for the current Sprint.
Another important point regards the agreement of the Goal. The Team may believe that what is proposed is too aggressive and there will not be enough time to implement it. When this happens the Team must justify to the Product Owner their believes and they must reach a consensus of what a feasible Goal is. After reaching that, the second part of the Planning Meeting starts.
The Team then estimates the activities, usually Stories, to determine whether they are really able to do that. If not, they may call the Product Owner again and talk about the Goal again, reaching a new consensus.
Now it is a good time to talk about User Stories and estimates in points. Scrum does not dictate how the features are described nor how they should be estimated. In Scrum, usually User Stories are used to describe functionalities and Story Points are used for estimates. This article will use them as examples to describe the Scrum framework, but keep in mind any other strategy could be used.
Going back to the Planning Meeting, after estimates determined, the Team breaks down the activities (User Stories) in tasks which can be assignable to developers. Usually one developer is responsible for one task, but there is no problem in more than one developer to be involved in a single task. The idea here is for the whole time to be aware of what is to be developed, and most importantly, how it is going to be developed. In theory, any member of the Team could develop any of the discussed Tasks, even though this may not be true in real life. Anyway, the idea is that the whole Team is aware of what it is going on, and the whole Team knows as much as each member is able, about the code being developed.
After the Tasks are broken down, the Team starts to work.
Development
This is not exactly a phase, it is how the Team should behave during the Sprint development. After the tasks have been broken down and the whole Team is aware what is to be done, so the work starts.
In the Planning Meeting, when the features were presented to the Team, they were also prioritized. Therefore, the Team has to pick the tasks which have the higher priority. This, sometimes, can be very hard to accomplish, because it may feel natural for some members of the Team to work on activities they are more accustomed with, which are not in the top of the priority hierarchy. However, in Scrum, the idea is to finish the features which are more important first, so if anything is left, is something less important.
This is like the metaphor of several rooms to be cleaned in a hotel. Suppose you have nine rooms to be cleaned and five people to do the job. The schedule is very tight so it may not be done. It sounds more natural for each person to start working in each room. However, if the time is not enough and no one can finish in time, there will be no room available for guests. On the other hand, if you put, the five workers in a single room, and when they are finished, they move to the next one, you will also not get all rooms, cleaned, however you will probably have two or three rooms cleaned up, which is much better than none.
This is the idea of Scrum, have all the Team, working on a single feature or User Story, and when they are finished, move to the next one. Of course, there may be the case where it is impossible to have everybody working on the same task, because there is simply too many people. In this case, a set of people should work on the task with highest priority and the rest of the Team should work on the Task with second highest priority.
After finishing the activity with highest priority, the Team moves to the next one, and so on.
The Product Owner must be available for the Team to answer questions, give suggestions and have all their doubts and problems solved, when it comes to requirements. Whenever there is a process issue or impediments, the Team should contact the ScrumMaster, who is responsible for helping them in these matters.
Everyday the Team meets in the so-called Daily Meeting to give their status and ask for help. The idea is that everyone becomes aware of the development status. Problems that may arise from this meeting should be discussed later, in separate meetings.
In the end of the Sprint, the Team presents the developed features to the Product Owner, who approves or rejects them. Finally, the Team discusses what went fine, what went bad, and could be improved in the Sprint so the development process is constantly being perfected.
Daily Meeting
Daily Meeting, as its name says, a meeting to be done everyday, where each member of the Team has to answer the following questions:
- From the last Daily Meeting to this one, what have I done?
- What do I plan to do until the next Daily Meeting?
- Do I have any sort of impediment (any kind at all)?
By answering these simple questions, it is possible to determine a number of things. Firstly, if a Team member is in the same status he or she was in the last meeting, it means he or she is stuck in a problem therefore in need for help. The third question is a more obvious manner to identify whether a person is having troubles. In case a problem is identified, the ScrumMaster should help the person sorting it out, either by asking someone else to help, or using any other means necessary. This is to be done in another meeting because the Daily Meeting is only used for status purposes.
It is very important to emphasize that this meeting must take at most 15 minutes. If it takes more, it means that is not being conducted correctly. This could be because other things are being discussed which are out of the scope, there are too many members in the Team, people are talking trivialities, and so on. Therefore, be prepared to discuss in the Retrospective Meetings why the Daily Meetings are taking so long, because this is something that happens quite often with new Scrum Teams.
Review Meeting
Review Meeting is where the Team presents to the Product Owner what was developed, via a demo. The Product Owner, then, evaluates whether he or she approves or rejects what was developed. Note that he or she can approve the product even it has bugs. As long as the product is something deliverable, the Product Owner can accept it and leave corrections for later Sprints.
The final client may be present in Review Meetings. This is quite advisable because feedback will be instantly given. It is much easier for the Team to understand the client's needs and it brings the Team much close to the client. This relationship, is usually given little importance, but everyone who had the experience of interacting with the client, knows how it contributes positively to the product development.
Note that Sprints may fail, either because the Product Owner does not like what was shown or because it was not enough time to develop everything which was agreed upon. This may sound strange, but it is common to occur when a project is starting because the Team is not aware how much time is needed to develop a set of functionalities. Therefore, when this happens, the Team must be aware if the failure and make its best to improve in the next Sprint. This becomes a problem is all Sprints fail and nothing relevant is done to correct this matter.
After the Review Meeting the Retrospective one takes place, which is described next.
Retrospective Meeting
This is where heated discussions sometimes take place. Team members along with the ScrumMaster discusses how to improve the current development process. The Product Owner may be present, but his or her presence is not mandatory. Again, three questions are to be answered by each member:
- What have we improved from our last Sprint? Meaning, what should we keep doing?
- What can we improve for the next ones?
- What should we stop doing?
By answering these three basic questions, the Team has a sense of what to do to improve the software development process. In this meeting sometimes a lot of accusations and blaming take place, which should be controlled by the ScrumMaster, so be careful.
Here lays the basis for continuous improvement. If this meeting is successfully executed, the Team will always be improving its development process. If they have in mind that there are always things to be improved, this meeting is a never-ending need; although perfection is impossible, significant improvements will be achieved throughout the product development.
Artifacts
Here the artifacts mentioned throughout this article will be presented, and a few which were not.
Product Backlog
The Product Backlog is is a list of features sorted by priority to be developed for the software. The Product Owner is responsible for creating and maintaining this document. Note that, as the final user gives feedback throughout the Sprints, this list will change in terms of content and priority. The final user may notice that he or she wants to give more priority to certain tasks, have different features or even discard ones that at first were though necessary but as the final user experience the product, he or she realizes they are not needed.
The features with highest priority that are in the Product Backlog are the ones which go to the Sprint Backlog (discussed in the next section).
Usually, features in the Product and Sprint Backlog are described as User Stories, but they could be anything. Also, the higher the priority of the feature, the more detailed is its description. Note that, if a feature has low priority, there is no need to describe it in much detail because it may even not be implemented.
Finally, note that the Product Backlog is a live document. Every end of Sprint, with the final user's input, there may be some changes in this document.
Sprint Backlog
This document holds a list of features - User Stories, to be developed in a certain Sprint, when the Team and the Product Owner agree upon which features will be implemented for the current Sprint. These features are put in a ordered list, which is called Sprint Backlog. This list will be attacked and implemented by the Team, finishing the ones with higher priorities, in that order.
Note that the Sprint Backlog also contains the Tasks broken down by the Team. So, it can fully describe what is to be developed. Estimates and completion percentage may also be added to this document so the progress can be easily visualized.
Burn Down Chart
A common tool to see the Sprint progress is the so-called Burn Down Chart. This chart shows how the Team is doing related to the Goal, based on the average development speed, extracted from previous Sprints.
The picture above depicts a Burn Down Chart. The blue line shows how the Team is doing in terms of User Histories being developed whereas the green one shows what is expected, meaning the Speed based on previous Sprints.
The Speed was not discussed previously, so here is what it means. For each Sprint, the User Stories are estimated. Based on that, a velocity can be measured, which is the the amount of points of completed User Stories divided by the number of Sprint's days. This measure provides what is to be developed each day of the Sprint (Velocity). The more Sprints there are, the more accurate is that measure because for each Sprint we can make the Sprint Speed more precise. More of that will be discussed in "Estimates of User Stories".
Miscellaneous
Here will be discussed several elements not touch previously, but are quite relevant for the Scrum subject.
Definition of Ready
Definition of ready gathers all conditions necessary for a User Story to be developed in the current Sprint. In order words, for a User Story to be considered ready it must meet a set of conditions which state it is ready to be developed. These conditions are to be defined among the Team, the ScrumMaster and the Product Owner. Here are a few examples of conditions (again, they are not mandatory and they must adhere to the project's necessity):
- There must be a description of how to test the User Story.
- A member of the Team should read the User Story and fully understand it.
- The Concept of Done (next chapter) must be defined for the User Story.
There are a few advantages of enforcing the policy of only implementing a User Story it is considered Ready. Firstly, it is avoided that User Stories start being developed, and a few days later stopped during the Sprint because information is needed in order to complete it. Note that this makes the Team lose time, and it increases dramatically the chances of the Sprint to fail. Secondly, the Team has the empowerment to reject a User Story in case it is not ready. This forces the Product Owner to only push User Stories that are indeed ready, and again the Team does not have its time wasted.
Concept of Done
Concept of done is the definition of what is necessary for a User Story to be fully implemented. This is very important because the Team must reach a consensus for that, otherwise one may believe a User Story is ready when is implemented and other may believe a User Story is finished when it is fully implemented, the code reviewed and fully tested by other developer.
Note that when this is correctly defined and the whole Team follow it, User Stories start to have a better standard and constant level of quality, since everybody understands the same thing about the readiness of a User Story implementation.
Also, and this is quite important, for a User Story to be ready it must be deliverable to the end user. So, it is crucial that every good practice the Team believes is applicable, must be present in the Concept of Done.
Sprint Goal
A Goal is what the Team is to develop for the current Sprint; the Goal tells what will be added to the product in the current Sprint. The Team may even achieve the Goal without developing all activities. Moreover, the Goal can be achieved even with the product having bugs to be fixed. It is up to the Product Owner to decide whether or not the Goal has been achieved. Here are some examples of Goals:
- Add to the software the ability of creating and listing Users, Clients and Products.
- Make the client creation interface more user-friendly. Moreover, add product registration capability along with fixing CSS bugs in the management screen of the system.
Note here that that Goals are pretty straight forward and are feature-driven statements. They do represent features to be added to the software or something to be fixed.
Estimates in User Stores
In old-school waterfall processes, estimates were usually done in hours, days, weeks, and so on. User Stories estimates take another approach. They use comparison do to so. The idea behind this is the following: human beings are not so good at telling the exact size, or time of things. For instance, if you show a pen to someone, it would be very hard for he or she to tell the size of it. However, if you show someone a pen and a pencil, he or she will tell easily which one is bigger. Therefore, although human beings and not so good at giving absolute estimates, there are very skilled in comparing measures - it is easy to tell which is bigger. The same is true for features size. To tell how long it would take to create a User Registration UI may be difficult. But it is much easier to say that this UI would take much longer than to create a screen which simply shows a popup message.
So, for User Stories, you define a Story as a default one and set its value arbitrarily. The values should be Fibonacci ones: 1, 3, 5, 8, 13, 21, 34, 55,... infinite (Scrum Poker Cards have slightly different values, for approximation purposes). If you choose, for instance, 8 as a default Story, when it comes the time to estimate the next one, your question should be: is this task bigger or smaller than the default one? If it is bigger, how bigger? The double, quadruple? If it is the double, you should set as 13, if it is more or less half the size: 3. Note that Fibonacci does not give exact numbers for what is the double or half, which is good - this imperfection adjusts estimates to our own errors in estimates.
To do this sort of estimates, usually each member of the Team has the so-called Poker Cards - cards having Fibonacci numbers for estimates, as shown below. Whenever a Story is to be estimated, everyone shows what he or she believes is the correct estimate, without previously letting any other person know of it. If the guesses are equal, no discussion is needed, otherwise the Team reaches a consensus of what is the best estimate.
After estimating all Stores, if the Sprint is successful, you can use the calculus of the sum of Stories points divided by Sprint days to calculate the Sprint Speed or Velocity. You can do that for every Sprint and have the average of Sprint Velocities by calculating their Mean. This Speed or Velocity is the one used in the Burn Down Chart, explained before.
Wrapping up
Risking of sounding too repetitive, have a look on how Scrum looks, after you have read all its main concepts with details.
It all starts with the Product Owner gathering the information of a new product to be developed. He then creates the Product Backlog, holding User Stories of what is to be done, prioritized. He plans the Sprints and present the first one to the Team.
The Team and the Product Owner agrees on a Goal, in the Planning Meeting. After that, the Team estimates and breaks down the User Stories into Tasks. If the Team feels they are not able to reach the Goal after exploring the User Stories, they can review the Goal and negotiate with the Product Owner.
After that, the Team starts working on the Tasks, following the priorities of the User Stories. Everyday they have a meeting to follow up their status (Daily Meeting). If any problem arises during this meeting or any other time, the ScrumMaster will help the Team solve the problems. Also, the ScrumMaster helps the Team follow the Scrum framework and resolves any impediments that may come.
Finally, when in the end of the Sprint, with all Stories completed and ready for deployment, the Team demonstrates the product to the Product Owner, who can approve or reject the Sprint. Moreover, the final user can participate in the meeting and both, the final user and Product Owner can give feedback regarding the product. After that, a Review meeting takes place where the Team and the ScrumMaster discuss how to improve their software development process.
After that, another Sprint starts with the Planning meeting and everything is repeated.
Note that after each review, the Product Owner and the final user can change their minds for future sprints of what is relevant. Since they have a shippable software, they can start using it and be aware of their needs, so constant change is possible here.
Discussion
Now hopefully you have a much better understanding of Scrum. Obviously not all were covered here since there are entire books dedicated to Scrum.
Now, some relevant topic are discussed here.
Value to the end user
One of the main advantages of Scrum is that something valuable is delivered to the end user since the first Sprint. It means the final user can start using the product much early and therefore provide feedback soon enough so useless features are not developed. This is a fundamental advantage of Scrum over waterfall processes, which ended up providing the final user with many things he or she did not need.
The truth is, software users, even developers, are fully aware of their needs just when they start using the product. Only then can they understand what is relevant or not, what will be useful or not. Unfortunately human beings are not able to foresee they needs, and this is a fact that software developers have to accept. It is not possible to force final users to know what they will need before starting using the software. Thus, give them something to work with and they will tell you what they truly desire.
Constant change
Since the product is being reviewed every Sprint, there is the change for feedback constantly, allowing future requirements to be changed and re-prioritized. This is the magic behind Scrum for constant changing.
Constant process improvement
Review meetings allow constant revisits and improvements of the software development process. This goes from Scrum framework matters to pure software development issues, such as testing.
In my experience constant process improvements involves a lot of testing improvements. Firstly it is detected that tests are not so efficient. Later, manual testing is improved but since constant improvements are required, automated tests take place. If the Team as whole evolves, great improvement will be seen in the testing strategies, because Teams wants to test less with better quality. Automated and unit tests, although very tricky to implement successfully, are usually achieved by constant trial and error in their methods of implementation.
Code is something else that is improved overtime due to this characteristic of constant improvement. The Team realizes that if the code is poor, too many bugs appear and the maintenance of the product becomes harder. Therefore, effort to improve the code is done. Activities such as peer review and static code analysis do improve the overall code quality if correctly applied. Another measures such as mentoring for young developers also gives good results.
Client commitment
There is no point of using Scrum if the client does not give constant feedback. If the client is not involved in the product being created, Scrum is as good as any other waterfall process, because without the constant feedback and change allowed in Scrum, there is not much advantage in using Scrum.
It is common knowledge that sometimes is hard to have client commitment - they simply want they minds read and the software ready in the agreed deadline. However, it is the Product Owner duty to convince them otherwise.
Is Scrum for everyone?
Definitely not. Some people are too accustomed to their way of working, and it may be just fine. If what you are doing is working great there may be no reason at all to change the process. However, if you do observe that requirements are not being meet, the end product is not useful to the client, you may need to think more about using Scrum.
When NOT to use Scrum?
Scrum should not be used for small teams, up to three people. In this case, experience shows that the framework is not so useful for a few reasons. The members of the Team probably talk to each other all the time, making Daily Meetings pointless. Moreover, since the Team is quite small, improvements are easy to detect and usually are implemented as soon as identified. This does not mean, however, that good practices of Agile Development should not be used. It just means that the whole Scrum framework is not necessary.
Another situation where Scrum may not be necessary is when the scope of the product is well known and most certainly will not change. Moreover, the Team is proficient in the technology being used, thus no surprises may arise due to uncertainties. As one can observe, this scenario is quite rare. However, in this specific situation, no constant feedback, continuous process improvement or changes in prioritization are necessary because everything is well determined.
Is Scrum perfect, a golden bullet?
Absolutely not. As stated before, Scrum is very hard to put in practice due to people interaction issues that may arise. Moreover, organizations may not be open to all that is needed to follow Scrum.
Furthermore, Scrum does not solve the problem of long-term estimates. It is still very hard to estimate a long project with precision, which still is a problem for managers who need to sell a product.
How to start using Scrum?
My best advice is: do it step by step - in small projects, preferably with members that are used to Scrum. Maybe start with Sprint, Daily Meetings, and later add Reviews. These will most probably show problems in you project, such as communication and too many bugs with features which were already supposed to be ready. Moreover, the daily meetings probably will not be as short as they were supposed to be, so this is something to be fixed.
Later, introduce retrospective in which process will be improved. After the team is used to follow all Scrum ceremonies, probably the software itself will be better. However, you will notice that will be room for improvements, such as automated tests, better coding and fewer bugs.
Do not kid yourself: this will not be easy - the mindset change is huge and there are people who simply do not adapt to that. Thus, do not get frustrated and try hard to implement Scrum if you believe it is worth.
Also, keep in mind that not adopting the whole Scrum framework is not a bad thing. What is good is what works for you! Maybe in your company ownership works better for a person than for a Team. Or perhaps Sprints have to vary their time frames. The important thing is to use the tools provided by Scrum to improve you software development process and make you Team agile.
Are waterfall processes useless?
Absolutely not. Do not forget that waterfall processes, mainly the ones related CMM, have been around for a long time. Although they do present problems, vastly discussed here, many companies achieved great success with them, and quite a few still do. Also, remember that before them there was nothing to organize software development so they were a huge breakthrough because CMM-like processes provided methodologies for software development for the first time.
These methodologies allowed that requirements were thought and discussed before the software was implemented, instead of absolute chaos which was before that time. Moreover, and in my opinion, the greatest advantage: time for software architecture and design was allowed, which improved greatly software quality. Furthermore, design and architecture allowed the development and usage of design patters and good practices which again, contributed immensely to the software quality.
Besides that, testing strategies were developed, along with automated and unit testing, which again contributed for software improvement.
Hence, the message here is: do not despise old-school software methodologies because they provided us with great ideas for good software development. Moreover: architecture, automated testing, design patterns and so on, are still very much applicable with Agile methodologies.
See Agile methodologies as a step in the right direction for software development. Finally, make no mistake, there will come a time when we will start seeing the troubles of Agile methodologies and hopefully something better will come up. And then, after that, problems will arise and the cycle will continue forever.
References
Here are the references of the images used in this article. I would like thank the web sites which host them.
- Scrum Life-Cycle image: http://www.mountaingoatsoftware.com/agile/scrum/overview
- Scrum Product Backlog image: http://agilesoftwaredevelopment.com/scrum/simple-product-backlog
- Sprint Backlog image: http://www.mountaingoatsoftware.com/agile/scrum/sprint-backlog/
- Burn Down image: http://maymay.net/blog/2008/09/06/scrum-style-burn-down-chart-in-iwork-08-numbersapp/
- Scrum Planning Poker image: http://apps.microsoft.com/windows/pt-br/app/agile-planning-poker/fd84a52b-d0ce-478f-97e7-a82021a8fa6a
History
- First version.
- Another subject added to constant process improvement in the miscellaneous section was code quality.
- Added the discussion of the usefulness of waterfall processes.
- Added the discussion on how to start using Scrum.
- Added references to the images used in this article.
- Added the Definition of Ready.
- Replaced SCRUM by Scrum.
- Added "Where NOT to use Scrum?" section in the Discussion topic. Moreover, a few corrections throughout the text were made.
- Corrected a few spellings and grammar mistakes.
- Corrected grammar issues, provided the the generous contributor JPaula.
