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

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

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.

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 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.

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.