The Agile movement seeks alternatives to traditional project management. Agile approaches help teams respond to unpredictability through incremental, iterative work cadences, known as sprints. Agile methodologies are an alternative to waterfall, or traditional sequential development. Traditional approach for developing software was first described by Dr. Winston Royce- Managing the large software systems. He draw a picture showing a series of phases. One phase connects to the next phase and each one has a hand off. In theory, you do all your analysis in the beginning, get that completely done then you start your design, get that completely done then code, integration etc. and we suppose it could work when we have a perfect knowledge at the beginning and never made mistake along the way.
Enhanced Quality
Predictability
Better Customer Experience
Continuous Engagement
Transparency
Ease of doing
Thats why the next sentence in Dr. Winston Royce’s paper, unfortunately no one read this far, said-
Dr. Winston W. Royce. Proceedings, IEEEWESCON, August 1970.
Copyright ©1970 by IEEE. Originally published by TRW.
Scrum is the most popular way of introducing Agility due to its simplicity and flexibility. Because of this popularity, many organizations claim to be “doing Scrum” but aren’t doing anything close to Scrum’s actual definition. Scrum emphasizes empirical feedback, team self management, and striving to build properly tested product increments within short iterations. Doing Scrum as it’s actually defined usually comes into conflict with existing habits at established non-Agile organizations. It provides a structure of roles, meetings, rules, and artifacts. Teams are responsible for creating and adapting their processes within this framework. Scrum uses fixed-length iterations, called Sprints, which are typically two weeks or 30 days long. Scrum teams attempt to build a potentially show able (properly tested) product increment every iteration.
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to negotiate which Product Backlog Items they will attempt to convert to working product during the Sprint. The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement without accruing technical debt. The team “pulls” work from the Product Backlog to the Sprint Backlog.
After Sprint execution, the team holds a Sprint Review Meeting to demonstrate a working product increment to the Product Owner and everyone else who is interested.The meeting should feature a live demonstration, not a report. After the demonstration, the Product Owner reviews the commitments made at the Sprint Planning Meeting and declares which items he now considers done.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend. It is the opportunity to inspect and adapt the product as it emerges, and iteratively refine everyone’s understanding of the requirements.
Each Sprint ends with a retrospective. At this meeting, the team reflects on its own process. They inspect their behavior and take action to adapt it for future Sprints. Dedicated Scrum Masters will find alternatives to the stale, fearful meetings everyone has come to expect.
There is one more step which is not officially included but most of the scrum will practice this step too -the Backlog Refinement Meeting, the team estimates the amount of effort they would expend to complete items in the Product Backlog and provides other technical information to help the Product Owner prioritize them.
