tag:blogger.com,1999:blog-89065466162924469752024-03-16T02:10:01.346+01:00ScrumUPA Visual Blog on IT ImprovementRemi-Armand Collarishttp://www.blogger.com/profile/07222991176549637007noreply@blogger.comBlogger31125tag:blogger.com,1999:blog-8906546616292446975.post-44194569319660302042013-12-10T23:45:00.000+01:002013-12-10T23:45:11.545+01:00The T-Shaped Tester<div dir="ltr" style="text-align: left;" trbidi="on">
At the TestNet kennisavond on Decemer 11. 2013 in Nieuwegein NL, Remi-Armand Collaris (Agile Facilitator and Coaches at Ordina) gave the key-note called "The T-Shaped Tester".<br />
Here we have published:<br />
<br />
<ul style="text-align: left;">
<li>The presentation on SlideShare (NL)</li>
<li>Aditional resources</li>
</ul>
<br />
<a name='more'></a><h4 style="text-align: left;">
Presentation (NL)</h4>
<iframe frameborder="0" height="400" marginheight="0" marginwidth="0" scrolling="no" src="http://www.slideshare.net/slideshow/embed_code/29087983" width="476"></iframe><br />
<div>
<br /></div>
<div>
<br /></div>
<h4 style="text-align: left;">
Movie</h4>
<iframe allowfullscreen="" frameborder="0" height="315" src="//www.youtube.com/embed/FSIkjNaICsg" width="420"></iframe></div>
Remi-Armand Collarishttp://www.blogger.com/profile/07222991176549637007noreply@blogger.com54tag:blogger.com,1999:blog-8906546616292446975.post-19301732551182132272013-11-28T20:43:00.003+01:002013-12-02T00:06:36.904+01:00DevOps Games - XP Days 2013 Workshop<div dir="ltr" style="text-align: left;" trbidi="on">
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".<br />
Here we have published:<br />
<ul>
<li style="margin: 0px 0px 0.25em; padding: 0px;">An abstract of that session</li>
<li style="margin: 0px 0px 0.25em; padding: 0px;">The presentation on SlideShare</li>
<li style="margin: 0px 0px 0.25em; padding: 0px;">Aditional resources</li>
</ul>
<a name='more'></a>According to Gartner DevOps is on the virge of breaking through from some large cloud based organizations to the mass of top 2000 companies worldwide. A perfect time to learn more about it.<br />
DevOps integrates Development and Operations. Its aim is to get application changes and additions to production much faster. This enables the business to drastically reduce time-to-market and start realising benefits faster. It also enables the business to boosting innovation by experimenting in production with minimal risks.<br />
Are you curious, in for a game and a new DevOps retrospective tool, find out more in our presentation!<br />
<br />
<h2>
Presentation
</h2>
<iframe frameborder="0" height="400" marginheight="0" marginwidth="0" scrolling="no" src="http://www.slideshare.net/slideshow/embed_code/28764754" width="476"></iframe><br />
<br />
<h2>
Movie "Streets of Hanoi"
</h2>
<iframe allowfullscreen="" frameborder="0" height="315" src="//www.youtube.com/embed/oetF3UTIwbc" width="420"></iframe><br />
<br />
<h2>
Movie "Streets of Urtecht"
</h2>
<iframe allowfullscreen="" frameborder="0" height="315" src="//www.youtube.com/embed/sjw3mraskoE" width="420"></iframe><br />
<br />
<h2>
Movie "Shared Space in Drachten"
</h2>
<iframe allowfullscreen="" frameborder="0" height="315" src="//www.youtube.com/embed/3Wte5-_gCDQ" width="420"></iframe><br />
<br />
<h2>
Downloads
</h2>
<a href="http://www.scrumup.com/dialoguesheets.html" target="_blank">Dialogue Sheet - Value Stream Map and Saboteur Game Board</a><br />
<br />
<a href="http://creativecommons.org/licenses/by-sa/4.0/" rel="license"><img alt="Creative Commons License" src="http://i.creativecommons.org/l/by-sa/4.0/88x31.png" style="border-width: 0;" /></a><br />
<span href="http://purl.org/dc/dcmitype/StillImage" property="dct:title" rel="dct:type" xmlns:dct="http://purl.org/dc/terms/">Presentation and downloads</span> by <a href="http://www.scrumup.com/" property="cc:attributionName" rel="cc:attributionURL" xmlns:cc="http://creativecommons.org/ns#">Remi-Armand Collaris</a> are licensed under a <a href="http://creativecommons.org/licenses/by-sa/4.0/" rel="license">Creative Commons Attribution-ShareAlike 4.0 International License</a>.
</div>
Remi-Armand Collarishttp://www.blogger.com/profile/07222991176549637007noreply@blogger.com60tag:blogger.com,1999:blog-8906546616292446975.post-89743733384919504862013-11-15T18:24:00.000+01:002013-12-20T19:05:24.827+01:00Estimation Game (2)<div dir="ltr" style="text-align: left;" trbidi="on">
<h4 style="text-align: left;">
The Round Trip Version</h4>
This is part 2 of 2 of a post on early estimation in Agile projects. To this end we introduce the Estimation Game. The first part of this post described the <a href="http://blog.scrumup.com/2013/11/estimation-game-1.html">Basic Version of the Estimation Game</a>.<br />
<br />
In order to leverage experiences from past
projects, it may be a good idea to involve not only the relative measures of “Small”,
“Medium” and “Large” but to relate them to ‘round trips’ from the user to the
system and back to the user. Suppose you have a user and a system with a screen
on which the actor can interact with the system. A round trip then starts with
a stimulus from the user, he performs some action which is input for the
system. The system processes the input and returns the result to the actor. A
new round trip starts when the user reacts to the result, which in turn is a
new stimulus for the system.<br />
<br />
<a name='more'></a>The concept of a round trip initially came
from the use case points analysis and was called a use case transaction, but
you can use the concept just as well in estimating stories. Stories may contain
user – system interactions, and if so, you can count the amount of round trips.<br />
<div class="Alinea">
<span lang="EN-US"><br /></span></div>
<div class="Alinea">
<span lang="EN-US">Not all stories do contain round trips, for
they might not involve user interaction. Such cases continue to be estimated
relative to other stories on other criteria (as in the first version of the
estimation game). They might also be much more complex than the amount of user
interaction suggests. In that case it is a good idea to split it up and put the
complex logic or interaction with other systems in a separate story.</span></div>
<div class="Alinea">
<span lang="EN-US"><br /></span></div>
<div class="Alinea">
<span lang="EN-US">The estimation game stays just the same, with
one difference: a “Small” user interface based story counts 1-3 round trips, a
“Medium” one counts 4-7 round trips, and a “Large” one counts 8 or more. The
estimation board now looks like figure 69.</span></div>
<div class="Alinea">
<span lang="EN-US"><br /></span></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://scrumup.com/blogimg/ch06/estimation_board_round_trip.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://scrumup.com/blogimg/ch06/estimation_board_round_trip.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 69: Estimation Board in round trip version</td></tr>
</tbody></table>
<div>
Participants have to think of the story they estimate in terms of the number of round trips involved. This often gives an interesting perspective, for the more user(-friendly) interaction you want, the more round trips you need.</div>
<div>
We have seen that people are fairly good at envisioning round trips and sharing their mental pictures of the system in terms of round trips. When later on in the project it turns out that a story is more complex than initially estimated, it is easy to go back to the estimate and explain the difference in terms of the amount of round trips involved – understandable to both stakeholders and team.</div>
<div>
An example: In the early estimation session, a job vacancy search interface was regarded as simple; it was expected that the user would select search criteria from a couple of drop down menus and then fire his selection. Later on, however, it became obvious that the usability of the application would be enhanced if the system could already react to partial selections and update a counter showing the number of job vacancies found for the current search criteria. In other words, what was regarded to be one round trip turned out to be two. So, it first looked like:</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://scrumup.com/blogimg/ch06/round_trip_text_1.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://scrumup.com/blogimg/ch06/round_trip_text_1.png" /></a></div>
<div>
<br /></div>
<br />
<br />
<br />
<span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 10.0pt; line-height: 120%; mso-ansi-language: EN-US; mso-bidi-font-family: "Times New Roman"; mso-bidi-font-size: 12.0pt; mso-bidi-language: AR-SA; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: NL;">But then it was expanded
as follows:</span><br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://scrumup.com/blogimg/ch06/round_trip_text_2.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://scrumup.com/blogimg/ch06/round_trip_text_2.png" /></a></div>
<span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 10.0pt; line-height: 120%; mso-ansi-language: EN-US; mso-bidi-font-family: "Times New Roman"; mso-bidi-font-size: 12.0pt; mso-bidi-language: AR-SA; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: NL;"><br /></span>
<br />
<br />
<br />
<br />
<br />
<br />
<br />
You see the two round trips clearly here. Both stakeholders and team agreed that the initial estimate should therefore be adjusted.<br />
<br />
<h4 style="text-align: left;">
From round trips to hours</h4>
Once you have your user interface based stories estimated on the basis of the number of round trips and others estimated relative to these stories, it is possible to calculate hours. This can be done with the Use Case Points Analysis, which despite its name, can be used for other types of stories just as well.<br />
In the Use Case Points Analysis, the number and weight of the stories identified is the most important component in the calculation of the size of a system. You can balance this size by bringing in a consideration of the system’s technical properties. The size of the system is the starting point for calculating the effort. Effort is balanced by considering the team’s qualifications and other environmental influences.<br />
<br />
This may sound a little complicated, but once you fill in the <a href="http://www.scrumup.com/downloads.html" target="_blank">spreadsheet </a>which accompanies the method, you will see that it is in fact quite straightforward. A “Small” story amounts to 5 Use Case Points, a “Medium” to 10, and a “Large” one to 15. We have experienced that 20 Hours per Use Case Point is a good average.<br />
The estimate obtained in this way is statistical information. On average, a story of the same weight will take the same effort but the actual time spent on each one may vary widely. Also in another sense an estimate in terms of Use Case Points is statistical: it does not work for a small system of, say, 5 stories. It needs at least 20 stories to be reliable. Nevertheless, our experience is that an estimate done in this way is closer to the actual effort spent on a project than an early expert estimate.<br />
<br />
<h4 style="text-align: left;">
Combining Round Trips and Story Points</h4>
The goal of the Early Estimation Game is to create an estimate for the whole of the project. Later on in the project, the team uses Planning Poker in order to get a more fine-grained team estimate in Story Points. This will be the team’s basis for measuring the team’s velocity and determining commitment for a Sprint. Figure 70 shows how a cross-check can be made between the early estimate in Use Case Points (5, 10 or 15) based on round trips and the more fine-grained estimate in Story Points (0, ½ , 1, 2, 3, 5, 8…) resulting from Planning Poker. The Story Points can be taken to be a more fine-grained version of the Use Case Points. Now if it turns out in Planning Poker that a story estimate is wildly out of range, you know that your story has more functionality than was initially envisioned and you may need to adjust your release planning.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://scrumup.com/blogimg/ch06/estimation_board_planning_poker.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://scrumup.com/blogimg/ch06/estimation_board_planning_poker.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 70: Early Estimation and Planning Poker</td></tr>
</tbody></table>
<div>
<div>
Why is it useful to have a mapping between Story Points and round trips?</div>
<div>
<ul style="text-align: left;">
<li>Round trips help the team to maintain a shared understanding of the measure and share this measure with new team members;</li>
<li>An estimate in Story Points is team bound, whereas an estimate in round trips can easily be shared across teams within an organization;</li>
<li>When under pressure, the team feels the urge to increase estimates which will increase the velocity without the teams productivity increasing. The mapping will show this more easily;</li>
<li>In retaining the round trips approach alongside the Story Points, it is quite simple to keep the Subject Matter Experts involved.</li>
</ul>
<br />
<ul style="text-align: left;">
</ul>
</div>
</div>
<h4 style="text-align: left;">
Downloads</h4>
<div>
At our <a href="http://www.scrumup.com/downloads.html" target="_blank">download page</a> you find the Cost Estimation Spreadsheet.</div>
</div>
Remi-Armand Collarishttp://www.blogger.com/profile/07222991176549637007noreply@blogger.com22tag:blogger.com,1999:blog-8906546616292446975.post-77480032788019865032013-11-01T17:11:00.000+01:002013-12-20T19:07:24.120+01:00Estimation Game (1)<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: left;">
Whereas Planning Poker works very well for estimating a Sprint or Release while the team is up and running, it is less useful for an early project estimate. It is hard to get a good feel for the size of a project at the beginning of a project, as the team has not established a measure yet. Moreover, early in a project we don’t have the level of information needed to do a meaningful Planning Poker session.</div>
<br />
For estimating Use Cases or Epics in an early stage (before they are detailed) we use an aproach we call the Estimation Game. It supposes that Use Cases or Epics have been identified and have a brief description. In this post we share our experiences in applying this game. In the Estimation Game the team, users and other stakeholders cooperate to estimate the Product Backlog together.<br />
<br />
<h4 style="text-align: left;">
The Estimation Game – Basic Version</h4>
<a name='more'></a>To get early estimates on a project we invite stakeholder representatives and the members of the Scrum team for an estimation game. Have the stories ready, preferably on cards or stickies so that you can easily move them around on a board. Initially, these stories are on a stack, ordered by business value or some other form of prioritization so that the highest priority story is on top.<br />
<br />
All participants stand in front of a board which looks like the one in Figure 68.<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://scrumup.com/blogimg/ch06/estimation_board_basic.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="http://scrumup.com/blogimg/ch06/estimation_board_basic.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 68 : Estimation Board basic version</td></tr>
</tbody></table>
<div>
<br /></div>
<div>
When it is your turn as a participant you do either of these things:</div>
<div>
<ol style="text-align: left;">
<li>Estimate a new story from the stack by placing it in a column on the estimation board and explain your estimate to the group;</li>
<li>Change an estimate by moving a story from one column to another and explain to the group why you think this estimate is more appropriate;</li>
<li>Add a new story to the stack and explain why you think it is needed.</li>
</ol>
</div>
<div>
Stop adding stories to the estimation board some 15 minutes before the end of the timebox for this meeting (preferably two hours) has been reached but continue changing estimates. The highest priority stories should be on the board by then and a new planning meeting can be scheduled if needed to estimate the remaining stories on the stack. The game is over when all stories are on the board and/or none of the participant feels the need to relocate any more stories.</div>
<div>
<br /></div>
<div>
If a story is ping-ponged between two locations three times, take it from the board, mark it and place it at the bottom of the stack. This story needs more investigation before it can be properly estimated. Stories in the “?/XXL” column should also be investigated more, be broken down into smaller stories or labeled as Epics that will be broken down later in the project.</div>
<div>
<br /></div>
<div>
This process makes estimation very concise and orderly. People have to await their turn to add or move a story, and they have to explain their actions to the group, furthering a better shared understanding of the stories.</div>
<div>
<br /></div>
<div>
Expect stories to be split up or joined. This may be seen as choices the participants have during their turn, but in our experience, it is not necessary to state this as a rule. Participants will spontaneously do this when needed.</div>
<div>
<br /></div>
<div>
A very important advantage of doing an estimation game with stakeholders is that they can share their view on the stories and hear why some stories are hard to build while they seem simple from a user perspective. Making estimation a joint effort creates a shared ownership of the estimates. If stories turn out to be heavier later in the project as a result of added features not mentioned during the early estimation session, the impact is more easily accepted by the business.</div>
<div>
<br /></div>
<div>
This is part 1 of 2 of a post on early estimation in Agile projects. To this end we introduce the Estimation Game. The second part of this post described the <a href="http://blog.scrumup.com/2013/11/estimation-game-2.html">Round Trip Verson of the Estimation Game</a>.</div>
<div>
<br /></div>
<div>
<br /></div>
<br />
<div>
<br /></div>
</div>
Remi-Armand Collarishttp://www.blogger.com/profile/07222991176549637007noreply@blogger.com11tag:blogger.com,1999:blog-8906546616292446975.post-77812068651113963922013-03-08T13:41:00.002+01:002013-03-08T14:22:38.633+01:00The Soup Stone - Catalyst to Agile Adoption<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
At the Agile Dev Practices conference on March 4. - 7. 2012 in Berlin, Germany I present a workshop called "The Soup Stone - Catalyst to Agile Change".<br />
<br />
Here I have published:<br />
<ul style="text-align: left;">
<li>An abstract of that session</li>
<li>The presentation on SlideShare</li>
<li>Aditional resources</li>
</ul>
<br />
<br />
It is on debate how many Agile implementations fail, but quite a few do. What is holding organizations back? Is it fear or something else? How can I help my organization?<br />
<br />
In this session we interactively investigated what motivates people to change their behavior, as this is the basis for organizational change. What can drive management and team members to become more Agile. And then there was the fairytale of the Soup Stone.<br />
<br />
<a name='more'></a><br />
The objective of this session was to make participants more aware of the organizational environment they are in. They learned about the change model of the Elephlant and its Rider (from the book Switch) in a fun way. They used this model to inspire more effective ways of introducing new Agile practices.<br />
<br />
<br />
<iframe allowfullscreen="" frameborder="0" height="470px" marginheight="0" marginwidth="0" mozallowfullscreen="" scrolling="no" src="http://www.slideshare.net/racollaris/slideshelf" style="border-style: none;" webkitallowfullscreen="" width="615px"></iframe>
</div>
Remi-Armand Collarishttp://www.blogger.com/profile/07222991176549637007noreply@blogger.com11tag:blogger.com,1999:blog-8906546616292446975.post-36865628793882038992012-12-02T17:42:00.003+01:002013-04-27T16:40:41.644+02:00Agile Contracting Games<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
At the XP Days on November 29. and 30. 2012 in the netherlands and the Mini XP Day on April 26. in Belgium we present a workshop called "Agile Contracting Games - Experience What It Takes to Build a Cooperative Environment". In this workshop we play card games to investigate the topic of Agile contracting.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://scrumup.com/blogimg/xpdays2012/xpdays2012acg-intro.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="Agile Contracting Games - Intro" border="0" src="http://scrumup.com/blogimg/xpdays2012/xpdays2012acg-intro.png" title="Agile Contracting Games - Intro" /></a></div>
<br />
Below you find the presentation and some related links.<br />
<a name='more'></a><br />
<iframe allowfullscreen="allowfullscreen" frameborder="0" height="356" marginheight="0" marginwidth="0" mozallowfullscreen="mozallowfullscreen" scrolling="no" src="http://www.slideshare.net/slideshow/embed_code/15451984" style="border: 1px solid rgb(204, 204, 204); margin-bottom: 5px;" webkitallowfullscreen="webkitallowfullscreen" width="427"> </iframe> <br />
<div style="margin-bottom: 5px;">
<strong> <a href="http://www.slideshare.net/racollaris/agile-contracting-games-xp-days-2012" target="_blank" title="Agile contracting games (xp days 2012)">Agile contracting games (xp days 2012)</a> </strong> from <strong><a href="http://www.slideshare.net/racollaris" target="_blank">racollaris</a></strong> <br />
<br />
<strong>Other Relevant Posts: </strong><br /><a href="http://blog.scrumup.com/2012/11/top-ten-reads-on-agile-contracts.html">Top Ten Reads on Agile Contracts</a><br />
<a href="http://blog.scrumup.com/2012/11/agile-contract-scan.html">Agile Contract Scan </a></div>
<br />
<div>
<br /></div>
</div>
Remi-Armand Collarishttp://www.blogger.com/profile/07222991176549637007noreply@blogger.com269tag:blogger.com,1999:blog-8906546616292446975.post-70981132427177708842012-11-24T21:33:00.000+01:002013-04-27T16:40:25.273+02:00Agile Contract Scan<div dir="ltr" style="text-align: left;" trbidi="on">
This is part 2 of 2 of a post on Agile contracting. Part 1 is called <a href="http://blog.scrumup.com/2012/11/top-ten-reads-on-agile-contracts.html">Top Ten Reads on Agile Contracts</a>.<br />
<br />
A lot of publications on Agile contracts handle payment models or topics for the contract but not the mindset it reflects. When starting a new Agile initiative however, wouldn't it be nice if the contract would reinforce the Agile mindset as well? In this post we suggest elements for a scan you can use to assess a contract. Involving stakehoders in such a scan will spring improvement ideas that they will themselves support.<br />
<a name='more'></a>The basis for this scan are Agile principles and values . In previous posts we talked about the <a href="http://blog.scrumup.com/2011/06/agile-spirit.html">Agile Manifesto</a> and the <a href="http://blog.scrumup.com/2011/07/maintaining-stability.html">Manifesto for Software Craftsmanship</a> as value systems that can be used for this purpose. We talked about six <a href="http://blog.scrumup.com/2011/07/maintaining-stability.html">XP practices for maintaining stability</a> on a daily basis and <a href="http://blog.scrumup.com/2011/10/test-your-agility.html">XP’s Bill of Rights</a>. We also introduced the <a href="http://blog.scrumup.com/2011/10/test-your-agility.html">Nokia Test</a> as a set of prerequisites for a team to be Agile. Furthermore RUP has 6 key principles that group twenty-five patterns for Business-Driven Development, <a href="http://blog.scrumup.com/2011/10/test-your-agility.html" target="_blank">OpenUP</a> has four core principles grouping twenty-four practices. Using these value systems we devised a set of <a href="http://blog.scrumup.com/2011/10/improve.html">Unified Principles for Iterative and Agile IT Development</a>. Since contracts often form the starting point of and provide direction to IT development initiatives it makes sence to use these Unified Principles as a startingpoint for an Agile Contract Scan. Using these values we came to the following list of statements about a contract to assess its support of an Agile way of working:<br />
<ol>
<li>The contract reinforces that scope is negotiable.</li>
<li>The contract reinforces that self-organizing, hybride teams are formed.</li>
<li>The contract reinforces embracing of change.</li>
<li>The contract reinforces openness and transparancy.</li>
<li>The contract reinforces a continuous focus on improving the teams effectiveness in delivering business value.</li>
<li>The contract reinforces iteratively delivering a usable, production quality (part of the) solution.</li>
<li>The contract reinforces that it will be adapted on a regular basis.</li>
<li>The contract reinforces that costs and benefits are weighed on a regular basis to guide decision making.</li>
</ol>
Let every participating stakeholder assess the validity of each statement on a scale from 1 to 5, 1 meaning 'I totally disagree' and 5 meaning 'I totally agree'. Furthermore let them pinpoint parts of the contract to underpin their assessment of each statement. Then bring all stakeholders together, discuss the results and come up with improvement suggestions as a group.<br />
<br />
Tell us what you think. Any comments and improvement suggestions to this post are more than welcome.<br />
<br />
</div>
Remi-Armand Collarishttp://www.blogger.com/profile/07222991176549637007noreply@blogger.com8tag:blogger.com,1999:blog-8906546616292446975.post-64945137098191907472012-11-21T23:08:00.001+01:002013-04-27T16:27:57.455+02:00Top Ten Reads on Agile Contracts<div dir="ltr" style="text-align: left;" trbidi="on">
At the XP Days on November 29. and 30. 2012 in the netherlands we present a workshop called "<a href="http://blog.scrumup.com/2012/12/agile-contracting-games.html">Agile Contracting Games</a> - Experience What It Takes to Build a Cooperative Environment". In this workshop we play card games to investigate the topic of Agile contracting. <br />
<br />
To follow up on this workshop we are collecting a top ten of links to the greatest reads on Agile Contracts. <br />
<a name='more'></a><br />
<a href="http://agilesoftwaredevelopment.com/blog/peterstev/10-agile-contracts" target="_blank">10 Contracts for your next Agile Software Projet by Peter Steven</a><br />
<br />
<a href="http://www.youtube.com/watch?v=qLez4eCw7KQ" target="_blank">YouTube: Agile Contract Negotiation </a><br />
<br />
<a href="http://www.agilecontracts.org/" target="_blank">Agile contracts primer by Craig Larman and Bas Vodde</a><br />
<br />
<a href="http://alistair.cockburn.us/Agile+contracts" target="_blank">Alistair Cockburn on Agile Contracts</a><br />
<br />
<a href="http://martinfowler.com/bliki/ScopeLimbering.html" target="_blank">Martin Fowler on Scope Limbering and contracts</a><br />
<br />
<a href="http://www.leanessays.com/2002/04/righteous-contracts.html" target="_blank">Mary Poppendieck on Righteous Contracts</a><br />
<br />
<a href="http://coactivate.org/projects/agile-contracts/money-for-nothing-change-for-free" target="_blank">Jeff Sutherland's Money For Nothing, Change For Free</a><br />
<br />
<a href="http://www.xprogramming.com/ftp/Optional+scope+contracts.pdf" target="_blank">Kent Beck's Optional Scope Contracts</a><br />
<br />
We are not at ten yet so help us out...<br />
<br />
Also follow the discussion on the Scrum Practitioners LinkedIn group "<a href="http://www.linkedin.com/nus-trk?trkact=viewQuestionAndAnswers&pk=group_item_detail&pp=1&poster=11124507&uid=5677141633968136192&ut=NUS_DISC&r=&f=0&url=http%3A%2F%2Fwww%2Elinkedin%2Ecom%2FgroupAnswers%3FviewQuestionAndAnswers%3D%26discussionID%3D188420752%26gid%3D52030%26goback%3D%252Egmr_52030%252Egde_52030_member_188420704%26trk%3DNUS_DISC_Q-ttle&urlhash=Hu0q&goback=%2Egmr_52030" target="_blank">Reading suggestions on Agile contracts?</a>"<br />
<br />
A lot of publications on Agile contracts handle payment models or topics for the contract but not the mindset it reflects. When starting a new Agile initiative however, wouldn't it be nice if the contract would reinforce the Agile mindset as well? In the next post on an '<a href="http://blog.scrumup.com/2012/11/agile-contract-scan.html">Agile Contract Scan</a>' we suggest elements for a scan you can use to assess a contract.</div>
Remi-Armand Collarishttp://www.blogger.com/profile/07222991176549637007noreply@blogger.com21tag:blogger.com,1999:blog-8906546616292446975.post-73094333805044399592011-12-30T17:53:00.000+01:002012-03-17T22:31:24.716+01:00Iterations in TimeThis is part 4 of 4 of a post on how to iterate in RUP. The introduction to this post can be found at <a href="http://blog.scrumup.com/2011/11/scrumup-fairytale-part-4.html">ScrumUP Fairytale - Part 4</a>.<br />
<br />
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.<br />
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.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch04/sprints_and_iterative_workflows.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch04/sprints_and_iterative_workflows.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 50: Sprints and workflows in time</td></tr>
</tbody></table>
<br />
The introduction to this post can be found at <a href="http://blog.scrumup.com/2011/11/scrumup-fairytale-part-4.html">ScrumUP Fairytale - Part 4</a><br />
Part 1 of this post is <a href="http://blog.scrumup.com/2011/11/get-ready-to-poker.html">Get Ready to Poker</a>.<br />
Part 2 of this post is <a href="http://blog.scrumup.com/2011/12/get-things-done.html">Get Things Done</a>.<br />
Part 3 of this post is <a href="http://blog.scrumup.com/2011/12/experience-product.html">Experience the Product</a>.<br />
<br />
<strong>Other Relevant Posts:</strong> <br />
<a href="http://blog.scrumup.com/2011/07/maintaining-stability.html">Maintain Stability using XP</a>Remi-Armand Collarishttp://www.blogger.com/profile/07222991176549637007noreply@blogger.com2tag:blogger.com,1999:blog-8906546616292446975.post-25023311087919688922011-12-19T17:21:00.000+01:002012-03-17T22:30:02.591+01:00Experience the ProductThis is part 3 of 4 of a post on how to iterate with RUP. The introduction to this post can be found at <a href="http://blog.scrumup.com/2011/11/scrumup-fairytale-part-4.html">ScrumUP Fairytale - Part 4</a>.<br />
<br />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. <br />
<br />
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 <a href="http://www.scrumup.com/blogimg/ch04/key_to_workflow_symbols.png" target="_blank">here</a>.<br />
<br />
<a href="http://www.scrumup.com/blogimg/ch04/warning_on_workflows.png" imageanchor="1" style="margin-left: 0em; margin-right: 1em;"><img border="0" src="http://www.scrumup.com/blogimg/ch04/warning_on_workflows.png" /></a><br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch04/acceptance_workflow1.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch04/acceptance_workflow1.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 46: Acceptance Workflow – install the Product</td></tr>
</tbody></table>
<div class="separator" style="clear: both; text-align: left;">
</div>
<a name='more'></a>The Product Increment is deployed in the Staging environment of the Customer, in order to subject it to a set of tests the Customer organization has prepared.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch04/acceptance_workflow2.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch04/acceptance_workflow2.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 47: Acceptance Workflow – test the Product</td></tr>
</tbody></table>
Once deployed, the Product Increment is ready to go through a set of tests, executed by the customer. Typically, a functional acceptance test and a user acceptance test are performed. The former is a test in which the functionality is formally checked against the Use Case and acceptance criteria from the Product Acceptance Plan. The latter is a test in which end users and system administrators, typically including the designated Subject Matter Expert, check whether the Increment is what was intended, facilitated by an Acceptance Tester.<br />
<br />
New or changed insights concerning the deployment procedure are recorded in the System Administration Documentation, in order to have an up-to-date deployment procedure. This procedure is tested every time a new increment is deployed. At this point information needed in the maintenance lifecycle of the product is also developed and if necessary, augmented or changed.<br />
<br />
Half way the next Sprint at the latest acceptance of the Sprint result is communicated by the Customer. This may include reports of found off-specs and other findings to be solved and the condition that they are fixed or put into the Product Backlog. If reported early enough the team does its best to have all smaller issues (that don’t interfere with their forecast) fixed before the next Demo. Bigger issues go to the Product Backlog. If the Customer does not react within this term, the Increment is implicitly accepted. Later findings automatically go to the Product Backlog. In this way, cyclic customer collaboration is stimulated.<br />
<br />
Figure 48 gives an overview of stakeholder roles and team roles and the work products they collaborate on to get stakeholders (customer, users, administrators) to experience and familiarize themselves with the product.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch04/acceptance_collaboration_matrix.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch04/acceptance_collaboration_matrix.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 48: Acceptance Collaboration Matrix</td></tr>
</tbody></table>
<div class="separator" style="clear: both; text-align: left;">
Figure 49 positions the Acceptance Workflow relative to an outline of the Scrum process.</div>
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch04/positioning_acceptance.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch04/positioning_acceptance.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 49: Positioning the Acceptance Workflow</td></tr>
</tbody></table>
<br />
The introduction to this post can be found at <a href="http://blog.scrumup.com/2011/11/scrumup-fairytale-part-4.html">ScrumUP Fairytale - Part 4</a><br />
Part 1 of this post is <a href="http://blog.scrumup.com/2011/11/get-ready-to-poker.html">Get Ready to Poker</a>.<br />
Part 2 of this post is <a href="http://blog.scrumup.com/2011/12/get-things-done.html">Get Things Done</a>.<br />
Part 4 of this post is <a href="http://blog.scrumup.com/2011/12/iterations-in-time.html">Iterations in Time</a>.<br />
<br />Remi-Armand Collarishttp://www.blogger.com/profile/07222991176549637007noreply@blogger.com3tag:blogger.com,1999:blog-8906546616292446975.post-16428027450490200082011-12-12T09:00:00.000+01:002012-03-17T22:27:23.146+01:00Get Things DoneThis is part 2 of 4 of a post on how to iterate with RUP. The introduction to this post can be found at <a href="http://blog.scrumup.com/2011/11/scrumup-fairytale-part-4.html">ScrumUP Fairytale - Part 4</a>.<br />
<br />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. <br />
<br />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 <a href="http://www.scrumup.com/blogimg/ch04/key_to_workflow_symbols.png" target="_blank">here</a>.<br />
<br />
<a href="http://www.scrumup.com/blogimg/ch04/warning_on_workflows.png" imageanchor="1" style="margin-left: 0em; margin-right: 1em;"><img border="0" src="http://www.scrumup.com/blogimg/ch04/warning_on_workflows.png" /></a><br />
<br />
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.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch04/development_workflow1.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" rea="true" src="http://www.scrumup.com/blogimg/ch04/development_workflow1.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 41: Development Workflow -- implementing</td></tr>
</tbody></table>
<a name='more'></a>The Developer starts with a story on top of the Sprint Backlog. Any Working Software he builds or changes is code-documented and furnished with relevant programmer tests, conforming to the team’s Definition of Done. It is a very good idea to have several unofficial demos during implementation. This way, Subject Matter Expert, Analyst, Tester and other team members have a natural and low-ceremony overview and can detect possible misunderstandings. This increases the quality and decreases the chance of findings (leading to rework and test effort) later on in the Sprint or thereafter.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch04/development_workflow2.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" rea="true" src="http://www.scrumup.com/blogimg/ch04/development_workflow2.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 42: Development Workflow – testing</td></tr>
</tbody></table>
The Tester tests using the test cases prepared in the foregoing Sprint as soon as the Developer indicates the code is mature enough to do so. The Subject Matter Expert participates in this activity. Any findings are passed to the Developer and fixed in that Sprint whenever possible. Also, easy to fix Acceptance Findings reported during the Acceptance period are taken care of as soon as possible. Bigger, more structural Acceptance Findings are added to the Product Backlog.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch04/development_workflow3.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" rea="true" src="http://www.scrumup.com/blogimg/ch04/development_workflow3.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 41: Development Workflow – Delivering</td></tr>
</tbody></table>
<br />
Toward the end of the Sprint, the Tester summarizes the testing efforts and his view on the readiness of the implemented stories in a Test Report. The Developer prepares a Usable Increment, with Release Notes and relevant System Administration Documentation. Progress is measured in stories that are done and delivered as part of that Usable Increment.<br />
<br />
Figure 44 gives an overview of stakeholder roles and team roles and the work products they collaborate on to get a Usable Increment done.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch04/development_collaboration_matrix.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch04/development_collaboration_matrix.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 44: Development Collaboration Matrix</td></tr>
</tbody></table>
As shown in Figure 45 only Stories that conform to the Definition of Done are built into the Product and shown at the Demo that takes place at the end of the Sprint. In this way, it is always clear what the quality of the Product Increment is. ‘Done’ is quite a meaningful word in Scrum.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch04/positioning_development.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" rea="true" src="http://www.scrumup.com/blogimg/ch04/positioning_development.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 45: Positioning the Development Workflow</td></tr>
</tbody></table>
At this Demo at least the Product Owner and Subject Matter Experts are present. The Product Owner can however invite any stakeholder to see the Sprint result and this way manage expectations. This Demo plays an important part in the acceptance (both emotional and official) of the Product.<br />
<br />
The introduction to this post can be found at <a href="http://blog.scrumup.com/2011/11/scrumup-fairytale-part-4.html">ScrumUP Fairytale - Part 4</a><br />
Part 1 of this post is <a href="http://blog.scrumup.com/2011/11/get-ready-to-poker.html">Get Ready to Poker</a>.<br />
Part 3 of this post is <a href="http://blog.scrumup.com/2011/12/experience-product.html">Experience the Product</a>.<br />
Part 4 of this post is <a href="http://blog.scrumup.com/2011/12/iterations-in-time.html">Iterations in Time</a>.<br />
<br />
<b>Other Relevant Posts: </b><br />
<a href="http://blog.scrumup.com/2011/11/be-transparent.html">Be Transparent</a>Remi-Armand Collarishttp://www.blogger.com/profile/07222991176549637007noreply@blogger.com1tag:blogger.com,1999:blog-8906546616292446975.post-82240106409446955182011-11-28T20:45:00.000+01:002012-03-17T22:29:50.141+01:00Get Ready to Poker<div style="text-align: left;">
This is part 1 of 4 of a post on how to iterate with RUP. The introduction to this post can be found at <a href="http://blog.scrumup.com/2011/11/scrumup-fairytale-part-4.html">ScrumUP Fairytale - Part 4</a>.<br />
<br />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 <a href="http://www.scrumup.com/blogimg/ch04/key_to_workflow_symbols.png" target="_blank">here</a>.<br />
<br />
<a href="http://www.scrumup.com/blogimg/ch04/warning_on_workflows.png" imageanchor="1" style="margin-left: 0em; margin-right: 1em;"><img border="0" src="http://www.scrumup.com/blogimg/ch04/warning_on_workflows.png" /></a></div>
<br />
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 <a href="http://blog.scrumup.com/2011/09/agile-requirements.html">Gather Requirements the Agile Way</a> and treat them more fully in an upcomming blog post No Magic. Assume for this moment that they, as the phrasing is, ‘magically appear’.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch04/preparation_workflow1.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" rea="true" src="http://www.scrumup.com/blogimg/ch04/preparation_workflow1.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 35: Preparation Workflow – scenarios</td></tr>
</tbody></table>
<br />
<a name='more'></a>The first sessions on a particular Use Case is devoted to the goal of the Use Case (Scenario) at hand and the steps the actor envisions in order to reach that goal. After this session, the Analyst and the Developer work together in making a screen prototype that reflects the input of the Subject Matter Experts. When this screen prototype is presented in the second session and the Subject Matter Experts actually see what they have told the Analyst, more often than not they see what they have taken for granted, omitted or just did not think of. In our experience, this second session is the most exciting as well as the most fruitful. It is one thing to have discussed a scenario, but quite another to have the corresponding screens which you can walk through. To almost anyone, a ‘live’ screen with actual information tells much more than the same information in a descriptive form.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch04/preparation_workflow2.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" rea="true" src="http://www.scrumup.com/blogimg/ch04/preparation_workflow2.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 36: Preparation Workflow – test cases</td></tr>
</tbody></table>
<br />
In parallel the Tester cooperates with the Analyst and Subject Matter Experts to obtain testable Use Case Scenarios. Writing Test Cases for these scenarios helps him find any indistinctness and determine the testability of the Use Case. The Test Cases are written with the acceptance criteria from the Product Acceptance Plan in mind.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch04/preparation_workflow3.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" rea="true" src="http://www.scrumup.com/blogimg/ch04/preparation_workflow3.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 37: Preparation Workflow – design</td></tr>
</tbody></table>
<br />
The Developer walks through the Scenarios, together with the Analyst, to see how it is to be realized in code and to discuss any issues. This may result in changes in the Use Case. A change in this respect ensures that the Use Case can be built with reasonable effort. The Developer of course consults the Software Architect if he has any hesitations about how the architecture should be implemented. The Developer updates the Design to reflect additions or changes made for this Use Case and starts implementing developer tests in the Test Suite for this Use Case.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch04/preparation_workflow4.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" rea="true" src="http://www.scrumup.com/blogimg/ch04/preparation_workflow4.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 38: Preparation Workflow – agreement</td></tr>
</tbody></table>
<br />
Finally, the Product Owner makes sure that all stakeholders agree on the scenarios and that the Team is ready to start developing these.<br />
<br />
Figure 39 gives an overview of stakeholder roles and team roles and the work products they collaborate on to get the team ready to poker.<br />
<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch04/preparation_collaboration_matrix.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch04/preparation_collaboration_matrix.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 39: Preparation Collaboration Matrix</td></tr>
</tbody></table>
<br />
If you think by now: okay, but this is just too much, in our team we reach the Ready to Poker state in a 20 minutes conversation, and that’s it – this is fine. It means that your ‘level of ceremony’ is a bit lower than sketched above. In the meantime, in this 20 minutes conversation you will probably recognize both the roles and the goal mentioned above.<br />
<br />
Figure 40 positions the Preparation Workflow within the cyclic Scrum process. It shows that before a Sprint starts, just enough of this workflow is executed for the team to get Ready to Poker. This means just enough information is gathered to be able to estimate the Stories for this Sprint and give commitment for their development. Execution of the workflow continues after Sprint Planning, parallel to the early development of the Stories.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch04/positioning_preparation.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" rea="true" src="http://www.scrumup.com/blogimg/ch04/positioning_preparation.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 40: Positioning the Preparation Workflow</td></tr>
</tbody></table>
The introduction to this post can be found at <a href="http://blog.scrumup.com/2011/11/scrumup-fairytale-part-4.html">ScrumUP Fairytale - Part 4</a><br />
Part 2 of this post is <a href="http://blog.scrumup.com/2011/12/get-things-done.html">Get Things Done</a>.<br />
Part 3 of this post is <a href="http://blog.scrumup.com/2011/12/experience-product.html">Experience the Product</a>.<br />
Part 4 of this post is <a href="http://blog.scrumup.com/2011/12/iterations-in-time.html">Iterations in Time</a>.<br />
<br /><b>Other Relevant Posts: </b><br />
<a href="http://blog.scrumup.com/2011/09/agile-requirements.html">Gather Requirements the Agile Way</a><br />
<a href="http://blog.scrumup.com/2011/11/be-transparent.html">Be Transparent</a>Remi-Armand Collarishttp://www.blogger.com/profile/07222991176549637007noreply@blogger.com458tag:blogger.com,1999:blog-8906546616292446975.post-42333229307791536322011-11-21T20:51:00.000+01:002012-06-23T00:09:02.123+02:00Be Transparent<div dir="ltr" style="text-align: left;" trbidi="on">
This is part 3 of 3 posts on Scrum. Part 2 of this post is <a href="http://blog.scrumup.com/2011/07/learn-scrum-rules-of-play.html">Learn the Scrum Rules of Play</a>.<br />
<br />
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. <br />
<br />
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 <a href="http://www.scrumup.com/blogimg/ch04/key_to_workflow_symbols.png" target="_blank">Appendix C</a>.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.scrumup.com/blogimg/ch04/warning_on_workflows.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://www.scrumup.com/blogimg/ch04/warning_on_workflows.png" /></a></div>
<br />
In the blog post <a href="http://blog.scrumup.com/2011/07/learn-scrum-rules-of-play.html">Learn the Scrum Rules of Play</a> 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.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch04/scrum_workflow1.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch04/scrum_workflow1.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 31: Scrum Workflow - Plan the Sprint</td></tr>
</tbody></table>
<br />
<a name='more'></a><br />
Figure 32 shows that during the Sprint, the Product Owner keeps track of business needs. The team works on executing their plan and living up to their forecast. Throughout the sprint, the Scrum Master supports and facilitates the team and Product Owner.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch04/scrum_workflow2.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch04/scrum_workflow2.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 32: Scrum Workflow - Daily Work</td></tr>
</tbody></table>
Figure 33 shows that at the end of the Sprint, in the sprint review meeting, the team provides transparency by providing updated estimates throughout the Product Backlog, where needed. At the end of the demo the Product Owner shares his view of remaining stories toward the release or project goal and his plan for reaching that goal. Looking back, the team comes up with two or three spearheads for improvement they are going to try out the next Sprint. The way in which the Team organizes itself is really up to the Team. If it works, keep it that way. If it doesn’t, try something else that works. Always look for more effective ways of doing things. You can use experiences from others, but do it as an experiment to see if it fits your team. That’s Scrum.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch04/scrum_workflow3.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch04/scrum_workflow3.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 33: Scrum Workflow - End of Sprint</td></tr>
</tbody></table>
Now we are going to look at some practices that are not part of Scrum, but are often used to increase transparency. In the workflow shown in Figure 34 we show some work products that are not part of Scrum but have proven useful in a lot of our projects. These include a Sprint Burndown Chart and a Release Burnup Chart (further discussed in Chapter 6 Estimation and Planning) showing the amount of work remaining toward the end of the Sprint and Release respectively. We also added an Impediments List for communicating and keeping track of impediments for the team and a Risk List for communicating and keeping track of perceived risks and counter measures (also found in RUP and PRINCE2).<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch04/scrum_workflow4.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch04/scrum_workflow4.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 34: Scrum Workflow – Supplemental Practices</td></tr>
</tbody></table>
<br />
The Usable Increment that is one of the Scrum work products is not shown here but is explained in the blog post <a href="http://blog.scrumup.com/2011/12/get-things-done.html">Get Things Done</a>.<br />
The fact that Scrum distinguishes no specialist roles within a team, does not mean that the team should consist of only generalists. Most IT efforts are way too complex to pull that off. The notion of roles is useful to communicate the knowledge and skills needed within the team to be able to deliver value to the customer. It can also help in determining which stakeholder representatives to invite to workshops on specific work products. Figure 35 gives an overview of stakeholder roles and team roles and the way they could collaborate to create the Scrum work products we discussed in this section. <br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch04/scrum_collaboration_matrix.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch04/scrum_collaboration_matrix.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 35: Scrum Collaboration Matrix</td></tr>
</tbody></table>
<br />
Just make sure team members are flexible in the roles they play and are prepared to do whatever is necessary to get the job done.<br />
<br />
Part 1 of this post is <a href="http://blog.scrumup.com/2011/07/self-organization.html">Self-organize using Scrum</a>.<br />
Part 2 of this post is <a href="http://blog.scrumup.com/2011/07/learn-scrum-rules-of-play.html">Learn the Scrum Rules of Play</a>.<br />
<br />
<div>
<b>Other Relevant Posts: </b><br />
<div>
<a href="http://blog.scrumup.com/2011/07/maintaining-stability.html">Maintain Stability using XP</a></div>
</div>
</div>Remi-Armand Collarishttp://www.blogger.com/profile/07222991176549637007noreply@blogger.com109tag:blogger.com,1999:blog-8906546616292446975.post-57491394846149131632011-11-07T21:47:00.000+01:002012-03-17T22:29:34.061+01:00ScrumUP Fairytale - Part 4<div style="text-align: center;">
<span class="Apple-style-span" style="color: #0b5394; font-size: large;"><b><i>The Soup Stone – 4: They seem curious…</i></b></span></div>
<div style="text-align: center;">
<span class="Apple-style-span" style="color: #0b5394; font-size: large;"><i><br /></i></span></div>
<div style="text-align: center;">
<span class="Apple-style-span" style="color: #0b5394; font-size: large;"><em>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.</em></span></div>
<div style="text-align: center;">
<span class="Apple-style-span" style="color: #0b5394; font-size: large;"></span></div>
<a name='more'></a><br />
<div style="text-align: center;">
<span class="Apple-style-span" style="color: #0b5394; font-size: large;"><i>After a while the soldier speaks to one of the children. It's a little boy with orange hair and matching shoes and clothes. He says: "I'm hungry, do you think your parents might have something to eat?" The little boy replies: "Well, we don't have much. We only eat carrots because they're ours and we are not allowed to give them to other people." Our soldier gets similar replies from the other children, one saying they only have leek, the other saying they only have tomatoes. Yet another child says they only eat onions because it is all they have. The soldier sees all of the children are looking hungry.<br /><br />Now the soldier notices some grown-ups coming towards the children. It looks like they're coming to collect their children. But he sees a trace of curiosity in their eyes as well. They look at the soldier and the soldier looks at them, looks at himself and then he understands: he is wearing green trousers, but a red jacket, a white shawl and an orange hat. It seems like people are thinking: "How is this possible, all these different colors worn by one single person?"</i></span><br />
<br /></div>
<div>
<b>How to Iterate</b> </div>
<div>
In the previous posts we showed how <a href="http://blog.scrumup.com/2011/07/self-organization.html"><span style="color: #888888;">Scrum</span></a> and <a href="http://blog.scrumup.com/2011/07/maintaining-stability.html"><span style="color: #cc6611;">XP</span></a> are used together to self-organize and maintain a stable product. This helps to deal with the complexity of IT-development and to easily respond to change. We argued that the best thing to do is to iterate, that is, have cycles of constant length and take time to look back on each cycle in order to improve the next.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch04/positioning_scrum_xp_and_rup.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" rea="true" src="http://www.scrumup.com/blogimg/ch04/positioning_scrum_xp_and_rup.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 29: Positioning Scrum and XP</td></tr>
</tbody></table>
Figure 29 shows the core Scrum process with its typical Sprint cycle and Daily cycles. Plotted within this process we show different goals of iterative IT-development that are only partly addressed by Scrum or XP. In this chapter we are going to show how each of these goals can be met using some practices common to Agile and practices from RUP.<br />
<br />
In the post <a href="http://blog.scrumup.com/2011/11/be-transparent.html">Be Transparent</a> we revisit Scrum and add some comon Agile practices.<br />
It is followed by post in 4 parts on how to iterate with RUP: <br />
Part 1 <a href="http://blog.scrumup.com/2011/11/get-ready-to-poker.html">Get Ready to Poker</a>.<br />
Part 2 <a href="http://blog.scrumup.com/2011/12/get-things-done.html">Get Things Done</a>.<br />
Part 3 <a href="http://blog.scrumup.com/2011/12/experience-product.html">Experience the Product</a>.<br />
Part 4 <a href="http://blog.scrumup.com/2011/12/iterations-in-time.html">Iterations in Time</a>.<br />
<br />
<b>Other Relevant Posts: </b><br />
<a href="http://blog.scrumup.com/2011/07/self-organization.html">Self-organize using Scrum</a><br />
<a href="http://blog.scrumup.com/2011/07/maintaining-stability.html">Maintain Stability using XP</a><br />
<br />
</div>Remi-Armand Collarishttp://www.blogger.com/profile/07222991176549637007noreply@blogger.com5tag:blogger.com,1999:blog-8906546616292446975.post-71016329474556109152011-10-24T16:30:00.000+02:002014-06-21T14:34:34.974+02:00Improve<div dir="ltr" style="text-align: left;" trbidi="on">
Perhaps the most important practice for <a href="http://blog.scrumup.com/2011/07/self-organization.html" target="_blank">self-organization</a> within the <a href="http://blog.scrumup.com/2011/07/learn-scrum-rules-of-play.html" target="_blank">Scrum process</a> 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 <a href="http://blog.scrumup.com/2011/10/test-your-agility.html" target="_blank">Nokia Test</a>). Keep in mind however that circumstances will keep changing, so make adapting and improving part of your primary process.<br />
<br />
<iframe allowfullscreen="" frameborder="0" height="315" src="//www.youtube.com/embed/MFLvQXMNrO8" width="560"></iframe>
<br />
<br />
Principles and values help to inspire improvement and pinpoint possible improvement areas. In the previous sections we talked about the <a href="http://blog.scrumup.com/2011/06/agile-spirit.html">Agile Manifesto</a> and the <a href="http://blog.scrumup.com/2011/07/maintaining-stability.html">Manifesto for Software Craftsmanship</a> as value systems that can be used for this purpose. We talked about six <a href="http://blog.scrumup.com/2011/07/maintaining-stability.html" target="_blank">XP practices</a> for maintaining stability on a daily basis and XP’s <a href="http://blog.scrumup.com/2011/10/test-your-agility.html" target="_blank">Bill of Rights</a>. We also introduced the <a href="http://blog.scrumup.com/2011/10/test-your-agility.html">Nokia Test</a> 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, <a href="http://blog.scrumup.com/2011/10/test-your-agility.html" target="_blank">OpenUP</a> has four core principles grouping twenty-four practices. <br />
<br />
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.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch03/unified_principles.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch03/unified_principles.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 27: Unified Principles for Iterative and Agile IT Development</td></tr>
</tbody></table>
<br />
<a name='more'></a><br />
One of the things you can do with it is have people vote for the principles. Have every team member divide 3 marks, reflecting his personal sense of value of these principles and dicess the result.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch03/values_mindmap.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch03/values_mindmap.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 28: Mind Map of Unified Principles</td></tr>
</tbody></table>
Another way to get team involved in the improvement process is to create a mind map with the team starting with the above principles. You can use a whiteboard with colored markers or a collaboration tool that creates mind maps. Start with the above principles in the center as shown in Figure 28 and add detail and practices the team finds helpful further outward. You could also devote a separate mind map to each principle.</div>
Remi-Armand Collarishttp://www.blogger.com/profile/07222991176549637007noreply@blogger.com1tag:blogger.com,1999:blog-8906546616292446975.post-78512310307286476422011-10-12T01:42:00.001+02:002014-06-21T14:36:50.004+02:00Test Your Agility<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
Of course implementing <a href="http://blog.scrumup.com/2011/06/agile-spirit.html">Agile</a> 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.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch03/agilebut_manifesto.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch03/agilebut_manifesto.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span class="Apple-style-span" style="font-size: small;">Figure 25: The AgileBut Manifesto</span></td></tr>
</tbody></table>
<br />
<a name='more'></a><br />
A basic tool to see if a team will be able to self organize and work in an Agile way is provided by the Nokia Test. It defines the minimum prerequisites for a team to call its way of working Agile. It does this in two simple steps. First it determines if the team works iteratively using three simple questions.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.scrumup.com/blogimg/ch03/nokia_phone.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://www.scrumup.com/blogimg/ch03/nokia_phone.jpg" /></a></div>
Does the team work iteratively:<br />
<ul>
<li>Are iterations timeboxed to a maximum of 4 weeks;</li>
<li>Are features tested and usable at the end of each iteration;</li>
<li>Are features clear enough before the planning of an iteration starts.</li>
</ul>
Working iteratively is a prerequisite for the team to be Agile. The test goes on to determine whether the team is working Agile using <a href="http://blog.scrumup.com/2011/07/self-organization.html">Scrum</a> using five simple questions.<br />
<br />
Is the team doing Scrum:<br />
<ul>
<li>Does the team know who the Product Owner is;</li>
<li>Is the Product Backlog ordered and does it provide insight into business value;</li>
<li>Does the Product Backlog have estimates created by the team (using planning poker);</li>
<li>Are the team velocity and work remaining toward the goal known;</li>
<li>Can the team focus on their commitment without disruptions by management (or anyone else);</li>
<li>Is the team able to self organize.</li>
</ul>
<iframe allowfullscreen="" frameborder="0" height="315" src="//www.youtube.com/embed/1yZ3J8C4MK0" width="560"></iframe>
<br />
<br />
<br />
Another powerful tool is the <a href="http://blog.scrumup.com/2011/07/maintaining-stability.html">XP</a> Bill of Rights shown in Tabel 1. It provides a way to see if the right mindset is in place to succeed with Agile by stating basic rights for developer and customer. Looking at this table you will see that they often represent different sides of the same medal, balancing expectations from both sides.<br />
<br />
<br />
<div class="MsoCaption" style="page-break-after: avoid;">
<span lang="EN-US">Tabel </span><span lang="EN-US">1</span><span lang="EN-US">: XP Bill of Rights</span></div>
<table border="1" cellpadding="0" cellspacing="0" class="MsoNormalTable" style="border-collapse: collapse; border: currentColor; mso-border-alt: solid #006699 .5pt; mso-border-insideh: .5pt solid #006699; mso-border-insidev: .5pt solid #006699; mso-padding-alt: 0cm 5.4pt 0cm 5.4pt; mso-yfti-tbllook: 1184;"><tbody>
<tr><td style="border: 1pt solid rgb(0, 102, 153); mso-border-alt: solid #006699 .5pt; padding: 0cm 5.4pt; width: 215pt;" valign="top" width="287"><div align="center" class="MsoNormal" style="text-align: center;">
<b><span lang="EN-US">Developer Bill of Rights</span></b></div>
</td><td style="border: 1pt solid rgb(0, 102, 153); mso-border-alt: solid #006699 .5pt; mso-border-left-alt: solid #006699 .5pt; padding: 0cm 5.4pt; width: 215pt;" valign="top" width="287"><div class="MsoNormal" style="margin-left: 36pt;">
<b><span lang="EN-US">Customer Bill of Rights</span></b></div>
</td></tr>
<tr><td style="border: 1pt solid rgb(0, 102, 153); mso-border-alt: solid #006699 .5pt; mso-border-top-alt: solid #006699 .5pt; padding: 0cm 5.4pt; width: 215pt;" valign="top" width="287"><div class="MsoNormal">
<span lang="EN-US">You have the right to know what is needed with clear declarations of priority.</span></div>
</td><td style="border-color: currentColor rgb(0, 102, 153) rgb(0, 102, 153) currentColor; border-style: none solid solid none; border-width: medium 1pt 1pt medium; mso-border-alt: solid #006699 .5pt; mso-border-left-alt: solid #006699 .5pt; mso-border-top-alt: solid #006699 .5pt; padding: 0cm 5.4pt; width: 215pt;" valign="top" width="287"><div class="MsoNormal">
<span lang="EN-US">You have the right to an overall plan, to know what can be accomplished when and at what cost.</span></div>
</td></tr>
<tr><td style="border: 1pt solid rgb(0, 102, 153); mso-border-alt: solid #006699 .5pt; mso-border-top-alt: solid #006699 .5pt; padding: 0cm 5.4pt; width: 215pt;" valign="top" width="287"><div class="MsoNormal">
<span lang="EN-US">You have the right to produce quality work at all times.</span></div>
</td><td style="border-color: currentColor rgb(0, 102, 153) rgb(0, 102, 153) currentColor; border-style: none solid solid none; border-width: medium 1pt 1pt medium; mso-border-alt: solid #006699 .5pt; mso-border-left-alt: solid #006699 .5pt; mso-border-top-alt: solid #006699 .5pt; padding: 0cm 5.4pt; width: 215pt;" valign="top" width="287"><div class="MsoNormal">
<span lang="EN-US">You have the right to get the greatest possible value out of every programming week.</span></div>
</td></tr>
<tr><td style="border: 1pt solid rgb(0, 102, 153); mso-border-alt: solid #006699 .5pt; mso-border-top-alt: solid #006699 .5pt; padding: 0cm 5.4pt; width: 215pt;" valign="top" width="287"><div class="MsoNormal">
<span lang="EN-US">You have the right to ask for and receive help from peers, superiors, and customers.</span></div>
</td><td style="border-color: currentColor rgb(0, 102, 153) rgb(0, 102, 153) currentColor; border-style: none solid solid none; border-width: medium 1pt 1pt medium; mso-border-alt: solid #006699 .5pt; mso-border-left-alt: solid #006699 .5pt; mso-border-top-alt: solid #006699 .5pt; padding: 0cm 5.4pt; width: 215pt;" valign="top" width="287"><div class="MsoNormal">
<span lang="EN-US">You have the right to see progress in a running system proven to work by passing repeatable tests that you specify.</span></div>
</td></tr>
<tr><td style="border: 1pt solid rgb(0, 102, 153); mso-border-alt: solid #006699 .5pt; mso-border-top-alt: solid #006699 .5pt; padding: 0cm 5.4pt; width: 215pt;" valign="top" width="287"><div class="MsoNormal">
<span lang="EN-US">You have the right to make and update your own estimates.</span></div>
</td><td style="border-color: currentColor rgb(0, 102, 153) rgb(0, 102, 153) currentColor; border-style: none solid solid none; border-width: medium 1pt 1pt medium; mso-border-alt: solid #006699 .5pt; mso-border-left-alt: solid #006699 .5pt; mso-border-top-alt: solid #006699 .5pt; padding: 0cm 5.4pt; width: 215pt;" valign="top" width="287"><div class="MsoNormal">
<span lang="EN-US">You have the right to change your mind, to substitute functionality, and to change priorities without paying exorbitant costs.</span></div>
</td></tr>
<tr><td style="border: 1pt solid rgb(0, 102, 153); mso-border-alt: solid #006699 .5pt; mso-border-top-alt: solid #006699 .5pt; padding: 0cm 5.4pt; width: 215pt;" valign="top" width="287"><div class="MsoNormal">
<span lang="EN-US">You have the right to accept responsibilities instead of having them assigned to you.</span></div>
</td><td style="border-color: currentColor rgb(0, 102, 153) rgb(0, 102, 153) currentColor; border-style: none solid solid none; border-width: medium 1pt 1pt medium; mso-border-alt: solid #006699 .5pt; mso-border-left-alt: solid #006699 .5pt; mso-border-top-alt: solid #006699 .5pt; padding: 0cm 5.4pt; width: 215pt;" valign="top" width="287"><div class="MsoNormal">
<span lang="EN-US">You have the right to be informed of schedule changes in time to choose how to reduce the scope to restore the original date. </span></div>
</td></tr>
<tr><td style="border: 1pt solid rgb(0, 102, 153); mso-border-alt: solid #006699 .5pt; mso-border-top-alt: solid #006699 .5pt; padding: 0cm 5.4pt; width: 215pt;" valign="top" width="287"><div class="MsoNormal">
<br /></div>
</td><td style="border-color: currentColor rgb(0, 102, 153) rgb(0, 102, 153) currentColor; border-style: none solid solid none; border-width: medium 1pt 1pt medium; mso-border-alt: solid #006699 .5pt; mso-border-left-alt: solid #006699 .5pt; mso-border-top-alt: solid #006699 .5pt; padding: 0cm 5.4pt; width: 215pt;" valign="top" width="287"><div class="MsoNormal">
<span lang="EN-US">You can cancel the project at any time and be left with a useful working system reflecting the investment to date.</span></div>
</td></tr>
</tbody></table>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<span lang="EN-US"></span><br /></div>
<div class="MsoNormal">
The message here is simple: make sure you pass the Nokia Test and that your actions adhere to the basic rights stated in the XP Bill of Rights before expecting major benefits from the use of any Agile or iterative method.</div>
<br />
<br /></div>
Remi-Armand Collarishttp://www.blogger.com/profile/07222991176549637007noreply@blogger.com1tag:blogger.com,1999:blog-8906546616292446975.post-88489762120680100802011-09-19T09:00:00.000+02:002012-10-17T18:09:57.390+02:00Gather Requirements the Agile Way<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
In the post <span class="Apple-style-span" style="background-color: white;"><a href="http://blog.scrumup.com/2011/07/self-organization.html">Self-organize using Scrum</a></span> 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.<br />
<br />
<a name='more'></a>Agile requirements focus on what the user can do with the system rather than on what the system can do. Traditionally developers tend to decompose a system to be built into functions of the system. They are faced with the problem of building a complex system. To solve this problem they divide it into smaller problems until they reach a granularity of problems that are solvable. Although this is helpful for the developers, it doesn’t help users much in getting a clear view on their needs and what a solution could look like that that meets these needs. When users are confronted with a collection of functions in a traditional functional design, it is hard for them to imagine how they could use these functions to help them do their daily jobs. This diminishes their readiness to be involved.<br />
<br />
Within iterative and Agile software development there are two approaches for capturing and detailing requirements: user stories and use case modeling. Use cases and user stories are a proven way to focus on what the user really wants to do with the system. They describe an interaction between a user and the system that delivers apparent value to the user or the organization. In this section we show how these approaches can come together.<br />
<br />
The user story approach has a low level of ceremony and uses stories about what the user would like to do with the system. The short description of a user story usually has a form as shown in Figure 22.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch03/form_of_user_stories.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch03/form_of_user_stories.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 22: Form of User Stories</td></tr>
</tbody></table>
The persona form (the third form shown in Figure 22) is great in situations where people with different backgrounds can expect very different solutions. Imagine this story: “Grandma Theresa – with no computer experience whatsoever – wants to make cheap video calls to her grandson at the other side of the globe so that it is easier to keep in contact”. The resulting solution will be a great contrast to the one resulting from this one “Paul – who is a computer nerd – wants to make cheap video calls to his grandma at the other side of the globe so that it is easier to keep in contact”. <br />
<br />
Short descriptions of user stories in the forms shown in Figure 22 are commonly used in a Scrum Product Backlog. <br />
<br />
The fact that you're using user stories doesn't say much however about the form in which requirements are detailed. A user sitting next to a developer, discussing the solution, might be enough. A more elaborate story about how the user would like to use the system to reach his goal could be appropriate. It could also be necessary to write a whole lot of detailed test cases (the XP Test Driven Development practice) to figure out exactly how the system should behave or to make a detailed design so the developers have an idea of how the solution can be realized.<br />
<br />
Use case modeling is a structured approach to capture and detail requirements and is shown in Figure 23. First the Vision is captured, describing a desired future state, the problem to be solved, stakeholders that are involved, what stakes they hold toward the solution and a high-level description of the qualities an appropriate solution should have.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch03/ucm_work_products.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch03/ucm_work_products.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 23: Use Case Modeling Work Products</td></tr>
</tbody></table>
In the Use Case Model the scope of the system is explored and structured. It captures short Use Case descriptions (describing uses the users want to make of the system) at a level of detail, comparable to user stories. For that the forms expressed in Figure 22 can be used. The Use Case Model evolves just after or alongside the Vision, very early on in a development effort.<br />
<br />
More detailed descriptions of the way users want to use the system are captured just in time for development in the form of Use Cases. A Use Case brings together all scenarios (describing a particular way in which the user uses the system) that lead to the same user goal. To create scenarios of comparable granularity it is a common practice to constrain scenarios to actions that are executed in one time, at one place, by one person. The Navigation Map is an aid to discuss and decide on a consistent navigation and look and feel throughout the solution. <br />
<br />
When used in a Scrum context these work products form input for the Product Backlog level and Sprint Backlog level of planning as shown in Figure 24.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch03/ucm-planning.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch03/ucm-planning.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 24: Use Case Modeling as Input for Planning</td></tr>
</tbody></table>
Although use case modeling work products focus mainly on functional requirements, they also form a starting point for identifying acceptance criteria, structuring the solution and keeping the focus on a usable product. This is shown in Figure 25.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch03/ucm-architecture.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch03/ucm-architecture.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 25: Use Case Modeling as Input for Architecture and Quality</td></tr>
</tbody></table>
A Product Acceptance Plan combines product-wide acceptance criteria with the strategy the business uses to organize acceptance. In an Agile context this strategy is mainly made up of iterative activities and helps team and business to level expectations on involvement and results. As such it provides constraints for the solution’s architecture and clues for a team’s Definition of Done.<br />
<br />
In the post <a href="http://blog.scrumup.com/2011/07/maintaining-stability.html">Maintain Stability using XP</a> we saw that XP has a group of practices for Shared Understanding of the Code. It does not say however how this shared understanding is reached, other than working closely together on the code. To reach a shared understanding it also helps to elevate the level of abstraction and use models (or metaphors) to grasp the inherent complexity of code. They enable discussion of its structure and possible improvements to be made. A Software Architecture Document helps in communicating shared coding standards, design ideas and the high level structure of the solution. <br />
<br />
Though all the work products we spoke about in this section can be helpful they are not a purpose on their own. They are merely aids to the real purpose: delivering value to the customer.<br />
<br />
<span class="Apple-style-span" style="background-color: white;"><b style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13px; line-height: 18px;">Other Relevant Posts: </b><br /><a href="http://blog.scrumup.com/2011/06/agile-spirit.html">The Agile Spirit</a><br /><a href="http://blog.scrumup.com/2011/07/self-organization.html">Self-organize using Scrum</a></span><br />
<a href="http://blog.scrumup.com/2011/07/maintaining-stability.html">Maintain Stability using XP</a><br />
<a href="http://blog.scrumup.com/2011/11/get-ready-to-poker.html" rel="nofollow">Get Ready to Poker</a><br />
<br />
<strong>External links:</strong><br />
<a href="http://blog.xebia.com/2012/07/12/improving-user-stories-with-usecases/">Improving User Stories with Use Cases</a></div>
Remi-Armand Collarishttp://www.blogger.com/profile/07222991176549637007noreply@blogger.com4tag:blogger.com,1999:blog-8906546616292446975.post-73696020063349245232011-09-03T10:00:00.012+02:002013-12-22T04:06:59.733+01:00The New New Scrum Rules of Play<div dir="ltr" style="text-align: left;" trbidi="on">
<span class="Apple-style-span" style="font-size: x-small;">(Deze blogpost is ook beschikbaar in het <a href="http://agileordina.wordpress.com/2011/09/05/de-nieuwe-nieuwe-spelregels-van-scrum/" target="_blank">Nederlands</a>)</span><br />
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.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch02/relay_race-scrum.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" qaa="true" src="http://www.scrumup.com/blogimg/ch02/relay_race-scrum.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 10: Relay Race versus Rugby</td></tr>
</tbody></table>
<a name='more'></a><b>History of Scrum</b><br />
Scrum is often traced back to the article ‘The New New Product Development Game’ published in 1986 by Nonake and Takeuchi. This article explains holistic software development using one cross-functional team across all phases of development. In the article this new approach is compared to playing rugby where the whole team takes the ball forward. This as opposed to a relay race where a baton is passed on from player to player which compares well to waterfall development where a team of experts finishes a development phase and passes on the result to another team of experts for the next phase. This article is still a great read.<br />
<br />
In the early nineties, Ken Schwaber and Jeff Sutherland each separately developed an Agile management approach. In 1995 they jointly presented their ideas at the OOPSL ‘95 (an object-oriented programming conference) under the name of Scrum (a rugby term). They are both still active in explaining and promoting Scrum. <br />
<br />
<b>The Why Behind the New New Rules of Play</b><br />
One of the Scrum principles is inspect and adapt. This is what Ken Schwaber and Jeff Sutherland have clearly done with their new Scrum Guide 2011. To play a game there have to be clear rules of play. Within the boundaries of these rules every team can try out numerous strategies and tactics to see what works in which situation. The new Scrum Guide 2011 only holds the New New Scrum Rules of Play. All strategies and tactics are removed and will be published elsewhere and can be found in the many books, blogs and articles on this topic. I think this is a great step forward and enables teams to know what they can experiment with while doing Scrum and what puts them out of the game (or causes Scrum’s effectiveness to be impaired). In the rest of this post I will visualize what the New New Scrum Rules of Play are and comment on them.<br />
<br />
<b>The New New Rules of Play Visualized</b><br />
The power of Scrum is that it is such a simple framework. With only 3 roles, 4 work products and 5 events the new Scrum Guide 2011 sets up a process for self-organization of Agile teams. Within a Scrum Team there are 3 roles as depicted in Figure 11. A change here is that the term Development Team is chosen for the ones actively creating the solution and the advice is to make it up of three to nine people. The metaphor of Pigs and Chickens is completely dropped to prevent jeopardizing the relationship between developers and non-developers (supporting roles and stakeholders).<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/scribble/Scrum%20Roles%20Strict.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/scribble/Scrum%20Roles%20Strict.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 11: Scrum Roles</td></tr>
</tbody></table>
The four Scrum work products represent work or value. They provide transparency in future work, work in progress and work that is done in the sense that it has led to a usable Product Increment. Figure 12 shows these work products within an outline of the Scrum process.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/scribble/Scrum%20Work%20Products%20Strict.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/scribble/Scrum%20Work%20Products%20Strict.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 12: Scrum Work Products</td></tr>
</tbody></table>
The Product Backlog is the only source of requirements that can lead to changes in the product. This list is now called ordered instead of prioritized because priority is only one of the criteria that can infuence the order of implementation. Other criteria are market opportunities, technical or organizational dependencies, politics and return on investment in the long run and from a combined set of stories. The Definition of Done is not labeled as a work product but is mentioned very explicitly as providing a shared understanding of when a story is done (as part of a usable product Increment). In the Sprint Backlog the team provides a forecast of what can be implemented this Sprint and the plan (for instance a work breakdown on a task board) for getting it done. The term commitment is no longer used for this purpose to stress the team can only give it’s best and honest guess of what they can get done in the upcoming sprint.<br />
<br />
The product Owner has an ongoing task in providing insight in the work remaining toward the goal of the development effort (project or release) and his plan for getting there. Burn-down or burn-up charts are no longer required by the rules of play but they have proven to be helpful in many cases so by all means keep on using them where this makes sense.<br />
<br />
The Scrum process consists of five time-boxed events that are repeated throughout development and provide a basis for inspection and adaption as shown in Figure 13. The Sprint encloses all other Scrum events and produces a usable Increment. The main innovations here are the timeboxed character of all the Scrum events and a clear indication of the length of each timebox, based on a Sprint length of one month. For a shorter Sprint the times mentioned will also be proportionally shorter.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/scribble/Scrum%20Events%20Strict.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/scribble/Scrum%20Events%20Strict.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 13: Scrum Events</td></tr>
</tbody></table>
Although these changes aren’t world shocking they are worth noting. Knowing the difference between the rules and the strategies and tactics will prevent a lot of needless discussion and will surely make you a better team player.<br />
<br />
Feel free to comment on the new rules of play, ask questions or share your own experiences. Further useful links are also welcome.<br />
<br />
<b>Other Relevant Posts: </b><br />
<a href="http://blog.scrumup.com/2011/05/introducing-agile.html">Introducing Agile</a><br />
<a href="http://blog.scrumup.com/2011/06/agile-spirit.html">The Agile Spirit</a><br />
<div>
<a href="http://blog.scrumup.com/2011/07/self-organization.html">Self-organize using Scrum</a><br />
<a href="http://blog.scrumup.com/2011/11/be-transparent.html">Be Transparent</a><br />
<br />
<strong>External links:</strong><br />
<div>
<a href="http://www.scrum.org/storage/scrumguides/Scrum%20Guide%20-%202011.pdf" target="_blank">Scrum Guide 2011</a> <br />
<a href="http://www.scrum.org/storage/Scrum%20Update%202011.pdf" target="_blank">Explanation of the Scrum Guide update by Ken and Jeff</a><br />
<a href="http://www.scrum.org/scrum-guide-updates" target="_blank">Further detailed explanations</a> <br />
<a href="http://www.enterprisescrum.com/publications/" target="_blank">Article ‘The New New Product Development Game’</a> <br />
<a href="http://www.implementingscrum.com/2006/09/11/the-classic-story-of-the-pig-and-chicken/" target="_blank">Cartoon on Chicken and Pig</a> and <a href="http://en.wikipedia.org/wiki/The_Chicken_and_the_Pig" target="_blank">WikiPedia on Chicken and Pig</a></div>
</div>
</div>
Remi-Armand Collarishttp://www.blogger.com/profile/07222991176549637007noreply@blogger.com33tag:blogger.com,1999:blog-8906546616292446975.post-17905595335713943462011-07-15T00:08:00.049+02:002012-03-17T02:03:40.258+01:00Maintain Stability using XPA 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 <a href="http://manifesto.softwarecraftsmanship.org/" target="_blank">Manifesto for Software Craftsmanship</a>, 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.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch03/manifesto_craftsmanship.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch03/manifesto_craftsmanship.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 15: Manifesto for Software Craftsmanship</td></tr>
</tbody></table>
<br />
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.<br />
<a name='more'></a><br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch03/positioning_xp.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch03/positioning_xp.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 16: Positioning XP Practices</td></tr>
</tbody></table>
As shown in Figure 16, XP practices can be positioned as part of the daily cycle of Scrum. The practices we treat here can be divided into three groups: the ones concerned with fine scale, early feedback, the ones concerned with continuity in the development process and the ones concerned with shared understanding of the code.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch03/xp_early_feedback.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch03/xp_early_feedback.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 17: XP Practices for Fine Scale, Early Feedback</td></tr>
</tbody></table>
The groundwork for fine scale, early feedback, as shown in Figure 17, is laid by Test-Driven Development. It makes sure that we build what the customer wants, forces thinking about design (interfaces, distribution of responsibilities over classes and methods), provides a safety net, preventing mistakes and in that way improves the maintainability of the code. Pair Programming is perhaps the most rigorous form of peer review there is. It makes sure that all production code is viewed by at least two developers, enables knowledge transfer, prevents lonely digging for solutions and stimulates discussion on design issues.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch03/xp_continuity.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch03/xp_continuity.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 18: XP Practices for Continuity in the Development Process</td></tr>
</tbody></table>
<br />
Continuity in the development process is provides by Continuous Integration and Design Improvement, as explained in Figure 18. Continuous Integration stimulates developers to check in code changes as soon as possible (as soon as they passed the programmer tests), making them easier to integrate. This way the current status of the solution, passing all tests, can always be demoed to the customer. Design Improvement through refactoring is something that is done very consciously. A developer is either building functionality or refactoring to keep the code clean and maintainable, never both at the same time.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch03/xp_understanding.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch03/xp_understanding.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 19: XP Practices for Shared Understanding of the Code</td></tr>
</tbody></table>
<br />
To ensure a shared understanding of the code XP deploys Simple Design, Collective Code Ownership and Coding Standards, as explained in Figure 19. For Simple design the ground rules are that the system runs all the customer and programmer tests, it contains no duplicate code that could increase the maintenance effort, the code is self explanatory and contains the fewest possible number of classes and methods. A nice saying illustrating this practice is ”Always assume the next one to maintain your code to be a homicidal maniac who knows where you live”. Collective Code Ownership enables quicker simplification of complex code and reduces waiting time since anyone feels free to contribute. Shared Coding Standards provides consistently shaped code, making it easier to read and maintain each other’s code.<br />
<br />
The key to the success of XP is that it ensures that changing the code is easy and risk free. To realize this, all the XP practices are needed as they enforce each other. They are like a house of cards where all cards support each other to keep the house of cards standing. When all used together the XP practices and values support the creation of high quality software, optimally fulfilling customer needs with a minimum of ceremony and overhead. As such they work great within the Scrum framework and they work equally fine in a somewhat higher level of ceremony environment, say in an organization where RUP is used.<br />
<div>
<br /></div>
<br />
More information on XP practices and values can be found at <a href="http://epf.eclipse.org/wikis/xp" target="_blank">epf.eclipse.org/wikis/xp</a>. <br />
A nice guided tour of XP can be found at <a href="http://www.extremeprogramming.org/" target="_blank">http://www.extremeprogramming.org/</a>.Remi-Armand Collarishttp://www.blogger.com/profile/07222991176549637007noreply@blogger.com2tag:blogger.com,1999:blog-8906546616292446975.post-25609027814449180102011-07-08T14:55:00.000+02:002012-03-12T00:12:11.178+01:00Learn the Scrum Rules of PlayThis is part 2 of 3 posts on Scrum. Part 1 of this post is <a href="http://blog.scrumup.com/2011/07/self-organization.html">Self-organize using Scrum</a>.<br />
<br />
The power of Scrum is that it is such a simple framework. To describe the Scrum process just 12 concepts suffice, divided as:<br />
<ul>
<li>3 roles</li>
<li>4 work products</li>
<li>5 time-boxed events</li>
</ul>
Within a Scrum Team, Scrum recognizes three roles as depicted in Figure 13.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch03/scrum_roles.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch03/scrum_roles.png" /></a></td></tr>
<tr><td class="tr-caption" style="font-size: 13px; text-align: center;">Figure 13: Scrum Roles</td></tr>
</tbody></table>
<br />
<a name='more'></a><br />
Each of these roles is responsible for a part of the management responsibilities within the Scrum Team. The Product Owner represents all Stakeholders toward the Self-organizing Team. He organizes requests for new or changed functionalities throughout the project, incrementally accepts the evolving solution and decides when increments of the solution go live. He spends some 20% to 30% of his time with the team. An equal amount of time is spent interacting with stakeholders. This role is best played by someone from the business, who will benefit most directly from the solution the team is developing. The Scrum Master facilitates the Self-organizing Team and the Product Owner and in that way ensures that they adhere to the Scrum values and practices. He helps them to understand and use self-organization. The Self-organizing Team consists of developers (in the broadest sense of the word) and subject matter experts who together translate business requests into a usable solution. They provide the Product Owner with estimates, forecast the work that can be done and organize themselves to get it done.<br />
<br />
The four Scrum work products represent work to be done or value. They provide transparency in future work, work in progress and work that is done in the sense that it has led to a Usable Increment of the solution. Figure 14 shows these work products within an outline of the Scrum process consisting of the Sprint cycle and the daily cycle. The Sprint cycle represents a time box or iteration in which a Usable Increment of the solution is developed. The Daily cycle represents activities that are repeated on a daily basis.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch03/scrum_work_products.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch03/scrum_work_products.png" /></a></td></tr>
<tr><td class="tr-caption" style="font-size: 13px; text-align: center;">Figure 14: Scrum Work Products</td></tr>
</tbody></table>
The Product Backlog is an ordered list of stories that represent requests for new or changed functionality that mean future work for the team. It is maintained by the Product Owner. The input for the Sprint cycle consists of stories from the Product Backlog which are ‘Ready to Poker’. This means that the team knows what the story is, how to realize it in software, which tasks they have to perform, and how it will be accepted by the customer. In other words, if the team is able to estimate (or poker) an item, it is Ready to Poker. The Definition of Done provides a shared understanding of when a story is done. The Product Backlog and the Definition of Done provide important input enabling the team to forecast what can be developed this Sprint. This forecast is represented by the Sprint Backlog. It contains the stories the team selected from the top of the list and details the work needed to get the stories Done. The goal of every Sprint cycle is to develop a Usable Increment of the solution.<br />
<br />
The Scrum process consists of five time-boxed events that are repeated throughout development and provide a basis for inspection and adaption. Figure 15 shows these events within an outline of the Scrum process. The Sprint cycle is an event that encloses all other Scrum events. It is a timebox of two to four weeks. Keep the Sprint length constant for at least a few months and gather experience with it before trying out a new one. The timebox indications for events that start and close a Sprint (the ones in hours) are based on a Sprint length of 3 weeks. A Sprint length we have had good experiences with. Adjust them linearly when using longer or shorter Sprints.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch03/scrum%20_events.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch03/scrum%20_events.png" /></a></td></tr>
<tr><td class="tr-caption" style="font-size: 13px; text-align: center;">Figure 15: Scrum Events</td></tr>
</tbody></table>
Every Sprint cycle starts with the Plan the Sprint event that consists of two meetings. Within the Sprint Planning Meeting the Product Owner and the Self-organizing Team sit together to select stories for the Sprint from the top of the Product Backlog (more in Section 6.2 Estimation and Planning of Stories). The Product Owner provides the team with input on ordering of stories and the need behind them. The team can negotiate a change of order (based on technical dependencies or technical risk) and provides the Product Owner with their estimates. The Product Owner has the final say in the order in which stories are implemented. The team decides on the forecast of stories that can be implemented this Sprint. In the Work Breakdown Meeting the team details the work that will have to be done to implement the stories (more in Section 6.1 Estimation and Planning of Tasks). After this meeting the team gives its final forecast. These two meetings produce the Sprint Backlog.<br />
<br />
Every day the team gets together for a 15 minute Stand-up Meeting at the Task Board to discuss progress. This meeting is meant to minimize the need for other team meetings. Every team member tells what he has done and learned yesterday, what he is going to do for the team today and if there are any impediments holding him back, he needs help with.<br />
<br />
As shown in Figure 15 at the end of each sprint two events take place. Review and Demo the Sprint Result is about updating the Product Backlog with insights from the last Sprint (remove stories that are done, re-estimate stories that are partially done or better known now). It also encompasses a demo by the team of the Usable Increment. For the demo the team and the Product Owner invite management and a wider range of stakeholders then the ones directly involved in development. The Product Owner concludes the demo with a presentation of the work still to be done toward the goal and his plan for getting it done. The updated Product Backlog and the current team (development) velocity form the input for this plan. Look Back and Improve is about making a plan for improvement in the next Sprint, focused on what the team can do to improve. What went well? Let’s keep doing that! What could be better? What will we try next Sprint as a team to improve.<br />
<br />
Part 1 of this post is <a href="http://blog.scrumup.com/2011/07/self-organization.html">Self-organize using Scrum</a>.<br />
Part 3 of this post is <a href="http://blog.scrumup.com/2011/11/be-transparent.html">Be Transparent</a>.<br />
<div>
<br /></div>
<div>
<b>Other Relevant Posts: </b><br />
<a href="http://blog.scrumup.com/2011/05/introducing-agile.html">Introducing Agile</a><br />
<a href="http://blog.scrumup.com/2011/06/agile-spirit.html">The Agile Spirit</a><br />
<div>
<a href="http://blog.scrumup.com/2011/07/maintaining-stability.html">Maintain Stability using XP</a></div>
</div>Remi-Armand Collarishttp://www.blogger.com/profile/07222991176549637007noreply@blogger.com17tag:blogger.com,1999:blog-8906546616292446975.post-73249356619998521562011-07-01T14:53:00.002+02:002012-03-12T00:13:17.084+01:00Self-organize using ScrumThis is part 1 of 3 posts on Scrum.<br />
<br />
Scrum is a framework for self-organization of Agile teams. Although this seems a simple statement we are going to repeat it:<br />
<div style="text-align: center;">
<span class="Apple-style-span" style="color: #0b5394; font-size: large;"><i>Scrum is a framework </i></span></div>
<div style="text-align: center;">
<span class="Apple-style-span" style="color: #0b5394; font-size: large;"><i>for self-organization </i></span></div>
<div style="text-align: center;">
<span class="Apple-style-span" style="color: #0b5394; font-size: large;"><i>of Agile teams</i></span></div>
<br />
Let’s take a closer look at the three parts of this statement.<br />
<br />
<a name='more'></a><br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch03/wordcloud_framework.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch03/wordcloud_framework.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 8: Word Cloud on the Term Framework</td></tr>
</tbody></table>
First of all Scrum is a framework. Looking at the word cloud in Figure 8 you can see that an important property of a framework is empty space. Think of a bookcase without space for books or a frame without space for a painting or picture: they are useless. In the same way Scrum leaves room for filling in specialist practices. This filling in is done by the team, guided by their own experiences. To preventing reinventing the wheel all the time, methods and company practices can serve as a starting point for these specialist practices, especially where newly formed teams are concerned.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch03/wordcloud_self-organization.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch03/wordcloud_self-organization.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 9: Word Cloud on the Term Self-organization</td></tr>
</tbody></table>
Self-organization points not only to the way the team fill in the specialist practices but also to the way the team independently forecasts and organizes its work. Self-organization is the natural way for people (and animals and all of nature) to work together and the only way to cope with the complexity of today’s systems and projects. As shown in Figure 9, to facilitate this self-organization the team needs mandate, a multidisciplinary, hybrid composition and a clear goal. It needs to be well facilitated and it needs a clear single point of contact toward the business for decisions about priority and requirements. <br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch03/wordcloud_agile.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch03/wordcloud_agile.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 10: Word Cloud on the Term Agile</td></tr>
</tbody></table>
<br />
Agile teams conform to the Agile values that we explained in the previous section. The word cloud in Figure 11 shows a collection of aspects that are associated with Agile. Scrum doesn’t say much about how an Agile team should be formed, it just supposes it is used in the context of a team that follows the Agile values and uses specialist practices from other agile methods. Furthermore Scrum presupposes a support and management organization that enables self-organization of Agile teams.<br />
<br />
To improve the self-organizing capability of an Agile team the Scrum framework introduces three pillars as shown in Figure 12. These pillars form the basis for the whole Scrum process that we will explain in the next section.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch03/scrum_pillars.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch03/scrum_pillars.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 12: Scrum Pillars</td></tr>
</tbody></table>
<br />
Transparency is all about clarity in goals, planning and results. In the Scrum process long term and short term goals and plans are made visible and realistic. Results are measured only in terms of usable software. Inspection is all about taking time to look back on the product and on how things get done followed by making concrete plans to improve. Adaptation is all about taking action on these plans and experiment to improve the product and empirically find better ways of doing things. Inspection and Adaptation form a continuous improvement cycle throughout the Scrum process.<br />
<div>
<br /> </div>
Part 2 of this post is <a href="http://blog.scrumup.com/2011/07/learn-scrum-rules-of-play.html">Learn the Scrum Rules of Play</a><br />
Part 3 of this post is <a href="http://blog.scrumup.com/2011/11/be-transparent.html">Be Transparent</a>.<br />
<br />
<b>Other Relevant Posts: </b><br />
<a href="http://blog.scrumup.com/2011/05/introducing-agile.html">Introducing Agile</a><br />
<a href="http://blog.scrumup.com/2011/06/agile-spirit.html">The Agile Spirit</a><br />
<div>
<a href="http://blog.scrumup.com/2011/07/maintaining-stability.html">Maintain Stability using XP</a></div>
<div>
</div>Remi-Armand Collarishttp://www.blogger.com/profile/07222991176549637007noreply@blogger.com3tag:blogger.com,1999:blog-8906546616292446975.post-14361871298326377162011-06-17T14:50:00.005+02:002012-01-09T20:19:37.085+01:00The Agile SpiritAll 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?<br />
<br />
<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch03/values_exercise.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch03/values_exercise.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 5: Agile Values Exercise</td></tr>
</tbody></table>
<br />
<a name='more'></a>The Agile Manifesto , as shown in Figure 6, guides teams in a direction of improving communication and involvement and eliminating waste from their process. It is a good idea to hang it on a wall in everyone’s sight and use it whenever decisions on the process are made. We changed the second statement from the Agile Manifesto a bit to make it more widely usable.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch03/agile_manifesto.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch03/agile_manifesto.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 6: The Agile Manifesto</td></tr>
</tbody></table>
After all marks have been given, rearrange the sticky notes according to the Agile Manifesto and check if the team values the aspects on the left more than the ones on the right. We have not experienced a team that valued an item on the right more than its counterpart on the left so it is a nice common starting point. The result might look something like Figure 7. The next question is: which aspects receive the most attention your organization? Prepare to be surprised by the discussion to follow.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch03/result_values_exercise.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch03/result_values_exercise.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 7: Example Result of the Agile Values Exercise</td></tr>
</tbody></table>
Agile also has 12 principles communicating the mindset teams and organizations need, to be able to leverage the advantages Agile has to offer. We will not discuss all 12 principles but they are partly incorporated in an upcoming <a href="http://blog.scrumup.com/2011/07/improve.html">post</a> discussing Unified Principles for Iterative and Agile IT Development.Remi-Armand Collarishttp://www.blogger.com/profile/07222991176549637007noreply@blogger.com2tag:blogger.com,1999:blog-8906546616292446975.post-30555371204218171842011-06-03T14:47:00.004+02:002011-10-01T20:50:41.197+02:00ScrumUP Fairytale - Part 3<div style="text-align: center;">
<span class="Apple-style-span" style="color: #0b5394; font-size: large;"><b><i>The Soup Stone – 3: An empty square…</i></b></span></div>
<div style="text-align: center;">
<span class="Apple-style-span" style="color: #0b5394; font-size: large;"><i><br />
</i></span></div>
<div style="text-align: center;">
<span class="Apple-style-span" style="color: #0b5394; font-size: large;"><i>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.</i></span></div>
<div style="text-align: center;">
<span class="Apple-style-span" style="color: #0b5394; font-size: large;"></span></div>
<a name='more'></a><br />
<div style="text-align: center;">
<span class="Apple-style-span" style="color: #0b5394; font-size: large;"><i>It gets more and more crowded along the road as the soldier is approaching the city. Well, it is hard to speak of a city because it doesn't really look like a city. It looks more like a collection of tiny townships. Little groups of houses with empty stores and workshops. There had been something like a square but it is now empty and covered with sand and mud. There are people in the houses but the square is empty. In this city of little townships each township also only contains objects and people of matching color.</i></span></div>
<div style="text-align: center;">
<span class="Apple-style-span" style="color: #0b5394; font-size: large;"><i><br />
</i></span></div>
<div style="text-align: center;">
<span class="Apple-style-span" style="color: #0b5394; font-size: large;"><i>Our soldier has a long journey behind him and has even further to go. He's looking for a place to rest and for something to eat because he is very hungry and has nothing left to eat in his old soldiers bag. He doesn't feel comfortable though, to just walk up to someone to ask for something to eat and a place to stay. It's clear to him that the people in this city of little townships don't have much to spend. If he would try to speak to someone they would probably just walk on so our soldier just sits down in the middle of the square on something that used to be a little bench. He looks around, looks at the sun that's glowing in the sky and lets his mind wander for a while.</i></span></div>
<div>
<br /></div>
<div>
<b>The Spirit of Iterative and Agile Development</b> </div>
<div>
Up till now we've only scratched the surface of what Agile is and what iterative and Agile methods have to offer. In this chapter are going to take a closer look at the Agile spirit. What does it mean to be Agile, what prerequisites are needed, what practices can help and how can I improve my way of working?</div>
Remi-Armand Collarishttp://www.blogger.com/profile/07222991176549637007noreply@blogger.com1tag:blogger.com,1999:blog-8906546616292446975.post-56066178361287611422011-05-20T14:44:00.002+02:002012-01-09T20:26:41.682+01:00Comparing MethodsUp 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.<br />
<a name='more'></a><br />
Although the core of Scrum is very simple, it is not completely self-explanatory and has a limited scope. The first point is illustrated by the many books and articles dedicated to the application of Scrum. Scrum gives you the simple basics that all can easily understand. Yet IT-development is complex and every situation is different so you need to adapt the process. The second point becomes clear by looking at its scope. Scrum is about self-organization of teams and has little to say about specialist work or project management. Any rules not stated in Scrum are supposed to be figured out by the Team and all others involved in the project. They may consult best practices, such as those described in other (preferably Agile or iterative) methods.<br />
<br />
Scrum is often used in conjunction with eXtreme Programming (XP), an Agile method providing day-to-day practices for developers. Projects using XP usually have the following characteristics:<br />
<br />
<ul>
<li>Low level of ceremony</li>
<li>Low focus on architecture</li>
<li>Minimal documentation</li>
<li>A dedicated team (in a product development or maintenance situation)</li>
<li>Quick and ongoing releases to production</li>
</ul>
<br />
There are many books on Scrum and XP and most books on Scrum assume Agile software development practices like the ones from XP are being used by the team to guide their daily work. We however have come across many situations where a higher level of ceremony is needed and where practices from RUP can help the team to:<br />
<br />
<ul>
<li>Guide them in a greenfield situation </li>
<li>Structure requirements</li>
<li>Reach agreement with stakeholders on objectives for the project</li>
<li>Deal with new technologies and technical risks</li>
<li>Provide them with a standard way of doing specialist work</li>
</ul>
<br />
XP is mainly concerned with requirements, architecture, development and testing, whereas RUP also provides practices for other software development disciplines. Furthermore RUP supports higher levels of ceremony than Scrum and XP do. In this book we will show how RUP can be tailored to be used in an Agile environment and how it can be integrated with Scrum and XP. Furthermore we will show what mindset is needed to make it work and what aspects of the organization should be involved.<br />
<br />
Scrum and RUP both provide guidance on team management, but are not focused on project management. For this Scrum could be pulled to a higher level (Scrum of Scrums) or the current management practices – like those described in PRINCE2 – can be used .<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch02/method_focus.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch02/method_focus.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 3: The Focus of Scrum, XP, RUP and PRINCE2</td></tr>
</tbody></table>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
In Figure 3 we have visualized the scope of Scrum together with those of RUP, XP and PRINCE2. On the x-axis we see time ranges: Does a method focus on day-to-day tasks, or is it focused around iterations, or perhaps releases or the complete project? We see that Scrum is focused on day-to-day tasks, and RUP not at all. We find iterations to be an overlapping area of concern, whereas Scrum does not say much about releases or a project as a whole. On the y-axis we see several ‘disciplines’. Scrum is mostly concerned with team management. RUP has a lot to say about other disciplines as well, although of course there are areas which RUP does not cover.<br />
<br />
This figure shows that each of the shown methods has its own viewpoint on IT-development. It helps to determine what the focus of each method is, it can help to select the right tools for the job at hand and it shows that these methods complement each other with only a small overlap in concerns. <br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch02/ceremony_iterativity.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch02/ceremony_iterativity.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 4: Level of Ceremony and Iterativity</td></tr>
</tbody></table>
<br />
As Figure 4 shows we can also look at methods from another angle. Here we look at the level of ceremony development methods support and at the rate at which they deliver usable software to the customer and release that software to production. At one end of the spectrum we have SDM supporting high level of ceremony and producing usable software in a matter of months or years. At the other end we have Kanban supporting a low level of ceremony and producing usable software interface. With ScrumUP we bridge the gap between the high level of ceremony of IBM RUP and the low level of ceremony of the combination of Scrum and XP.<br />
<br />
<span class="Apple-style-span" style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 12px; line-height: 16px;"></span><br />
<div class="post-body entry-content" id="post-body-4503883972446840651" style="font-size: 13px; line-height: 1.4; position: relative; width: 570px;">
<b>Other Relevant Posts: </b><br />
<a href="http://blog.scrumup.com/2011/04/introducing-rup.html" style="color: #cc6611; text-decoration: none;">Introducing RUP</a><br />
<a href="http://blog.scrumup.com/2011/06/agile-spirit.html" style="color: #cc6611; text-decoration: none;">The Agile Spirit</a><br />
<a href="http://blog.scrumup.com/2011/07/self-organization.html" style="color: #cc6611; text-decoration: none;">Self-organization</a> (on the Scrum process)<br />
<a href="http://blog.scrumup.com/2011/07/maintaining-stability.html" style="color: #cc6611; text-decoration: none;">Maintaining Stability</a> (on what XP has to offer in a Scrum setting)<br />
<div style="clear: both;">
</div>
</div>
<div class="post-footer" style="background-color: #f9f9f9; border-bottom: rgb(238,238,238) 1px solid; color: #666666; font-size: 11px; line-height: 1.6; margin: 20px -2px 0px; padding-bottom: 5px; padding-left: 10px; padding-right: 10px; padding-top: 5px;">
</div>Remi-Armand Collarishttp://www.blogger.com/profile/07222991176549637007noreply@blogger.com2tag:blogger.com,1999:blog-8906546616292446975.post-45038839724468406512011-05-06T14:38:00.012+02:002012-01-09T20:27:36.691+01:00Introducing AgileIn 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.<br />
<a name='more'></a><br />
These methods have in common that they<br />
<ul>
<li>Are lightweight </li>
<li>Involve the customer</li>
<li>Have short cycles (2 to 4 weeks, enabling rapid delivery and frequent inspection and adaptation)</li>
<li>Focus on eliminating waste from the process</li>
<li>Are keen on the human aspect of software development </li>
</ul>
In 2001 a number of representatives from these lightweight methods convened in a ski resort in Utah to establish some common ground. Among them were Kent Beck, the creator of Extreme Programming and Ken Schwaber and Jeff Sutherland, the creators of Scrum. Most participants did not expect any tangible result to come from a gathering of such stubborn, know-it-all methodologists. Nevertheless two important outcomes are to be noted and still influence the world of software development today.<br />
<ul>
<li>These lightweight methods were from then on to be known as Agile.</li>
<li>Agile methods are now guided by the Agile Manifesto , a statement of values that all participants of that gathering agreed on (see <a href="http://blog.scrumup.com/2011/06/agile-spirit.html">The Agile Spirit</a>). </li>
</ul>
<b><span class="Apple-style-span" style="font-weight: normal;"></span></b><br />
<div style="display: inline !important;">
<b>An overview of events surrounding the introduction of the development methods used in this book, Scrum, XP and RUP is shown in Figure 2.</b></div>
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch02/timeline_methods.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch02/timeline_methods.png" /></a></td></tr>
<tr><td class="tr-caption" style="font-size: 13px; text-align: center;">Figure 2: Timeline Agile and Iterative Software Development Methods<br />
<div>
<br /></div>
</td></tr>
</tbody></table>
<b>Introducing Scrum</b><br />
Scrum originates from an article published in 1986 on holistic software development using one cross-functional team across all phases of development. In the article this approach was compared with playing rugby where the whole team takes the ball forward (as opposed to a relay race where a baton is passed on from player to player).<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.scrumup.com/blogimg/ch02/relay_race-scrum.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.scrumup.com/blogimg/ch02/relay_race-scrum.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 3: Relay Race versus Rugby</td></tr>
</tbody></table>
<br />
In a relay race a baton is passed along from one player to the next. This is similar to a waterfall approach in IT, where a group of experts carry out one phase in the development of an IT-solution (requirements, analysis and design, implementation or testing). When they are done they pass the result on to a next group of experts for the next phase. If one player doesn’t make it or drops the baton (often while passing it on), the race is lost. In rugby, time after time the team take possession of the ball and as a team try to get it across the field to score a touchdown (or as a team try to prevent a touchdown when the opposing team has the ball). This is much more like the Agile way of working where a team as a whole delivers working, usable software every two to four weeks.<br />
<br />
In the early nineties, Ken Schwaber and Jeff Sutherland each separately developed an Agile management approach. In 1995 they jointly presented their ideas at the OOPSL ‘95 (an object-oriented programming conference) under the name of Scrum (a rugby term). In 2001 the first book on Scrum “Agile Software Development with Scrum” by Ken Schwaber and Mike Beedle was published. A lot more have followed since then.<br />
<br />
Scrum is a framework for self-organization of Agile teams. With only 3 roles, 4 work products and 5 events it sets up an easy to learn process for incremental software delivery, guided by business needs that is further explained in the post about Section 3.2. It helps the team to deliver value to the customer early and gives complete openness to all stakeholders concerning tasks that are being done, work remaining toward the development goal, the teams development velocity and impediments that keep the team from performing at their best. Because of its clear focus on self-organization of teams it is easy to combine with other methods that focus more on the specialist or project management side of IT development. Scrum is often used in combination with XP (eXtreme Programming).<br />
<br />
<b>Introducing XP</b><br />
Around 1996 Kent Beck, a prominent Smalltalk practitioner at Crysler, started refining a set of day to day software development practices that made sense to him. To work out some difficulties his team were having, he asked them to take these practices to their extremes and leave out all others -- and it worked. These practices were first published on the newly evolving internet and since 1999 bundled and further expanded in a series of books, starting with his own book “Extreme Programming Explained”.<br />
<br />
XP focuses on improving software quality and responding to change. It’s practices encompass timeboxing, test-first development (writing automated tests before programming), pair programming (working in pairs behind one computer), refactoring (to achieve simplicity and clarity of code), continuous integration (building the code and running outomated tests preferably each time code is checked in), customer involvement and the planning game (for estimating, clarifying requirements and getting commitment from the team). Some of these practices will be discussed in the post about <a href="http://blog.scrumup.com/2011/07/maintaining-stability.html">Maintaining Stability</a>.<br />
<br />
<b>Other Relevant Posts: </b><br />
<a href="http://blog.scrumup.com/2011/04/introducing-rup.html">Introducing RUP</a><br />
<a href="http://blog.scrumup.com/2011/05/comparing-methods.html">Comparing Methods</a><br />
<a href="http://blog.scrumup.com/2011/06/agile-spirit.html">The Agile Spirit</a><br />
<a href="http://blog.scrumup.com/2011/07/self-organization.html">Self-organization</a><br />
<a href="http://blog.scrumup.com/2011/07/maintaining-stability.html">Maintaining Stability</a>Remi-Armand Collarishttp://www.blogger.com/profile/07222991176549637007noreply@blogger.com23