Monday, October 24, 2011


Perhaps the most important practice for self-organization within the Scrum process is the Retrospective. Each sprint the team takes some time to assess their way of working and agree on improvement suggestions to work on and experiment with in the next sprint. When starting with an iterative and Agile way of working, the first Sprints are probably needed to get the most obvious impediments eliminated and to fulfill the basic prerequisites for iterative and Agile development (as described in the Nokia Test). Keep in mind however that circumstances will keep changing, so make adapting and improving part of your primary process.

Principles and values help to inspire improvement and pinpoint possible improvement areas. In the previous sections we talked about the Agile Manifesto and the Manifesto for Software Craftsmanship as value systems that can be used for this purpose. We talked about six XP practices for maintaining stability on a daily basis and XP’s Bill of Rights. We also introduced the Nokia Test as a set of prerequisites for a team to be Agile. RUP has 6 key principles that group twenty-five patterns for Business-Driven Development,  OpenUP has four core principles grouping twenty-four practices.

To help teams in their improvement effort we have devised a concise set of principles that are inspired by all of the above guidance. They can be used to inspire discussion in a Retrospective and guide decision-making during a Sprint. Just write them on a flip over sheet, hang it in the team room and bring it to each Retrospective.
Figure 27: Unified Principles for Iterative and Agile IT Development

Wednesday, October 12, 2011

Test Your Agility

Of course implementing Agile is not a goal. It is a way to help achieve improvement in your IT-initiatives. Reaching the desired results however is greatly dependant on doing the right things, inspired by the right mindset. An early warning that things might turn out less successful than expected is when people say: ‘Yes we do Agile, but…’. Saying you want to do Agile as an organization is one thing. Really doing it is quite another. To get a grip on reality it sometimes helps to state what you should do to fail miserably. This is exactly what the AgileBut Manifesto shown in Figure 25 is all about.
Figure 25: The AgileBut Manifesto