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

Experience the Product

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

We now take a closer look at the accepting side of the process. Since software delivery is a cyclic process, acceptance is conducted in a cyclic manner as well. Although Subject Matter Experts and the Product Owner have already been involved in the software development cycle, it is now time for the accepting organization to have a thorough look at the increment built and to get stakeholders (customer, users, administrators) to experience and familiarize themselves with the product and give feedback on it.

In Figure 46 and Figure 47 we build up a workflow explaining a RUP based process of getting the product accepted and the receiving organization to familiarize themselves with it. A key to the symbols used in this workflow can be found here.

Figure 46: Acceptance Workflow – install the Product

Get Things Done

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

To get a story done it has to be implemented and as near to production quality as the team can get it. For this the team has to build software and test it. Scrum provides little guidance for the team on how to do that accept for saying the team has to self-organize. XP provides a set of day-to-day practices and stresses that the team as a whole should feel responsible for the Sprint result. This still means the team has to devide tasks in a way that ensures that the customer will get the most value out of each working day.

In Figure 41 through Figure 43 we build up a workflow explaining a RUP based process of software development and testing you can follow to get a Usable Increment done. A key to the symbols used in this workflow can be found in here.



Input to this workflow is an agreed set of Use Cases or Use Case scenarios that are pokered and forecasted to be done by the end of this Sprint.

Figure 41: Development Workflow -- implementing

Get Ready to Poker

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

The term “Ready to Poker” means that the team is ready to estimate a story from the Product Backlog in such detail that they can accurately forecast if its implementation will fit in the upcoming Sprint. Stories to be prepared by the team so they can be pokered are the ones at the top of the Product Backlog (and sometimes explicitly planned in the Sprint Backlog). The best way to get a story Ready to Poker is for the team to be actively involved in preparing this story for implementation. Team members playing the role of Analyst, Developer and Tester work together with Subject Matter Experts, who represent the business. Starting point for these activities is the short description of a Use Case from the Use Case Model, describing what the user wants to do with the system and why. The activities involve detailing requirements so the team knows what the user wants, preparing test cases so the team knows how the solution will be accepted and do some designing so the team knows how to get to a solution. In Figure 35 through Figure 38 we build up a workflow explaining a RUP based process you can follow to get Ready to Poker. A key to the symbols used in this workflow can be found in here.

The Analyst has several sessions or workshops with the relevant Subject Matter Experts. His starting point is the brief Use Case description in the Use Case Model, together with relevant user interface and navigation guidelines found in the Navigation Map. We briefly introduced these work products in the blog post Gather Requirements the Agile Way and treat them more fully in an upcomming blog post No Magic. Assume for this moment that they, as the phrasing is, ‘magically appear’.

Figure 35: Preparation Workflow – scenarios

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

ScrumUP Fairytale - Part 4

The Soup Stone – 4: They seem curious…

While he is sitting there, from the corner of his eye he sees little children coming from the little townships and saunter onto the square. They come closer and closer very carefully. In their eyes he sees something he hasn't seen in the eyes of the grown-ups: they seem curious. Without saying a word the little children stop and sit down a few meters from where he is sitting. They don't speak to him and they surely don't speak to each other. There are children with green hair, green shoes and green clothes, children with red hair, red shoes and red clothes and children with orange hair, orange shoes and orange clothes.

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

Gather Requirements the Agile Way

In the post Self-organize using Scrum we saw that Scrum supposes that the Product Owner can fill the Product Backlog with stories, ordered by the desired sequence of implementation. Furthermore Scrum supposes that the team estimates these stories and comes up with a Definition of Done that will ensure a common understanding of the desired quality constraints. It doesn’t say where the information comes from that is needed to do these things. Speaking with Jeff Sutherland (one of the founders of Scrum) – “this stuff magically appears”. In this section we will look at the way Agile requirements practices can help in this regard.

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

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.

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.

The Agile Spirit

All Agile methods are guided by the Agile Manifesto and the Agile Principles. The Agile Manifesto takes 8 aspects of software development and compares the focus they should receive. A way to check if the Agile spirit is present is to bring a development team, management and stakeholders together. Write these 8 aspects on sticky notes as shown in Figure 5 and randomly put them on a flip-over or whiteboard. Then have every participant divide 5 marks over these aspects, reflecting his personal sense of value of these aspects in reaching the project goal (a happy customer). You can try this exercise for yourself. Which 5 aspects have you marked?

Figure 5: Agile Values Exercise

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.

Introducing RUP

In the late 80s and early 90s Ivar Jacobson, James Rumbaugh and Grady Booch, also called the three amigos, were each working on combining object oriented modeling and iterative development. The Rational Software Corporation, a software vendor specialized in tooling to support software development, brought them together. Their mission was to unify their methods.

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.

A Short History

Software development started with the arrival of the first computers in the 1960’s. Programming started to be hard-wired (fixed programming) or soft-wired (reprogramming was possible by changing the position of plugs). Later, programs could be fed to the computer. First in binary code, then assembler languages were developed (second generation) which were more readable to programmers. The next step in programming was the introduction of procedural languages (third generation) like Cobol and Basic. Although these languages were even closer to the human language and hide a lot of low level procedures and direct addressing of memory from the programmer, they were still modeled close to how a computer works, performing a number of tasks in the right order to get to the right result. But since computers were mainly concerned with heavy data processing and number crunching in those days, procedural languages worked fine.

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.