Sprint Planning

Before the start of each sprint, a planning meeting is held to determine which features will be included in the sprint. Features come from the product backlog, which is prioritized by the product owner. The first time that this meeting occurs on a project the product backlog is created. You can think of this as sprint 0. The user stories chosen by the product owner to be included in the sprint are given to the team and through a tool called Planning Poker, they are resized to show the complexity of a story related to the other stories in group (this will be further discussed in the following section). Once the user stories are sized, they are turned into a number of tasks by the team and a time estimate on how long each task will take is determined. Once all this is done, the team will look at the entire list of submitted work for the sprint and decide if they can commit to completing the work by the end of the sprint. To decide this, the team does a five-finger vote to gauge individual members� opinions.
A team member simply raises his hand and through the number of fingers he is holding up, he displays what bests reflects his confidence level. A hand value of a �1� means that the team member is very doubtful of the proposal. A hand value of a �5� means the team member is extremely confident in the proposal. If no one holds up a value of a �1� or �2� then the team commits to that work for the sprint. If a value of �1� or �2� is shown, then the team discusses why that team member voted this way and adjusts the proposal accordingly.

Once the team commits to delivering the list of user stories and tasks within the sprint, the ScrumMaster enacts a change freeze to allow the team time to develop the user story as written before any changes can be made (to prevent scope creep). A sprint backlog is made up of all the user stories and tasks required to complete the sprint. All members of the team, including the ScrumMaster and the product owner, are involved in sprint planning meetings. Once the planning meeting is over, the team will get together without the product owner to discuss the high-level design of the system.


Planning Poker
Planning Poker is a game that encourages the team members to give their honest assessment of the complexity of a user story in relation to other stories. The tools required for the game are simple: you can use your hand or purchase a set Planning Poker cards to handle it.

To play this game, the product owner will read the user story and explain it to the team. The team is free to ask questions about the story. Once all the questions have been answered, the ScrumMaster will ask the team to privately determine a number that best represents the complexity of the story. Team members should not share their numbers with anyone in order to prevent inadvertently influencing other team members. Once the team members have each come up with a number, the ScrumMaster asks everyone to reveal their numbers. If all the team members decided the same number, that number is assigned to the user story and everyone moves on to the next one. If the numbers do not match, then the team members with the lowest number and the highest number are asked to explain why they selected the number that they did.

After the discussion, another round of poker is played with each member deciding on a number for the user story. This goes on until the team has unanimously settled on a number. On average, there will be no more than three rounds to agree on numbers. If at the end of three rounds there is still no consensus, however, we suggest that the ScrumMaster take the number in the middle and move on to the next user story.

Planning Poker accomplishes a conversation about a user story among the entire team. When this discussion occurs, �rabbit holes� and �gotchas� are usually avoided for the developer.


Daily Stand-Ups (Scrums)
During a sprint, the team, the ScrumMaster, and the product owner commit to meeting once daily in the same place and at the same time to discuss any issues that are preventing work from being done.
Meetings are held with everyone standing and time boxed to no longer than 15 minutes. Anyone interested is invited to attend these meetings; however, only the people classified as Pigs are allowed to speak at these meetings. At the meeting, each team member answers the following three questions:

� What have you done since yesterday?
� What are you planning to do today?
� Do you have any problems preventing you from accomplishing your goal? What progress has been made on existing impediments? Can the blockage be removed or must it be escalated? (The ScrumMaster looks after this area.)

To keep the meeting from becoming a long, drawn-out ordeal and to stay within the 15-minute time box, team members agree to meet after the meeting to further discuss any problems raised during the stand-up. The daily stand-up meetings are about team members committing to work and giving a platform to talk about issues early in the process.


Sprint Review
The sprint review is held at the end of the sprint. Its purpose is for the team to present the user stories it has completed during the sprint. The team, product owner, and ScrumMaster are present at the review, along with any interested parties�especially managers and customers. The review consists of an informal demo of the developed software as it stands at the end of the sprint. This product demo meeting is a chance for the customer to give feedback on the product to the team. This opportunity for the customer to see the product and provide feedback on it gives the customer the chance to see a return on investment that was not possible in the waterfall development process. The aim of the review is to show the actual working software; there should be no formal slide show presentation or masses of preparation for this review. This meeting aligns with the agile principle of satisfying the customer through early and continuous delivery of valuable software.


Sprint Retrospectives
Along with the sprint review, a sprint retrospective occurs at the end of a sprint. The sprint retrospective is an opportunity for the team to reflect on the sprint that was. This is the team�s chance to congratulate itself for the things that went well and discuss the things that went wrong. This is an open area where the team should feel free to discuss any issue that affects the team and their ability to deliver the product to the customer. During this meeting, the entire team is present, including the ScrumMaster and the product owner.

At the beginning of this meeting the ScrumMaster gives each person three stacks of Post-it notes in three colors. One color is designated to mean �things that went well during the sprint;� another color is designated to mean �things that were confusing during the sprint;� and the third color is designated to mean �things that were bad during the sprint.� The group is then given a time box (three to five minutes) to write down as many thoughts as they can about the sprint onto the Post-it notes. This is quiet time with everyone writing. Once the time is up, all the notes are gathered and put on a wall in the office room. The cards are then organized into similar categories. As time progresses on the product, you start to see some common categories that come up with every sprint.

The ScrumMaster reads the notes for each category and the team discusses them. If during the discussion an action item is presented, the ScrumMaster will write it down. Once the team has finished discussing the category, the ScrumMaster will move on to the next category. This is done until all the categories are discussed.

Toward the end of the meeting, the ScrumMaster reads all the action items that were presented and the team assigns members to be responsible for making sure the action items get addressed.

This is a good time for the team to try new ideas on how to fix problems. Do not be afraid to try something new with a sprint. If it does not work for the team, then throw it out and try something else. This meeting aligns with the agile principles of continuous improvement of practices and process, and owes much to Lean principles.

Source of Information : Pro Agile .NET Development with SCRUM

Scrum Artifacts

Scrum contains three main artifacts: product backlog, sprint backlog, and the burn-down chart. These artifacts are the by-products of the Scrum activities and help give direction and transparency to the team. In addition to these main artifacts, there is also an important secondary artifact: acceptance criteria.

Product Backlog
The product backlog is a list of all work remaining on a project that the team needs to complete. This list represents the customer�s product needs and wants. At the heart of this list is the user story, a key component of Scrum. It defines the increment of value to the customer that the developer is trying to deliver.

The product backlog is managed by the product owner, who is responsible for adding and removing user stories to and from the list. The product backlog is constantly prioritized by both the product owner and the customer. This constant prioritization is the key to Scrum. It ensures that the user stories that provide the greatest value to the customer are listed at the top of the product backlog. As user stories are added, they are compared to the user stories already on the list to see where they fit in value to the customer. During a sprint, user stories can be added to the product backlog, however, they will not be presented to the team until after the current sprint is completed.


User Stories
As mentioned earlier, the product backlog is nothing more that a prioritized list of user stories. A user story is a card that describes an increment of value to the customer. The user story is written for the developer in order to express the increment of value. The key to a good user story is that it is a vertical slice through the product. A horizontal slice is a feature that just touches one level, such as the database level or the UI (user interface) level. A vertical slice, on the other hand touches all the levels of the product. This is the smallest amount of work that touches all levels of the product and still provides value to the customer. By writing the user stories in a way that allows for vertical slicing, you can create basic functionality in the first user story and then easily add functionality to this feature as the customer needs it.

A way to make sure that a user story accomplishes the goal of being a vertical slice through the system is to make sure that it fits the INVEST acronym. INVEST2 stands for:
� Independent: The user story should be self contained, so that there is no inherent dependency on another story.
� Negotiable: User stories, up until they are a part of a sprint, can always be changed and rewritten.
� Valuable: A user story must deliver value to the end user.
� Estimable: You must always be able to estimate the size of a user story.
� Sized appropriately: User stories should not be so big as to become impossible to plan/task/prioritize with a degree of certainty.
� Testable: The user story or its related description must provide the necessary information to make test development possible.


Backlog Sizing
Sizing the product backlog is a measure of the pace at which the Scrum team can deliver items. People are not good at estimating work. We all know how terrible we are at accurately estimating how long something will take us to complete. How many times have we heard or said ourselves, �I am 80 percent complete on this. The remaining 20 percent will be done in an hour.� Yet two days later, it�s still not done. People are just naturally bad at estimating.

We may not be good on our estimates, but we are great at comparing things. For example, we are able to look at two cooking recipes and tell which one is more complex without being a professional chef. We can look at two items and see that one is larger than the other. Sizing the backlog is all about making decisions based on the complexity and amount of work, not on how long it will take to do the work. Sizing is not equal to estimating.

You may ask: how do I know how long something will take? Consider, as an example, a manager who wants to know how long it will take your team to produce a widget. You can derive the time estimate of completing the widget from the complexity of the widget. After your team has gone through a sprint, you can then look at that sprint and calculate how long it took the team to complete it. The team is only concerned with how complex a task is.

To perhaps better explain the idea of estimating the amount of work over the time to complete it, let�s compare it to painting your house. Let�s say you went to your local hardware store and bought several gallons of paint to paint your house. Then you call three contractors to give you an estimate on painting the house. The first contractor comes out and walks around the house, looks at all the buckets of paint you bought, and explains that he has old rusty ladders and handheld brushes and a scrawny kid to help him, so it will take him two days to do the job.

The second contractor comes out and walks around the house, looks at the buckets of paint, and explains that he just recently purchased new ladders and brushes, and the local high school varsity football team is working for him that weekend. With all those hands and the new equipment it will only take him a day to paint your house.

The third contractor comes out, walks around the house, looks at the paint, and explains that he owns some brand new mechanical paint sprayers and top-of-the-line machinery and he can have the house painted by lunch time.

What you see in this story are three contractors with three different time estimates on how long it will take to paint the house, but there is one thing that did not change throughout all of this and that is the size of the house and the amount of paint. No matter who was doing the job, the house size never changed, even though the time estimates did. The moral of the story is to do your best not to estimate the duration of the work, but instead estimate the amount of effort it will take to complete the work. Once you have the estimation of the amount of work, you can derive the duration to complete the work.


Sprint Backlog
The sprint backlog is a list of all work remaining in a sprint that needs to be done by the team. Think of the sprint backlog as a subset of the product backlog. Whereas the product backlog lists all the user stories remaining for the product, the sprint backlog contains all the user stories and tasks remaining for the sprint. Typically when a user story is chosen for a sprint, the team will split that user story into tasks. A task is a small chunk of the user story that can be done by any member on the team. Examples would be a task to implement the database changes needed for the user story, or a task to implement the UI for the user story. These tasks are displayed on a task board�also known as a Kanban3 board�that is visible to the entire organization. Other items can appear on this board as well, including information on set-up meetings to gather requirements, review checks, research, testing, design, and stages of coding.
Team members take a card from the board and during the sprint commit to doing the task the card describes. As team members work through tasks, other tasks may emerge and original estimates are adjusted. All members of the team are responsible for updating the Kanban board based on new information gained on the feature being worked on.

The sprint backlog supplies the information needed by the burn-down chart. At the end of each sprint, the sprint backlog is emptied. Any remaining items on the backlog are pushed back to the product backlog, where they are reprioritized against user stories currently in the product backlog, in addition to any new user stories that were added during the sprint.


Burn-down chart
A burn-down chart is a visual way to track how the sprint is progressing. The chart graphically shows the amount of remaining work on any given day of the sprint. It is usually displayed in a public area where anyone can see it. This aids the communication among team members and anyone else in the organization. This chart can also act as an early indicator that there is a problem in the sprint and the team may not be able to fulfill the commitment.


Acceptance Criteria
Although product backlog, sprint backlog, and the burn-down chart are the primary parts of Scrum, acceptance criteria is a very important secondary artifact in the Scrum process. Without good acceptance criteria a project is doomed to fail.

Acceptance criteria is essentially a clarification of the story. It gives the developer a set of steps that must be completed before the story can be considered done. The acceptance criteria are created by the product owner with the help of the customer. It sets the expectation of the user story. With this in place, a developer has a great starting point in which to write automated tests or even use test-driven development (TDD). In this way, the developer is creating something that the customer needs and wants with the understanding of how the customer will use it.

Another benefit of acceptance criteria appears when a feature cannot be completed in a sprint and needs to be spread out across sprints. Then the team can use the acceptance criteria as a tool to see where the user story could be broken into smaller pieces that still provide value to the customer, but can be completed in a sprint.
Source of Information : Pro Agile .NET Development with SCRUM

Scrum Roles

Scrum makes a strong distinction between the people committed to the project and those that are just interested in it. The most famous way of explaining this concept is via the fable of the pig and the chicken.
A pig and a chicken are walking down a road. The chicken looks at the pig and says, �Hey, why don�t we open a restaurant?� The pig looks back at the chicken and says, �Good idea, what do you want to call it?� The chicken thinks about it and says, �Why don�t we call it �Ham and Eggs�?�

�I don�t think so,� says the pig, �I�d be committed, but you�d only be involved.�

The �Pigs� are the people who are committed to the project. They are the ones that handle the creating, testing, and deploying of the project. The �Chickens,� on the other hand, are less committed. They are the stakeholders and/or interested parties who benefit from the project, but are not responsible for delivering it. Input from people classified as Chickens on the project should be taken into consideration; however it should not prevent the team from delivering the project.

Scrum promotes the support of the Pigs, but values and takes into account the views of the Chickens.


Pig Roles
The following are the three Pig roles that make up a Scrum team:
� ScrumMaster
� Product owner
� Delivery team


ScrumMaster
If the team is the engine of a Scrum project, then you can think of the ScrumMaster as the oil that keeps the engine running. The ScrumMaster is responsible for ensuring that the Scrum process is understood and followed. A ScrumMaster facilitates the team meetings and removes any blockages that the team may have in the course of the doing their work. He ensures that there are no obstacles keeping the team from achieving their goals and also isolates the team from outside distractions, all of which ensures focus is kept on the job at hand.

The ScrumMaster also liaises with different parts of the team, from product owners to testers and business stakeholders, ensuring that all members of the team are productive and share the common goal of delivering the sprint. Don�t liken the ScrumMaster position to that of a traditional project manager because the role is much more than that.

The key characteristic of a ScrumMaster is to be a �servant leader.� A ScrumMaster is not the boss of the team, but is there to help the team achieve what it needs to accomplish in the sprint. The ScrumMaster is there to help the team align the work in order to deliver value to the customer. A ScrumMaster is the team coach. He facilitates the decision-making aspects within a team. He is the point person for the team to those outside the group, and thus needs to be a top-notch communicator. When issues arise among a team, it is up to the ScrumMaster to manage that conflict and get the team back on track.

There are times, however, when the ScrumMaster stops being the servant leader and starts becoming a dictator. Since a key responsibility of the ScrumMaster is to ensure that the practices of Scrum are being followed as a team, any issue or attack against the framework should be handled by the ScrumMaster. Hopefully this is something that rarely happens.


Product Owner
A product (or project) owner represents the customer and is responsible for maximizing the value of the work that the team produces. The product owner meets with the customers to determine their wants and needs, and prioritizes those items so that the team is always working on the items of highest customer value. A product owner manages the product backlog and is the only person who can prioritize the user stories for a sprint; all features are developed for her and she is responsible for the sign-off of sprint deliverables. The product owner�s responsibilities change from being classified as a �Pig� before and after a sprint to being a �Chicken� during a sprint. The product owner role is also vital in that this person is the customer�s representative to the team. A product owner is similar to a ScrumMaster, but the main difference is the nature of the roles: the ScrumMaster is looking after the team�s best interest during a sprint while the product owner is looking after the customer�s best interest during the sprint.

In a Scrum team, the product owner is the one role that cannot be miscast. A product owner who is unable to accurately portray the customer�s wants and needs will result in failure. The product owner is key to delivering a product that brings value to the customer and success to the team.


Delivery Team
The delivery team is the group of people responsible for actually delivering the product. The team usually consists of two to ten people and includes a combination of programmers, testers, front-end designers, and members from any other required disciplines. The team works on each sprint to move the user story and related tasks through the different stages on the Kanban board until completion. The key characteristic of a Scrum delivery team is that it is a self-organizing unit. There is no one leader; everyone decides as a group what they can commit to each sprint. Team members also decide what tools they need to be successful for the project. This level of autonomy was unheard of in a waterfall method.

Delivery teams are designed to optimize flexibility and productivity. They are cross functional in that each member of the team should know all aspects of the product to varying degrees. Each individual on the team is not an expert at everything in the application, but each is a generalist in everything and an expert on a few aspects of the product.

The delivery team, along with the ScrumMaster and product owner, work together to complete the user stories and successfully accomplish each sprint. The ScrumMaster is geared to look after the team�s interests and the product owner is geared to look after the customer�s interests. With those two roles in place, the team does can concentrate on creating the application that the customer wants.


Chicken Roles
The people classified in the Chicken roles vary, ranging from business managers and directors to stakeholders such as customers, vendors, and sponsors. The Chickens are not actively involved in the development of the project; rather they are an interested party. Ultimately, the project is developed for these people, so their views are important and must be taken into account, but not at the expense of the development. This is why the ScrumMaster liaises between other people and the team and makes sure that these interested other people provide the resources that the team needs to get the job done, but don�t act as a distraction. Chicken roles are only involved in the process during sprint reviews, when feedback from stakeholders and other interested parties is of high value.

Because Chicken roles typically enjoy higher salaries in an organization they are not usually called chickens! Instead, they are told the pig and chicken story and then invited (and actively encouraged) to attend the Scrum meetings from time to time. Generally they do so and are very happy to observe and hear firsthand about what is going on.

Source of Information : Pro Agile .NET Development with SCRUM

Plan-Driven vs. Value-Driven Methods

When looking at the differences between the Waterfall method and the Agile method you need to look at the core behind each method. One method is driven by the plan that was created at the beginning of the project and the other method is driven by the value that you give the customer.

Waterfall Method (Plan Driven)
The waterfall method can be thought of as a plan-driven method of software development. In the past, this method of development was used by many�not because it was the best way to develop software, but because it was the only method known.

A project that used the waterfall method involved a large amount of risk, mainly because everything was done at the beginning of the project. All the requirements gathering, and discovery and scope definition was completed before the first line of code was ever written. Customers had to know up front everything that they needed or wanted the system to do. At times customers did not know exactly what they wanted, but yet, they had to define every last detail of their needs; and once they defined the details, they could not change them�even if they later realized that their needs had changed.

This approach destined the project for failure before it even began. The entire process led to problems that were hidden until toward the end of a project, simply because the customer had not considered every little detail, and there was no way make changes as the need arose. Sometimes it was too expensive to make a change. Scope creep was rampant in these kinds of projects; developers didn�t understand the problem that the customer was trying to solve�and the customer didn�t either.

Plan-driven development could be like a hoop jumping process: you started at discovery and once you jumped through that hoop, it was on to the requirements-gathering hoop, and from there you went on to the design hoop. You could not jump through one hoop until you had jumped through the previous hoop, and once you were through a hoop it was near impossible to go back to a previous hoop if the need arose. There was no allowance to do a little bit of everything and then pause to make sure you were still on the right path. The waterfall process did not foster an environment where developers could go to a customer and say, �I would like to show you what I am working on to make sure it is what you want.�

Usually the big issues would surface toward the end of a project, which was rather late in the process. This led to many development teams being behind on their projects. When teams got behind on a project, they would just throw more bodies at the project, with the hope that the more people on the project, the faster it would get done. That rarely happened. Most of the time the project would remain behind schedule, so the team had to cut the scope, cut testing, or both.


Scrum Method (Value Driven)
Scrum is considered a value-driven method for software development. Scrum is a dramatic change over the waterfall method for a number of reasons. Instead of first gathering all the requirements needed for every feature of the project, completing all the designs based on these requirements, and then coding the application based upon these up-front designs, Scrum looks at doing iterative, incremental development.

Scrum is all about taking small passes at a problem and reassessing that problem after each pass. Scrum is all about small:
� Small time blocks called sprints
� Small features
� Small teams

Small time blocks are how the team works on a solution for the customer. Each sprint can be looked at as a mini waterfall project. This is because in every sprint you are doing everything you would normally do in a waterfall project, except you are doing it on a smaller scale. In each sprint, you take a feature and you gather requirements on that feature, you design that feature based on those requirements, and you code and test that feature based on those designs. In Scrum, unlike waterfall, you are not trying to do everything up front; you are doing everything you need to do when you need to do it. The goal of each sprint is to deliver an increment of the final product�but an increment that is potentially releasable.

So how can we do numerous waterfall projects in each sprint, when we could barely do one waterfall project before? By doing these sprints against small features. Small features are pieces of a project that try to solve a particular problem for the customer; they don�t attempt to create the whole application. The massive features of the project are broken down into smaller chunks that can still provide value to the customer and are able to be completed more quickly. As more and more of these features are completed, the customer will start seeing the entire application coming into view.

All of this is done with a small team of developers, testers, and designers that are dedicated to getting the project done. This team is cross functional in that every member knows how to do everything. Each member may not be the best at everything, but everyone knows how to do everything necessary to complete the project. Think of them as a SEAL1 team, where every member knows how to do everything needed, but there are also experts on every aspect of the operation.

By doing things on a small scale, problems are less likely to arise near the end of the project. In fact, Scrum works to expose problems as soon as possible. Issues can�t hide because the process is broken down to a manageable scale. When a problem does surface, it causes major discomfort for the team until they address and fix it. They can�t ignore the problem because it is visible to everyone.

There is one important thing to realize about Scrum, however: it works to expose problems to the team as soon as possible, but it is not designed to fix the problems. It exposes the mud, but it is still the team�s job to clean it up.

With Scrum, you are not just creating features for the sales and marketing teams to show the customers, you are creating solutions for the customer. This is done by prioritizing the features that need to be completed based on the customer�s needs and wants. If a customer deems feature A to be more important than feature B, then the developer would be wasting his time working on feature B before feature A. Give the customers what they want when you say you can deliver it.

Source of Information : Pro Agile .NET Development with SCRUM

The Flavors of Agile

There are various forms of agile methodologies, but they all share similar characteristics. You can think of these various methodologies as branches of the same religion. The cornerstone of each branch is the idea of customer satisfaction. They also feature many of the key ideas listed previously, as well as the practices and principles laid out in the Agile Manifesto. The key thing to remember about all the agile flavors is that every one of them is iterative.

Scrum
The Scrum methodology consists of a series of �sprints,� typically lasting two to four weeks, each delivering some working, potentially shippable software. The workload of each of these sprints is driven from the �product backlog.� The product backlog consists of new features, bug fixes, technical debt, and anything else that will contribute to the end deliverable. A product owner, with help from the customer, prioritizes the product backlog and works closely with the team via regular stand-up meetings and sprint retrospectives. The iterative aspect of Scrum is that this cycle is repeated over and over until the project is complete.


eXtreme Programming (XP)
eXtreme Programming (XP) is strongly focused on customer interaction and involvement. It has the following five values:
� Simplicity
� Communication
� Feedback
� Courage
� Respect

It also follows these twelve practices:
1. Planning Game
2. Small Releases
3. Customer Acceptance Tests
4. Simple Design
5. Pair Programming
6. Test-Driven Development
7. Refactoring
8. Continuous Integration
9. Collective Code Ownership
10. Coding Standards
11. Metaphor
12. Sustainable Pace

In XP, user stories are created to capture requirements from customers. These stories are then estimated by the developers, prioritized by the customer, and then developed into working software on an iteration-by-iteration basis. Continuous planning and delivery underpin the disciplined XP process. It is also worth noting that many of the practices in XP are shared by other branches of agile, like Scrum.


Crystal
The Crystal group of agile methodologies focuses more on people rather than process. It has a simple set of principles that enhances teamwork by concentrating on communication and the removal of project management noise. It also concentrates teams on the priorities and critical paths of the software development. Like Scrum and XP, it also encourages frequent delivery of working software.


Dynamic Systems Development Method (DSDM)
The Dynamic Systems Development Method (DSDM) is based on the 80/20 rule, in that 80 percent of the benefit a system will be derived from only 20 percent of the systems requirements. With this in mind, only work that is deemed critical for the system to operate is prioritized; that is, the first 20 percent of requirements. DSDM is prioritized using the so-called MoSCoW method, which is as follows:

M: Must have
S: Should have, if at all possible
C: Could have, but not critical
W: Won�t have this time, but potentially later

All �must have� work is committed to being completed in the course of the project; all other work is deemed a �nice to have� and is picked up only when the core requirements have been implemented.


Feature-Driven Development (FDD)
Feature-driven development (FDD) begins by creating a model of the domain under development. Once this is completed, an iterative process of feature design and implementation begins. Features represent a useful grouping of functionality to the customer. FDD is made up of the following five simple activities:

1. Develop the Domain Object Model
2. Create a feature list
3. Plan by feature
4. Design by feature
5. Build by feature


Lean Software Development
Lean software development comes from the Lean manufacturing principles that were derived mostly from the production system created by Toyota. Lean focuses on customer value and the elimination of waste. It achieves this by following these next seven principles:

1. Eliminate waste: Selects only the most valuable features for a customer.
2. Amplify learning: Learn by doing and testing things rather than documenting.
3. Decide as late as possible: Delay decisions in order to enable more facts to be gathered and changes to take place.
4. Deliver as fast as possible: The sooner software is delivered, the sooner feedback is received and incorporated into the next release, giving fast return on investment to the business.
5. Empower the team: Make the team responsible and increase motivation by including all members in the decision-making process.
6. Build integrity in: Re-factor regularly to keep code flexible and adaptable to change.
7. See the whole: Ensure that domain knowledge is spread throughout the team in order for problems to be identified at any level of the system.

Source of Information : Pro Agile .NET Development with SCRUM

Key Features of Agile

Looking through the Agile Manifesto and, in particular, the twelve principles, we can identify some key features that define the process and mindset. Let�s explore these at a deeper level.
� Embracing change by understanding the needs of the business: Being agile is a realization that change is inevitable; nobody gets it right the first time, business priorities change, and people get things wrong. Agility comes about by embracing change, and learning from and with the business. With this in mind agile defines the ability to adapt and be flexible, to embrace change rather than resist it or sit around and moan that the goalposts have moved. Agile teams embrace change and actively identify changes in applications that will increase business value.

� Focusing on the business value and return on investment (ROI): Agile development is a development mind shift and a refocusing of efforts and priorities. There are a number of techniques that will help you become a more agile developer. However, becoming truly agile is so much more than the sum of its parts. The tools, project methodologies, and programming methods can certainly go some way to help one become agile, but it is the ability to apply these techniques to an ever-changing business that will truly reap the rewards. Fundamentally you must understand the business domain you are working within and align your efforts, practices, and process to realize its value.

� Continuous delivery via incremental and iterative development: Being agile is all about delivering working software of value as often as possible. Success of software development is not measured in the amount of design work. Businesses measure success in working software; this should be your measure of progress as well.

� Continuous improvement by learning from and with the business: As part of the software development team, it�s our job to turn the language and processes of the business into software systems. In order to do this it is vital that we work closely with the domain experts themselves, that is, the people that will use the software. The users aren�t always domain experts. They have experience using the existing process, but do not necessarily understand why it is that way. That is where the domain experts come in. The more you as a developer understand about the business you are writing software for, the better the software will be.

� Eric Evans in his book Domain-Driven Design: Tackling Complexity in the Heart of Software (Addison-Wesley Professional, 2003) picks up on this point when he mentions the �ubiquitous language.� This is a language that is shared between the developers and the business to describe the business domain being modelled.

� Keeping the process lean by continuous reflection on process and the removal of waste: Keeping process and practices lean is all about eliminating waste. Don�t bother with lots of documentation before developing systems. Create the documentation when it is needed. You should be able to cope with a few architectural diagrams that any member of the team can reproduce on a white board. Instead of masses of requirements documentation, use story or tasks cards and write features that can act as reminders for conversations when it is time to build the feature. Lots of upfront documentation is no good to the business� there is simply no value in it. The amount of documentation that is produced in an agile project is defined as a requirement. It is not true that agile equals no documentation. Agile equals the removal of useless information. The code and the user stories with their corresponding acceptance criteria become the documentation of the project. Not a 400-page, stagnant requirements document.
? Keeping lean is also achieved with regular retrospectives on work carried out and meetings on what�s working and not working with the current processes. Continuously refining how we work and concentrating on the work at hand will contribute towards a leaner and more effective working practice.

� Strong focus on team effort that spans more than developers in order to reduce risk and find better ways of working: Agile is about working together with a strong focus on the team in an effort to improve your working practices and ultimately deliver more value for your business. Domain experts, product managers, business analysts, security and IT infrastructure stakeholders, and testers should be first-class citizens along with developers during the project. Including nondevelopers in the team helps to increase knowledge and shared ownership and decreases the �them and us� gap between developers and everyone else in more traditional methods.
? Agile development can be the proverbial silver bullet. The problem that occurs has to do with changing the people around you. That being said, an agile project methodology can be very valuable to any organization with a need to be flexible when prioritizing application development.

Source of Information : Pro Agile .NET Development with SCRUM

Patterns for Adopting Scrum - Start Small or Go All In

Conventional, long-standing advice regarding transitioning to Scrum or any agile process has been to start with a pilot project, learn from it, and then spread agile throughout the organization. This approach is the frequently used start-small pattern in which an organization selects typically one to three teams (of five to nine people each), gets them successful, and then expands Scrum from there. As Scrum spreads through the organization, new teams benefit from the lessons learned by the teams that have gone before. There are many variations of start small, depending on how many people the organization wants to transition and how quickly they want to do it. Start small can also be applied differently based on how riskaverse or uncertain about the transition the organization is. For example, in some cases the first team or teams will finish their projects before a second set of teams even begins. Other organizations will take an overlapping approach, where the second set of teams starts only one or two sprints after the first.

The start-small pattern, while popular, is not for everyone. Salesforce.com, for example, followed the opposite pattern (Fry and Greene 2006). I remember answering my phone on October 3, 2006, and hearing Chris and Steve from

Salesforce.com tell me that they had just converted 35 teams to Scrum overnight. They asked if Fd like to help. My initial thought was that they needed a psychiatrist more than a Scrum consultant. Not one to shrink from a challenge, though, I agreed to help, packed a copy of Freud alongside my laptop, and set off for their office in San Francisco. Part of what I saw there wasn't entirely unexpected� teams and individuals in an uproar over such a sudden, far-reaching change�but I also saw other things that helped this large-scale, rapid adoption succeed. Salesforce.com was pursuing the all-in pattern, which draws its name from a poker player who bets all of his chips on one hand. Salesforce.com has a hard driving, aggressive, achievement-driven culture that would not have been a good fit for a cautious start-small approach. When key executives were presented with a proposal to adopt Scrum, they were convinced. They felt that if Scrum was worth doing for one team, it was worth doing for all teams, so they chose to go all in.

Surprisingly, the all-in and start-small patterns can be combined. An increasingly common approach is a one- to three-team pilot project followed immediately by going all in. The pilot in this case serves the typical purpose of allowing the organization to learn about Scrum and how it will function there. However, the pilot in this scenario also serves the more important purpose of increasing organizational awareness about Scrum. If you're going to transition 200 or more people all at once, it is extremely helpful to be able to point to one team who has already done it and say, "We're all going to do what they did."


Reasons to Prefer Starting Small
The start-small approach offers several advantages.

� Starting small is less expensive. An all-in transition will almost certainly cost more than starting small. Because of the greater number of people learning a new way of working all at the same time, all-in transitions generally rely more heavily on outside coaches, ScrumMasters, and trainers. The slower pace of a start-small adoption allows the organization to build internal expertise and then use that to help the teams that start later. Starting small also saves money because early mistakes affect only a subset of the organization. Tom Gilb, who was perhaps the original agilist, has written, "If you don't know what you're doing, don't do it on a large scale" (1988, 11).

� Early success is almost guaranteed. By carefully selecting the initial project and team members, you can almost guarantee the success of your first Scrum project. You may consider this cheating; I don't. When starting small, a goal of the first few projects is to generate the knowledge that will enable the successful rollout of Scrum. There may be value in starting with a project and team that make success easy and then learning from its experiences. Additionally, an early success can be vital to gaining buy-in from skeptics or fence-sitters.

� Starting small avoids the big risk of going all in. An all-at-once transition can be very risky. Small mistakes will be magnified across the entire transition effort. Perhaps the most significant risk to an all-in approach is that you will be unlikely to get a second chance. If you start to transition the entire organization, make a mistake that increases resistance, and then revert to your pre-Scrum process while figuring out how to overcome the newly discovered issues, it is unlikely that team members will give you a second chance to start the transition. Resistance by that point will likely be so entrenched that the transition effort will have failed. By contrast, if you start small and find a fatal flaw in how you've started, you can keep the next round the same size as the current one, rather than expanding, effectively restarting the transition process.

� Starting small is less stressful. Twenty-first century organizations and their employees are under constant stress. An announcement that the whole development organization is adopting Scrum, which affects so many aspects of everyday work, could be the proverbial straw that breaks the camel's back. The stress of transitioning is reduced by starting small because early adopters become coaches and ambassadors. They encourage other groups to make the transition with stories of their successes and honest discussions of the challenges they faced and overcame.

� Starting small can be done without reorganizing. Most organizations that fully adopt Scrum will eventually undergo some degree of reorganizing. This can create further stress and can increase resistance from some individuals. By starting small, the need to reorganize can be put off longer, ideally until valuable experience with Scrum has been gained.


Reasons to Prefer Going All In
Just as there are reasons to prefer starting small, there are reasons to prefer an all-in transition:

� Going all in can reduce resistance. In anything less than an all-at-once transition, there will always be some skeptics who will hold out hope that the whole effort is a pilot that will soon be abandoned. Like Cortez burning his boats at Vera Cruz to prove his resolve to his soldiers, an organization that goes all in is demonstrating both its commitment to the new process and also that it will not turn back. This level of visible commitment to the change can be beneficial in helping the change succeed.

� It avoids problems created by having Scrum and traditional teams work together. If you transition anything short of the entire company all at once, you run the risk of having some teams using Scrum and others not. This means there will be times when a Scrum team needs to coordinate work with a traditional team, which creates challenges because of the different attitudes Scrum and traditional teams bring to things like planning, deadlines, and communication. These problems go away when the entire organization adopts Scrum at the same time. Chris Fry and Steve Greene ofSalesforce.com report that "the key factor driving us toward a big-bang rollout was to avoid organizational dissonance and a desire for decisive action. Everyone would be doing the same thing at the same time" (2007, 137).

� An all-in transition will be over more quickly. One of the central tenets of this book is that an organization is never "done" becoming agile; there are always improvements to be made. However, there is definitely a time when employees can look back and say of the transition that the worst is over. An organization that goes all in can reach this point more quickly.


Choosing Between Going All In and Starting Small
As I mentioned at the start of this chapter, starting small has been the default approach recommended by most agile authors and used in most agile adoptions. The combination of this approach's low risk and high likelihood of success make it hard to find fault with. Always choose to start small when there is reluctance by leaders in the organization to fully commit to Scrum. Success, even on a small scale, can be the best way to convince the skeptics. Always start small when there is a high cost associated with failure. If the cost of failure is too high for those leading the transition, starting small is the way to go, even if it may not be best for the organization as a whole. Start small is probably not the best approach when your organization urgently needs the benefits of Scrum. (But if you do choose to start small, scale quickly.) Starting small is safe, but it's slow.

Going all in should be used in limited cases. Consider going all in if time is critical. Although an all-in approach may cost more money, it will cost less time. If time is your primary concern, all in may be the best solution. Consider going all in if you, like Salesforce.com, want to send a clear message to a small number of critics and stakeholders that Scrum is here to stay. Never go all in without enough experienced ScrumMasters to serve each team. It doesn't matter in the short term whether these ScrumMasters are internal or external; but remember that eventually you'll want all of your ScrumMasters to be internal employees. Finally, size matters. If there are only ten of you, you might as well go all in. But for teams of more than perhaps 400, going all in may not be logistically possible.

Whichever route you choose for adopting Scrum, remember that choosing this pattern is only the first of the many decisions you'll need to make when transitioning. You will next need to decide whether to make your transition public.

Source of Information :  Pearson - Succeeding with Agile Software Development Using Scrum 2010

ADAPTing to Scrum

Lori Schubring was among the first to realize that things had to change. An application development manager for a large manufacturing company, Lori realized that its development process had become "so formalized that we hindered our ability to remain flexible for the business. It got to the point where we weren't turning around project requests fast enough" (2006, 27). Aware of the need to change, Lori attended a free, half-day seminar introducing Scrum. What she saw there was a better way to develop software, a framework she thought might help her organization. As such, Lori developed the desire to change to Scrum. Next, she acquired the ability to do it by participating in a ScrumMaster class, attending an agile conference, and visiting a company that had already adopted Scrum. Lori then promoted Scrum to her boss and team, convincing them of its benefits. Finally, Lori transferred some of the implications of her team using Scrum to the rest of her company so that organizational gravity would not pull the team back to where it had started.

Lori's story encapsulates the five common activities necessary for a successful and lasting Scrum adoption:

� Awareness that the current process is not delivering acceptable results

� Desire to adopt Scrum as a way to address current problems

� Ability to succeed with Scrum

� Promotion of Scrum through sharing experiences so that we remember and others can see our successes

� Transfer of the implications of using Scrum throughout the company

Conveniently, these five activities�Awareness, Desire, Ability, Promotion, and Transfer�can be remembered by the acronym ADAPT. These activities are shows Awareness, Desire, and Ability as overlapping, whereas Promotion and Transfer repeat and occur throughout the transition effort. After you have transitioned, this cycle will continue as you continuously improve.

The five activities of ADAPT are based on ADKAR (Hiatt 2006), a general model of change that includes the steps of Awareness, Desire, Knowledge, Ability, and Reinforcement. In practice, I have found separating Knowledge and Ability to be unnecessary. In a field such as software development, knowledge without ability is meaningless. Additionally, the Reinforcement step of ADKAR is replaced in ADAPT with separate Promotion and Transfer steps, emphasizing the importance of these activities to a successful transition.

An organization that successfully adopts Scrum can be thought of as engaging in these activities at multiple levels:

� Organizationally. The organization as a whole will engage in these activities. No matter how aware one person or group is, there must be a critical mass of people with a similar awareness before the organization will be able to collectively move forward. In thinking of the ADAPT model at this level, we may speak of a company with an organizational desire to adopt Scrum. Or we may say that our organization currently lacks the ability to do Scrum.

� As individuals. Because organizations are made up of individuals, it is important to acknowledge that individuals will progress through the overall transition at different rates. For example, you personally may already have acquired the ability to do Scrum; you've learned some new skills and some new ways of thinking about software development. A colleague, on the other hand, is only starting to become aware that the current approach isn't working.

� As teams. Individuals can be aided or hindered in the transition to Scrum by their teams. Teams tend to progress through the ADAPT cycle more or less together. In the same way that studies have shown individuals are more likely to be overweight if their friends are overweight (Thaler and Sunstein 2009), you are more likely to have a desire to do Scrum if the rest of your team does as well.

� Per practice. The ADAPT model can also be applied to each new skill that is acquired as part of adopting Scrum. Consider the increased reliance on automated unit testing that is common on Scrum teams. The team and its members must first become aware that the current approach to testing isn't working. They must then develop the desire to automate more tests and to do so earlier in the process. To do this will require that some team members learn new skills. Promoting the team's success with automated testing will encourage other development teams to emulate them. Finally, transferring the implications of the team doing more automated testing to other groups ensures that forces external to the team do not prevent it from continuing with the new practice.

One of the first things you'll need to do, whether you are currently using Scrum or just starting your adoption, is to decide where your individuals, teams, and organization are in their ADAPT sequence. It could be that you are acquiring the ability to do test-driven development on a team that is promoting its success inside a department that desires to implement Scrum. The overall organization, however, may be aware of only a general need to change. This chapter will discuss not only the five ADAPT activities but also the tools you will need to encourage and develop awareness, desire, ability, promotion, and transfer throughout all levels of the organization.

Source of Information :  Pearson - Succeeding with Agile Software Development Using Scrum 2010

Why Becoming Agile Is Hard (But Worth It)

Many software development organizations are striving to become more agile. And who can blame them? Successful agile teams are producing higher-quality software that better meets user needs more quickly and at a lower cost than are traditional teams. Besides, who wouldn't want to be more agile? It just plain sounds good, doesn't it? It is almost as though one cannot be too thin, too rich, or too agile. But beyond the buzzword and hype, organizations that take becoming agile seriously by adopting a process such as Scrum are seeing dramatic benefits.

They are seeing significant gains in productivity with corresponding decreases in cost. They are able to bring products to market much faster and with a greater degree of customer satisfaction. They are experiencing greater visibility into the development process, leading to greater predictability. And for them, out-of control, will-it-ever-be-done projects have become a thing of the past.

One company to realize these benefits by adopting Scrum is Salesforce.com. Founded in 1999 in a San Francisco apartment, Salesforce.com is one of the true, lasting dot-com-era success stories. With revenue of more than $450 million and 2,000 employees in 2006, Salesforce.com had noticed the frequency of its releases had dwindled from four a year to one a year. Customers were getting less and waiting longer to get it; something needed to be done. The company decided to transition to Scrum. During the first year of making the switch, Salesforce. com released 94% more features, delivered 38% more features per developer, and delivered over 500% more value to its customers compared to the previous year (Greene and Fry 2008). In the ensuing two years, revenue more than doubled to more than $1 billion. With results like these, it is not surprising that so many organizations have transitioned to Scrum. Or at least tried to.

I say "tried to" because transitioning to Scrum and other agile methods is hard�much harder than many companies anticipate. The changes required to reap all of the rewards being agile can bring are far reaching. These changes demand a great deal from not only the developers but the rest of the organization as well. Changing practices is one thing; changing minds is quite another. It is my aim in this book to show not only how to transition well but also how to succeed long term.

I've personally witnessed several failed agile adoptions that could have been prevented. The first was in a company that had spent more than a million dollars on its transition effort. Executives brought in outside trainers and coaches and hired five people into an "Agile Office" to which new Scrum teams could turn for advice. The company's failure was the result of thinking that the implications of adopting Scrum would be restricted to only the development organization. The executives who initiated this transition thought that educating and supporting developers would be sufficient. They failed to consider how Scrum would touch the work of salespeople, the marketing group, and even the finance department. Without changes to these areas, organizational gravity pulled the company back where it had started.

For completely different reasons, Josef ultimately failed at introducing Scrum to his company. A newly promoted and first-time project manager, Josef was instantly attracted to Scrum because it fit his natural management style. Josef easily convinced his team�who had all been his peers as little as one month before�to try Scrum on their new project. The project was wildly successful, earning accolades for the team and winning Josef the chance at a much larger project. Josef introduced the new project team to Scrum, and most members were willing to try the new approach. Although those working on the project were happy to use Scrum, some of the functional managers to whom they reported got nervous about what Scrum might mean to their careers. Josef's luck ran out. The functional managers�in particular the directors of quality assurance and database development�banded together and convinced the vice president of engineering that Scrum was inappropriate for projects of the complexity and importance being done in their company.

Caroline fared a little better. A vice president of development in a large data management company, Caroline had more than 200 developers in her organization. After seeing the benefits of Scrum on one project, she excitedly launched an initiative to introduce Scrum across her division. All employees were provided with training or coaching. Within a few months nearly all teams were producing working software at the end of each two-week sprint. This was great progress. When I visited this company a year later, though, the employees had failed to make any additional headway. To be sure, teams were producing higher-quality software and doing it a bit faster than they had before starting with Scrum, but her company's gains were only a fraction of what they could have been. Caroline's company had forgotten that continuous improvement is part of Scrum.

Frightening, isn't it? Each of these failures was a well-intentioned effort to transition to Scrum.Yet all the good intentions in the world could not keep them from failing. Don't worry, though. Transitioning to Scrum may be hard, but it's entirely possible with the right approach. In this chapter we examine why transitioning to any agile development process, including Scrum, is especially difficult.

We detail some of the challenges that derailed the companies I've mentioned. Most important, though, we look at the reasons why the benefits of becoming an agile organization are more than worth the effort.

Source of Information :  Pearson - Succeeding with Agile Software Development Using Scrum 2010