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

Be Transparent

This is part 3 of 3 posts on Scrum. Part 2 of this post is Learn the Scrum Rules of Play.

An important part of being transparent is played by having a transparent way of working. This helps alignment in the team and with its surroundings and enables discussions on improvement. In the next few postswe will introduce two tools for recording and enabling discussions on a way of working: the workflow and the collaboration matrix. A workflow provides a high level, semi sequential representation of (a part of) a process. It brings together roles, tasks and work products in a concise manner. A collaboration matrix gives an overview of knowledge and skills needed for certain work products.

Let’s start with a workflow of a process we already know: the Scrum process. In Figure 31 through Figure 34 we gradually build up a workflow of the Scrum Process. Furthermore we show explicit activities for the Product Owner and Scum Master to clarify their role in the Sprint. A key to the symbols used in this workflow can be found in Appendix C.

In the blog post Learn the Scrum Rules of Play we saw a number of Scrum elements that help the business and the team to be transparent. The Product Owner role provides the team with a single point of contact for decisions about requirements and order of implementation. The Product Backlog gives a clear overview of the work remaining toward the goal of the release or project. The Definition of Done shows which criteria must be met before a story will be delivered as part of a Usable Increment. The Sprint Backlog gives a clear overview of what the team forecasts to get done in a Sprint and how they plan to do that. Figure 31 shows these Scrum elements and their connection.

Figure 31: Scrum Workflow - Plan the Sprint

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

The New New Scrum Rules of Play

(Deze blogpost is ook beschikbaar in het Nederlands)
Ten years after the creation of the Agile Manifesto and the publication of the first book on Scrum, sixteen years after the first presentation of Scrum at OOPSLA'95 and Twenty Five years after the publication of a scientific article that inspiered the name Scrum, the new Scrum Guide 2011 by Ken Schwaber and Jeff Sutherland is out. It has some great new insights to offer. In this post we will take a brief look at the history of Scrum, see what this new Scrum Guide has to offer and visualize the New New Scrum Rules of Play. This can be of interest to people with some knowledge of Scrum but can hold insights for experienced Scrum practitioners as well.

Figure 10: Relay Race versus Rugby

Learn the Scrum Rules of Play

This is part 2 of 3 posts on Scrum. Part 1 of this post is Self-organize using Scrum.

The power of Scrum is that it is such a simple framework. To describe the Scrum process just 12 concepts suffice, divided as:

• 3 roles
• 4 work products
• 5 time-boxed events

Within a Scrum Team, Scrum recognizes three roles as depicted in Figure 13.

Figure 13: Scrum Roles

Self-organize using Scrum

This is part 1 of 3 posts on Scrum.

Scrum is a framework for self-organization of Agile teams. Although this seems a simple statement we are going to repeat it:

Scrum is a framework 

for self-organization 

of Agile teams

Let’s take a closer look at the three parts of this statement.

ScrumUP Fairytale - Part 3

The Soup Stone – 3: An empty square…

The people all look tired and skinny. The houses are decaying and the farmland looks bare although there are crops growing on it. There seems to be a lot of poverty in this curious place.

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.