Its not uncommon to hear from Scrum teams - “we are sprinting, do not disturb” or “this could be handled in the next sprint” or “this sprint is going really well.” One of the first things, anyone learning about Scrum, should do well is to understand what is a sprint - philosophy and mechanics.Sprint in Scrum [or an iteration in a XP team] is a time period (can be anything from 2 to 8 weeks) in which the team does whatever it can to develop software as per the features/ requirements that the Team has committed to. At the start of a sprint, the team gets together with stakeholders [ideally represented by single entity called a product owner] and works out with the product owner, what features or set of requirements [which is usually called sprint backlog] will they be completing in this sprint. During the sprint, the team works on the sprint backlog. At the end of the sprint, the team demonstrates actual working software. The team also gets together to review its progress and what can be done better in the next sprint. Hence, a sprint is a time boxed period of time in which the team develops software as per its commitment.

The basic mechanics of a sprint in Scrum is centered on it being time boxed to a fixed duration. A 2 week sprint will end in 2 weeks even if all the work the team committed to is not completed. This is very important because:

• A fixed duration, imparts a rhythm to the process.
• The team gets better at identifying how much work to ideally commit to once it keeps working within fixed duration of time - this provides a great predictability to the product owner after a few sprints to plan releases around solid data rather than hope or complicated formulas not based on actual experience of “the” project. Additionally, the teams provides product owner fixed periods of engagement and review.
• The team also gets better at doing things within a fixed time period. Team reviews how well it has been working together and what can it do to get better. In a strange way time boxing provides the team tremendous opportunity to surface things that are the real obstacles. What its doing to each person in the team is tell them “You have a time boxed sprint to develop a given set of software with your team. Now, go develop and tell us whats stopping you from reaching your optimal collaboration.” Teams will [hopefully] identify everything that needs to be done and whatever is stopping them from doing it. And after a period of time get better at working together and work at a sustained pace.
• The product owner does not have to wait too long to make a change and trigger happy product owners need to wait at least 1-2 weeks to make changes. Hence, this will identify if your product owner is lackadaisical in providing feedback/ priorities and surface the obstacle. Similarly, it will also surface if your product owner is very fickle and keeping the team away from focus and stability.
• Finally, time boxing a sprint and self commitment to what it has to do in a sprint provides the team tremendous focus and goal.

Some other aspects of Scrum with regards to a sprint:

• There would be no changes in the team composition during the sprint and ideally over many sprints so that team can achieve sustainable pace in working together. Similarly, the team would commit to what it has to do and there would be no pressure to over commit. These are basically covered in the rules of Scrum.
• Product owners [or requirements owners] should be available through out the sprint to explain requirements to the team. This is important to provide marketing leadership through out the sprint for the team.
• The team would need someone to help the team surface obstacles, get better, explain Scrum and watch the Scrum process. This process leadership is generally provided by a Scrum Master.

Popularity: 9%

Posted on December 30th, 2007 by admin
Filed under: Introduction, Practices, Values | No Comments »

A lot of customers have been asking us “What is Agile?” While posts, pages, news, case studies of the website would provide information on various aspects [values, beliefs, practices, frameworks] of Agile, the simplest way to introduce anyone to Agile is to provide them information on what is called Agile Manifesto.

In 2001, various software development professionals, managers and thinkers got together and agreed on what is now called the Agile Manifesto. The signatories of the manifesto include Kent Beck [creator of jUnit and originator of concept of Design Patterns], Martin Fowler [originator of the concept of Refactoring], Dave Thomas [wrote the landmark book on Agile Development with Rails], Ken Schwaber [co-founder of SCRUM] and Brian Marick [world renowned testing expert]. Agile Manifesto states that:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The principles behind Agile Manifesto were as follows:

• Our 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 projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity–the art of maximizing the amount of work not done–is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Popularity: 5%

Posted on December 10th, 2007 by admin
Filed under: Values | 1 Comment »