Software Development/Project Management using Scrum
A few years ago, I started a project at a major automotive company in Los Angeles. During the first couple weeks I explained the concepts of the project management Scrum Agile Development to a team that knew RUP, but wanted to implement Scrum. After the brief explanation, one of the team members asked me, "if all we're doing at a scrum meeting is reporting our status, why not just have everyone publish their status on an email or a web page, why have these scrum meetings?"
It seemed to some like a snyde resposne, but despite that it was a reasonable statement. If these scrum meetings were only capturing this information, what really is the point to meet with everyone. It was tempting to replace the scrum meetings with emails or a web page. However, some things, like human interactions, should not be automated, so here was my answer.
"Scrum meetings do much more for a team than just collect the information. They don't only make everyone capture what they did, but it makes everyone say in front of everyone else. That way everyone at the Scrum meeting listens to what others are saying and others can offer help. It makes everyone say face to face to their management. This forces everyone to have courage and to be honest, and gives everyone a tool to put pressure on management about solving issues. It also makes everyone at the scrum meeting promise in front of everyone else what you will be working on next, so it puts everyone's credibility and trust to the test. Scrum is about deep social interactions that build trust among team members.
A primary difference of the Agile approach is the notion that software requirement specifications are created in a vacuum of theory prior to reality. An iterative agile development project management cycle forces the real world into the picture, as opposed to the document driven process puts far too much pressure on the document author for perfection, which cannot be done. The agile software development approach also draws developers into the initial problem definition process, so that they are actively engaged in the solution. This proactiveness allows them to introduce new technology concepts that the software specification process would never have introduced.
Some basic principles of Agile are as follows:
Highest priority is to satisfy the customer through early and continuous delivery of valuable software
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build products around motivated individuals. Give them the environment and support they need and trust them to get the job done
SCRUM is an agile, lightweight project management process that can be used to manage and control software and product development using iterative, incremental practices. The term comes from the sport of rugby, where it refers to the process used to get the ball back into play. Everybody in the pack acts together with everyone else to move the ball down the field.
As applied to software development, it refers to the organization and management technique used to successfully deliver software in a chaotic environment.
It's important to understand that the Scrum/Agile framework is one of many frameworks available for software development. Others include,
Extreme Programming, SCRUM
Prototyping, iterative development and CASE tools
RUP (Rational Unified Process)
The Waterfall software development/project management model is based upon a defined methodology which attempts to define requirements up front, logically break down the work, estimate, plan, then begin development, while trying to limit/control change which will threaten the plan. These are based upon Defined Process Model theory which was adopted from manufacturing and applied to software development and project management.
The Agile SCRUM approach assumes that baselines will change significantly during the project. In such an unpredictable project management environment, empirical methods should be used to monitor progress and change, rather than using definitive methods to try and predict progress and stop change.
SCRUM looks forward to change, as it means the end result will be a product which more closely meets the customer's needs at the end of development. SCRUM is not, however, without its own structure and control mechanisms.
SCRUM is founded upon two basic principles:
1) Iterative Development. The project management deliverables are built over several iterative development cycles, each adding additional features, and each resulting in demonstratable results: working code, written documentation, viewable designs, etc.
2) Team Empowerment. The project team is divided into self-managing multi-function units called Sprint Teams consisting of up to seven or eight people. The team is empowered to use whatever development methods or tools they think best to prepare their deliverables.
The product owner owns the definition of success. They direct the product, sprint by sprint, to provide the greatest ROI and value to the organization. They also manages ROI through prioritization and release plans and are the sole owner of the product backlog. They set development schedule by prioritizing backlog.
One person in this role ensures that only one set of requirements drives development. They can be influenced by committees, management, customers, sales people, but is the only person that prioritizes. The product owner eliminates confusion of multiple bosses, different opinions, and interference.
According to Scrum, one person takes on the role of ScrumMaster to facilitate the team on a day to day basis. The ScrumMaster doesn't do anything else because just the workload of ScrumMaster is a full time job.
The ScrumMaster is responsible for making sure a Scrum team lives by the values and practices of Scrum. The ScrumMaster shields the team from aggressive customers by making sure they do not overcommit themselves to what they can achieve during a sprint.
The ScrumMaster facilitates the daily scrum and becomes responsible for removing any obstacles that are brought up by the team during those project management meetings.
The ScrumMaster role is typically filled by a project manager or a technical team leader but can be anyone within the project management team.
The Sprint is a fixed period to develop a deliverable product increment. It is strictly time boxed: it’s more important to fall short than to slip the date. The Sprint includes design, coding, testing, and documentation. Once a Sprint has started only the Scrum Team can add or remove items in Sprint backlog. Abnormal termination of Sprint is called for when the Sprint Goal no longer makes sense.
The Special Release Sprint -- Releasing software to production requires a special sprint known as the “Release Sprint”
Like any other sprint; but the release sprint team is dedicated ONLY to releasing the software during that period
Used to package software, final regression tests, move through the various environments and release to production.
No additional functionality is taken on for release. Can be made up of a subset of team members from the original development sprints.
This practice is when the product Owner describes highest priority features to the team, and the team then decides what they can commit to delivering in the Sprint. This occurs within two consecutive meetings (4 hours each) where the goal is set and the team plans tasks to create the Sprint Backlog.
The daily Scrum is a daily 15 minute status meeting held in typically the sam place and time every day for consistency.
Logistically, the Scrum team sits in a circle facing each other and each team member will address the following three questions.
1. What have you done since the last Scrum?
2. What will you do between now and the next Scrum?
3. What got in your way of doing work?
At the end of each sprint a review meeting is held. During this meeting the Scrum team demonstrates what they completed during the sprint phase. Typically this takes the form of a demo of the new features.
It is reccomended that the sprint review meeting is very informal, with rules forbidding PowerPoint slides and allowing no more than two hours of preparation time for the meeting. A sprint review meeting should not become a distraction for the team. Instead should be a natural result of the sprint.
Participants in the sprint review meeting include but are not limited to the Product Owner, the Scrum team, the ScrumMaster, management, customers, and engineers from other projects. During this meeting the project is compared against the sprint goal determined during the Sprint planning meeting. Optimally, the team has completed each product backlog item brought into the sprint, but it is more important that they accomplish the goal of the sprint.
Facilitated by the ScrumMaster, this meeting is used to discuss the just concluded Sprint and determines what could be changed that might make the next Sprint more fun and productive. The Sprint Review looks at what the team are building whereas the Retrospective looks at they are building.
Anything that affects how the team builds software is open for discussion such as processes, practices, communication, environment, and tools.
Scrum should be seen as a framework that should be adapted appropriately for any given project, team and specific situations. The Sprint retrospective is an important tool that allows a team to continuously improve through the life of a project.
A product backlog is a prioritized list of project requirements with time estimates for completion and implementation. Estimates are in days and are more precise the higher the item is in the Product Backlog queue. Priority should be assigned based on the items of most value to the business or that offer the earliest ROI and value. This list should evolve, changing as the business conditions or technology changes.
The sprint backlog is the collection of tasks that the Scrum team is committing that they will complete in the current sprint. Sprint backlog items are drawn from the Product Backlog, by the team based on the priorities set by the Product Owner and the team's perception of the time it will take to complete the various features.
It is critical that the team selects the items and size of the sprint backlog. Because they are the ones committing to completing the tasks they must be the ones to choose what they are committing to.
An effective Scrum will deliver the highest business value features first and will always try and avoid building unrealistic features. Since industry data shows that about half of the software features developed are never used, development can be completed in half the time by avoiding unnecessary work.
Typically, development is slowed down by issues identified as impediments during the daily meetings or planning and review meetings. Using Scrum, these obstacles are prioritized and systematically purged, increasing effectiveness and quality. Well-run Scrums achieve the Microsoft effect: four times industry average productivity and twelve times better quality.
Scrum aims to remove management pressure from teams. Teams are allowed to select their own work, and then self-organize through close communication and mutual agreement within the team on how best to accomplish the work. In a successful Scrum, this level of control can often improve the quality of life for developers and enhance employee retention for managers.
The simple rules of Scrum allow for continual inspection, adaptation, self-organization, and emergence of innovation. It can produce an exciting product for the customer, foster great team spirit and satisfying work, and yield high productivity and customer satisfaction, and achieve the company financial goals. At the end of the day, Scrum is being widely adopted worldwide in companies large and small, localized or distributed, open source or proprietary, for virtually any type or size of project.
The GatherSpace.com system becomes a natural fit for the software requirements gathering cycle within the Scrum framework. In creating the product backlog, you would use the "features" functionality. To order the priority for the product backlog, you would use the rank field. For each feature in the product backlog, you can create individual software requirements/specifications and report on that.
We typically have Scrum teams using GatherSpace and reccomend various system changes that helps the system adhere to solid Scrum practices. Going forward, if your team decides to use GatherSpace and Scrum we always encourage continuous feedback so we can improve the system for all.