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