Iterations in Time

This is part 4 of 4 of a post on how to iterate in RUP. The introduction to this post can be found at ScrumUP Fairytale - Part 4.

By now we are able to see how the content of several Sprints hangs together. In the Preparation Workflow, the Team prepares to get Stories ready for development. The Planning Meeting and subsequent development of a story starts before preparation is complete. Before the Planning Meeting just enough preparation is done for the team to be able to Poker the Story. In early development Subject Matter Experts look at the solution under construction and fill in details where needed. Development starts before requirements are complete.
Figure 13 shows that the Team works together in two subsequent Sprints: the first for getting Ready, the next for getting things Done. To finish the cyclic process, the customer accepts the team’s work in the Sprint directly subsequent to Development. Hence, in one Sprint your Team has to spend time to prepare next Sprint, get the items for this Sprint Done and support acceptance activities.

Figure 50: Sprints and workflows in time

The introduction to this post can be found at ScrumUP Fairytale - Part 4
Part 1 of this post is Get Ready to Poker.
Part 2 of this post is Get Things Done.
Part 3 of this post is Experience the Product.

Other Relevant Posts:
Maintain Stability using XP

Improve

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

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

Maintain Stability using XP

A dominant part of software development and maintenance is adding new or changed features to existing code. This means that the cost of software development and maintenance is in part determined by the maintainability and stability of the code. This is one of the messages the Manifesto for Software Craftsmanship, as shown in Figure 15, is trying to bring across. Delivering well-crafted software is the only way to ensure that business value can be added at a steady, predictable, cost-efficient pace throughout the solution's lifecycle.

Figure 15: Manifesto for Software Craftsmanship

XP is a popular Agile method containing specialist practices for maintaining stability and working on quality. It's practices are inspired by widely used and proven ways of working, taking them to their extremes and leaving out all others that don't directly add value for the customer. In this section we will look at some of the XP practices that are directly concerned with delivering and maintaining quality and aren't addressed in Scrum, RUP or the Agile mindset in general.

Comparing Methods

Up till now we have discussed two Agile methods (Scrum and XP) and RUP as an iterative but more process oriented method. In this section we will compare these methods and investigate how they could enhance each other.

Introducing Agile

In the mid 1990’s, as a reaction to heavyweight waterfall based processes, some other methods emerged. Good examples of these methods are DSDM, RAD, Crystal, XP and Scrum. Not that the people behind them were against process. They just strived to free themselves of Dilbert-like manifestations of process in corporate life, of people hiding behind pointless regulations, managers disrupting the working environment and enforcing unfounded plans and teams producing hundreds of pages of documentation that were impossible to maintain and hardly ever used. They strived for cooperation instead of throwing the result of hard work over a cubicle wall without a proper transfer session and without a clue of what the person on the other side of that wall would be going to do with it.

Following a Method

It is important to have an appropriate process or method. Following a method provides a team with a common vocabulary to express complex concepts which would otherwise take a lot of time to explain. Furthermore, a method provides responsibilities (assigned to roles) so team members know what to expect from each other without spending a lot of time arguing about it. Methods provide a way to utilize experiences from others so a team can avoid spending a lot of time reinventing the wheel.

ScrumUP Fairytale - Part 2

The Soup Stone – 2: Something odd…


There is something odd going on though, because every time he sees a little settlement it is followed by a piece of wasteland and then a little settlement again. This pattern continues for quite some time along the road he is following. There are only little paths leading from each little settlements to the main road, never from one settlement to another. As the soldier approaches a city he notices the little settlements start to be closer together and more and more settlements appear. But the pattern of pieces of wasteland between each settlement is never broken. Although the settlements are getting closer and closer together there are still no paths between them.

Scope of this Blog

When organizations start thinking of implementing a new method, this means they are not happy with the way things are currently going. The discontent may stem from:

• too little process, causing chaos and misunderstanding;
• a very rigid process, causing people to feel constrained and hindered in effectively doing their job;
• a lack of timely feedback and focus on working software in the process, causing dissatisfied customers and overruns in delivery;
• too much pressure on the team and measures like working overtime, causing concessions to software quality and maintainability and dissatisfied team members.

ScrumUP Fairytale - Part 1

The Soup Stone – 1: At the beginning…


Once upon a time in a land far far away a soldier served in the king's army, or the emperor's or sultan's. History is not really clear on that point. In this land a conflict had been going on for many years, that cost a lot of people their lives and made even more people miserable. Our soldier played a very important role in finding a peaceful solution to this conflict which is quite an accomplishment since this hadn't been part of his training as a soldier. But that's another story and should be told another time.