After the team has picked the requirements from the Project Backlog, during the Sprint Planning Meeting, the team normally drafts a Sprint Backlog, the team starts working on the requirements and through a Daily Stand Up during the Sprint and updates the Sprint Backlog. Once the sprint is complete, the time comes to demonstrate working functionality. For this, the team and product owner gather together for Sprint Review. A Sprint Review is a meeting where the team demonstrates working software corresponding to project backlog items they have completed in a given sprint. There are some simple rules for a Sprint Review:

• The meeting is kept very informal. The team should not have to spend time preparing for the same beyond getting working software ready.
• Powerpoints, presentations, speeches and lectures are not allowed.
• You can only demonstrate working software.
• The preparation [working environment, arranging room] is done by the Agile Coach or Scrum Master.
• The meeting generally lasts about 1 hour per week of work [but this obviously can change depending on number of team members working for the project].
• The whole team, product owner or customers and stakeholders participate in the Sprint Review Meeting.

Of the above focus on “working software” is very important. This keeps the teams focus on delivering working software and adopting processes which aid delivery of the same. Thats another reason why any aids like PowerPoint slides or lectures are not allowed. The team would typically demonstrate each code it has written either through GUI, mock objects or through API calls. Actual working software allows product owner or customer to get first hand experience of the working features and based on the same provide feedback to the team. The feedback to the team is typically of these components:

• Whether they completed enough requirements
• Whether they completed requirements quite early
• Whether they understood the requirements and translated them to working features well enough

All three help the team and product owner plan for the next sprint better. At the end of sprint review meeting, Agile Coach or Scrum Master would announce the date for next Sprint Review and confirm the date for next Sprint Planning session. This sets the tone for the next sprint. After the Sprint Review Meeting, the team moves towards the Sprint Retrospectives.

The Sprint Review also works as a feedback channel for the Product Owner in some ways. The Product Owner invites stakeholders and customers who give her the actual feedback which she can factor into her requirements for future. She can then edit or delete any requirement or add new ones. In addition, they help the Product Owner identify the correct priority for requirements and minimize the biggest risk of all - developing the wrong thing as well as the second biggest risk - developing the wrong thing, the wrong way. Hence, Sprint Review is basically a “feedback, inspect and adaptation” channel in an Agile Development Framework.

Popularity: 33%

Posted on February 28th, 2008 by admin
Filed under: Assessment, Collaboration, Introduction, Practices | No Comments »

agilecollab brings you an exclusive interview with Ken Schwaber. A brief profile of Ken at Scrum Alliance website reads: Ken Schwaber co-developed the Scrum process with Jeff Sutherland in the early 1990s to help organizations struggling with complex development projects. One of the signatories to the Agile Manifesto in 2001, he subsequently founded the AgileAlliance, a nonprofit organization dedicated to the creation of Agile software. He then founded the ScrumAlliance, a nonprofit organization dedicated to expanding the understanding of Scrum. A 30-year veteran of the software development industry (from bottle washer to boss), he has written three books about Scrum: Agile Software Development with Scrum, Agile Project Management with Scrum, and The Enterprise and Scrum. He lives in Lexington, Massachusetts with his family. His web site is www.controlchaos.com

In this interview Ken answer’s questions about use of Scrum, origins of Scrum, Scrum and Outsourcing, changes required to implement Scrum and the India connection.

agilecollab: You might have answered this a lot of times - how did the motivation for coming up with something like Scrum came about?

Ken Schwaber: My company, ADM, provided process automation products to several of the large methodology companies, like IBM and Coopers & Lybrand. Between all the new features that we wanted to introduce, features demanded by our customers, and our somewhat unstable object oriented technology base, we were overwhelmed. A friend of mine, Jeff Sutherland was experiencing similar problems at Easel. Jeff asked which of the methodologies ADM had automated we were using internally. I replied, 鈥渘one; otherwise we鈥檇 be out of business!鈥� Jeff already had some ideas about Scrum, so we started collaborating. The result was a pretty complete, field-tested Scrum by the end of the 1990鈥檚.

agilecollab: Are you pleased at rapid spread of Scrum?

Ken Schwaber: Yes, in that the spread means that people are desperate for a new approach. No, in that they may think of Scrum as simply an iterative version of waterfall. Many CIO鈥檚 still think of Agile as more, faster. However, as organizations and projects flee the existing controls and safeguards of waterfall and predictive processes, they need to recognize the even higher degree of control, risk management, and transparency required to use Scrum successfully. I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it.

agilecollab: Do you agree with 50% Scrum approaches? Are there any dangers in this approach?

Ken Schwaber: Scrum is a very simple framework within which the 鈥済ame鈥� of complex product development is played. Scrum exposes every inadequacy or dysfunction within an organization鈥檚 product and system development practices. The intention of Scrum is to make them transparent so the organization can fix them. Unfortunately, many organizations change Scrum to accommodate the inadequacies or dysfunctions instead of solving them.

agilecollab: Does outsourcing and Scrum work together or you should keep both of them as separate as possible?

Ken Schwaber: Outsourcing can be as simple as additional Scrum teams that are remote. They have the same Scrum responsibilities as any team, and have to test and integrate their work according to the same schedules or as worked out by the teams. Then Scrum works fine with outsourcing. Scrum鈥檚 transparency makes any inadequacies visible.

agilecollab: What makes Scrum a good fit for using it with any engineering approaches like XP or even system approaches like Lean?

Ken Schwaber: Scrum is a framework. XP engineering practices can be used within a Scrum Sprint to improve quality and productivity. Lean is a way of thinking that optimized complex, repetitive processes. Product development is more of a one-off thing, where every release and project is more unique than similar. However, much of the thinking that Lean uses is also used by Scrum, so studying lean helps you understand Scrum. For instance, value stream mapping helps optimize some of the processes 鈥� such as change control 鈥� that aren鈥檛 addressed by Scrum. Scrum purposefully has many gaps, holes, and bare spots where you are required to use best practices 鈥� such as risk management. Scrum then shows you how well that approach works through transparency, so you can continually optimize the approach.

agilecollab: You must have coached many people now. There must have been a lot of Indians in those trainings as well. Anything specific you noted in the way they respond to the values of Scrum?

Ken Schwaber: I think that the cultural differences are given too much significance. I find excellent, serious, determined professionals from India, China, Germany, Finland, Iceland, and the America鈥檚.

agilecollab: Have you been to India? Any plans for the same?

Ken Schwaber: I ran development projects for the United Nations Development Program from India and Indonesia in the 1980鈥檚. A wonderful people, a long airplane trip.

agilecollab: A lot of people in India say - “Scrum is not suited in Indian cultural context”. You would have heard that probably in many cultures before. There are blog articles who say “Agile is for Bay Area”. How do you respond to this?

Ken Schwaber: Several changes, or cultural shifts, are required to use Scrum. The first is to forget predictive, waterfall thinking. The second is to realize that self-management is a much better practice for productivity and creativity. The third is to understand that cross-functional teams produce more robust products. All of these changes are extremely difficult, regardless of the country. I鈥檇 say that the United States has a lot of trouble going from top-down, command and control to self-management; we believe that the only way to get something done is to make it get done. Many large [and other] Indian companies believe the same. Success, competitive advantage, and quality products are the fruits of the change, to those who make this change.

agilecollab: Finally, what are your next goals?

Ken Schwaber: To create many environments where Scrum helps people look forward to coming to work, where customers love working with software developers, and where the quality and predictability of our efforts significantly increases. To help the 25% of the organizations that are willing to make the effort to improve, and to help them beat the pants of those who aren鈥檛. To make it work so well that firms in the United States turn to offshore because they need more people, not because they can鈥檛 stand the developers in the United States or just for pricing advantage. And, to help everyone conceive of people as people, not resources.

Popularity: 41%

Posted on February 19th, 2008 by admin
Filed under: Around the Globe, Interviews | 6 Comments »