The rules of the game in new product development are changing. Many companies have discovered that it takes more than the accepted basics of high quality, low cost, and differentiation to excel in today’s competitive market. It also takes speed and flexibility.
This new emphasis on speed and flexibility calls for a different approach for managing new product development. The traditional sequential or “relay race” approach to product development may conflict with the goals of maximum speed and flexibility. Instead, a holistic or “rugby” approach – where a team tries to go the distance as a unit, passing the ball back and forth – may better serve today’s competetive requirement.
- Takeuchi, Hirotaka and Nonaka, Ikujiro. January-February 1986. “The New New Product Development Game.” Harvard Business Review.
The Scrum software development process uses an iterative, incremental approach. Interaction with the environment (technical, competitive, and user) is allowed, which will change the project scope, technology, functionality, cost, and schedule whenever required. Controls are used to measure and manage the impact.
Scrum accepts that the development process is unpredictable. The product is the best possible software, factoring in cost, functionality, timing, and quality.
- Schwaber, Ken. “Controlled Chaos: Living on the Edge.”
The rules and practices for Scrum—a simple process for managing complex projects—are few, straightforward, and easy to learn. But, Scrum’s simplicity itself—its lack of prescription—can be disarming. Scrum provides a simple framework of basic tenets to solve complex problems and drive better results—delivering more valuable software faster .
Scrum is hard. It’s not hard because of the things you do; it’s hard because of the things you don’t do. There are no Gantt charts in Scrum, there’s no time reporting, and you don’t assign tasks to programmers. Instead you’ll learn the few simple rules of Scrum and how to use its frequent inspect-and-adapt cycles to create more valuable software faster.
The Scrum Team consists of the Scrum Master, the Product Owner, and the Team. Scrum Team members are called “pigs.” Everyone else is a “chicken.” Chickens cannot tell “pigs” how to do their work. Chickens and pigs come from the story –
“ A chicken and a pig are together when the chicken says,
“ Let’s start a restaurant!”
The pig thinks it over and says,
“ What would we call this restaurant?”
The chicken says, “Ham n’ Eggs!”
The pig says,
“ No thanks, I’d be committed, but you’d only be involved!”
The Team is responsible for developing functionality and collectively responsible for the success of each iteration and of the project as a whole.
Teams are self-managing, self-organizing, and cross-functional, and they are responsible for figuring out how to turn Product Backlog into an increment of functionality within an iteration and managing their own work to do so.
The responsibilities of the Team or Team Member role are:
Estimating size of backlog items
Committing to increments of deliverable software - and delivering it
Tracking own progress
Self-managed but accountable to the Product Owner for delivering as promised
The Scrum Master is responsible for the Scrum process, for teaching Scrum to everyone involved in the project, for implementing Scrum so that it fits within an organization’s culture and still delivers the expected benefits, and for ensuring that everyone follows Scrum rules and practices.
The responsibilities of the Scrum Master role are:
Empowering and shepherding the team
Keeping the process moving
Institutionalize Scrum to the larger organization
The Scrum Master is a friend, philosopher and guide for the team !
A Scrum project starts with a vision of the system to be developed which might be vague at first but it will become clearer as the project moves forward.
PO is responsible for delivering the vision in a manner that maximizes the ROI, formulates a plan and converts that into a Product Backlog.
Product Backlog is a list of requirements that will deliver the vision. Product Backlog is prioritized so that the items most likely to generate value are top priority.
The prioritized Product Backlog is a starting point and is grouped into releases. Changes in the Product Backlog reflect changing business requirements and how quickly or slowly the Team can transform Product Backlog into functionality.
All work is done in Sprints. Each Sprint is an iteration of 2 to 4 consecutive weeks.
Each Sprint is initiated with a Sprint planning meeting, where PO and Team get together to collaborate about what will be done for the next Sprint.
Selecting from the highest priority Product Backlog, the PO tells the Team what is desired, and the Team tells the Product Owner how much of what is desired it believes it can turn into functionality over the next Sprint.
Sprint planning meetings cannot last very long — that is, they are time-boxed to avoid too much hand-wringing about what is possible. The goal is to get to work, not to think about working.
The Sprint planning has two parts - in first part PO presents the Product Backlog to the Team. The Team questions about the content, purpose, meaning, and intentions of the Product Backlog. Team selects as much Product Backlog as it believes it can turn into a completed increment of potentially shippable product functionality by the end of the Sprint. The Team commits to the PO that it will do its best.
During the second part of the Sprint planning meeting, the Team plans out the Sprint. Because the Team is responsible for managing its own work, it needs a tentative plan to start the Sprint. The tasks that compose this plan are placed in a Sprint Backlog; the tasks in the Sprint Backlog emerge as the Sprint evolves. With Sprint planning meeting, the Sprint starts, and the clock is ticking toward the Sprint time-box.
Sprint is time-boxed to the amount of time required to build something of significant interest to the PO and potentially shippable.
The Team commits to Product Backlog during the Sprint planning meeting and Product Backlog is frozen until the end of the Sprint.
The Team can seek outside advice, help, information, and support during the Sprint but no one can interfere during the Sprint.
If the Sprint proves to be not viable, the Scrum Master can terminate the Sprint and initiate the next Sprint.
If the Team feels itself unable to complete all of the committed Product Backlog during the Sprint, it can consult PO on which items to remove from the current Sprint. Conversely, it can consult PO on which additional Product Backlog items can be added to the Sprint.
The Team members have two administrative responsibilities during the Sprint: attend the Daily Scrum meeting, and keep the Sprint Backlog up-to-date
Picture courtesy methodsandtools.com The Sprint
After Sprint review and prior to next Sprint planning, Scrum Master holds a Sprint retrospective meeting with the Team.
The Sprint retrospective meeting is time-boxed and attended only by the Team, Scrum Master. PO is optional.
At this time-boxed meeting, Scrum Master encourages Team to review, within the Scrum process framework and practices, its development process to make it more effective and enjoyable for the next Sprint.
Team members answer two questions:
What went well during the last Sprint?
What could be improved in the next Sprint?
The Scrum Master records the Team’s answers in summary form.
The Scrum Master is not to provide answers but to facilitate the Team’s search for better ways for the Scrum process to work for it.
The trend of work remaining across time in a Sprint, a release, or a product. The source of the raw data is the Sprint Backlog and the Product Backlog, with work remaining tracked on the vertical axis and the time periods (days of a Sprint or Sprints) tracked on the horizontal axis.
The Burndown report remaining estimated workload over the course of the project. Workload at the start of each Sprint is measured by summing all open Product Backlog work estimates. From Sprint to Sprint, the increase or decrease in these sums can be used to assess progress toward completing all work for a release by an expected date.