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