DevOps Games - XP Days 2013 Workshop

At the XP Days conference on Novemer 29. 2013 in Belgium, Jan_Sake Kruis and Remi-Armand Collaris (both Agile coaches) present a workshop called "DevOps Games".
Here we have published:

• An abstract of that session
• The presentation on SlideShare
• Aditional resources

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

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