Discussion:
[SCRUMDEVELOPMENT] minimally dependent Teams sharing a code base
'Jean Richardson' jean@azuregate.net [SCRUMDEVELOPMENT]
2015-02-14 04:06:07 UTC
Permalink
All -



I'm looking for example cases of multiple teams in the same code base and
sharing a product backlog releasing every sprint and functioning in a fairly
independent manner. Specifically, that their sprint commitments are
Team-specific, and it is possible for one Team to fail their sprint while
the other succeeds. I'm also interested in hearing where the minimal
dependencies are.



Thanks in advance for anything you can provide.



--- Jean









Jean Richardson

Azure Gate Consulting

~ Repatterning the Human Experience of Work



AzureGate.net

(503) 788-8998

***@AzureGate.net
steve@ootac.com [SCRUMDEVELOPMENT]
2015-02-14 09:41:36 UTC
Permalink
Hi Jean.


First Point: Sprints do not fail!!


Second Point: Team commitment has been replaced by team forecast in the Scrum Guide. The commitment used to be to the Sprint Goal but this was so widely misinterpreted to committing to deliver all User Stories (a very non- Agile interpretation) that "commitment" has been dropped.


So, to your question about minimal dependencies.
Each team should have some sort of minimum that is guaranteed (Moscow rules, MVP, MMF etc). This minimum should represent around the 50-70% of the estimated effort (depending on teams' Agile experience) for all the User Stories forecast.


Dependencies across teams must always be within these minimums to 'guarantee' no problems.


Ah - you say -what if one team find that they cannot meet their minimums (it happens very rarely)?


STOP THE SPRINT!


Inform the team(s) that have a dependency on the first team and then they must decide if they can still meet their minimums. If they cannot - STOP THEIR SPRINTS.


Affected teams should regroup with the relevant stakeholders and re-plan - "simples".


Although it is the same code base and same Product Backlog, what you have is a Programme that needs coordination across teams but the application of the basic Agile and Scrum principles as above will minimise any problems.


Hope that helps


Steve
Jean Richardson jean@azuregate.net [SCRUMDEVELOPMENT]
2015-02-14 15:54:04 UTC
Permalink
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
</head>







<body style="background-color: #fff;">
<span style="display:none">&nbsp;</span>

<!--~-|**|PrettyHtmlStartT|**|-~-->
<div id="ygrp-mlmsg" style="position:relative;">
<div id="ygrp-msg" style="z-index: 1;">
<!--~-|**|PrettyHtmlEndT|**|-~-->

<div id="ygrp-text" >


<p><div style="width: 100%;font-size: initial;font-family: Calibri, 'Slate Pro', sans-serif;color: rgb(31, 73, 125);text-align: initial;background-color: rgb(255, 255, 255);">Your solution would cause these teams to stop their sprint almost every day.</div><div style="width: 100%;font-size: initial;font-family: Calibri, 'Slate Pro', sans-serif;color: rgb(31, 73, 125);text-align: initial;background-color: rgb(255, 255, 255);"><br></div><div style="width: 100%;font-size: initial;font-family: Calibri, 'Slate Pro', sans-serif;color: rgb(31, 73, 125);text-align: initial;background-color: rgb(255, 255, 255);">Anyone else, please?</div> <div style="width: 100%;font-size: initial;font-family: Calibri, 'Slate Pro', sans-serif;color: rgb(31, 73, 125);text-align: initial;background-color: rgb(255, 255, 255);"><br></div> <div style="font-size: initial;font-family: Calibri, 'Slate Pro', sans-serif;color: rgb(31, 73, 125);text-align: initial;background-color: rgb(255, 255, 255);">Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.</div> <table width="100%" style="background-color:white;"> <tbody><tr><td colspan="2" style="font-size: initial;text-align: initial;background-color: rgb(255, 255, 255);"> <div id="_persistentHeader" style="border-style: solid none none;border-top-color: rgb(181, 196, 223);border-top-width: 1pt;padding: 3pt 0in 0in;font-family: Tahoma, 'BB Alpha Sans', 'Slate Pro';font-size: 10pt;"> <div><b>From: </b>***@ootac.com [SCRUMDEVELOPMENT]</div><div><b>Sent: </b>Saturday, February 14, 2015 1:41 AM</div><div><b>To: </b>***@yahoogroups.com</div><div><b>Reply To: </b>***@yahoogroups.com</div><div><b>Subject: </b>[SCRUMDEVELOPMENT] Re: minimally dependent Teams sharing a code base</div></div></td></tr></tbody></table><div style="border-style: solid none none;border-top-color: rgb(186, 188, 209);border-top-width: 1pt;font-size: initial;text-align: initial;background-color: rgb(255, 255, 255);"></div><br><div id="_originalContent">














<span>&nbsp;</span>



<div id="ygrp-text">


<p></p><div class="ygroups-quoted"><div id="ygrps-yiv-2063505876"><div class="ygrps-yiv-2063505876WordSection1"><p class="ygrps-yiv-2063505876MsoNormal">Hi Jean.</p><p class="ygrps-yiv-2063505876MsoNormal"><br></p><p class="ygrps-yiv-2063505876MsoNormal">First Point:&nbsp; Sprints do not fail!!</p><p class="ygrps-yiv-2063505876MsoNormal"><br></p><p class="ygrps-yiv-2063505876MsoNormal">Second Point:&nbsp; Team commitment has been replaced by team forecast in the Scrum Guide.&nbsp; The commitment used to be to the Sprint Goal but this was so widely misinterpreted to committing to deliver all User Stories (a very non- Agile interpretation) that "commitment" has been dropped.</p><p class="ygrps-yiv-2063505876MsoNormal"><br></p><p class="ygrps-yiv-2063505876MsoNormal">So, to your question about minimal dependencies.</p><p class="ygrps-yiv-2063505876MsoNormal">Each team should have some sort of minimum that is guaranteed (Moscow rules, MVP, MMF etc). This minimum should represent around the 50-70%&nbsp;of the estimated effort (depending on teams' Agile experience) for all the User Stories forecast.</p><p class="ygrps-yiv-2063505876MsoNormal"><br></p><p class="ygrps-yiv-2063505876MsoNormal">Dependencies across teams must always be within these minimums to 'guarantee'&nbsp;no problems.</p><p class="ygrps-yiv-2063505876MsoNormal"><br></p><p class="ygrps-yiv-2063505876MsoNormal">Ah - you say -what if one team find that they cannot meet their minimums (it happens very rarely)?</p><p class="ygrps-yiv-2063505876MsoNormal"><br></p><p class="ygrps-yiv-2063505876MsoNormal">STOP&nbsp;THE SPRINT!</p><p class="ygrps-yiv-2063505876MsoNormal"><br></p><p class="ygrps-yiv-2063505876MsoNormal">Inform the team(s) that have a dependency on the first team and then they must decide if they can still meet their minimums.&nbsp; If they cannot - STOP THEIR SPRINTS.</p><p class="ygrps-yiv-2063505876MsoNormal"><br></p><p class="ygrps-yiv-2063505876MsoNormal">Affected teams should regroup with the relevant stakeholders and re-plan - "simples".</p><p class="ygrps-yiv-2063505876MsoNormal"><br></p><p class="ygrps-yiv-2063505876MsoNormal">Although it is the same code base and same Product Backlog, what you have is a Programme that needs coordination across teams but the application of the basic Agile and Scrum principles as above will minimise&nbsp;any problems.</p><p class="ygrps-yiv-2063505876MsoNormal"><br></p><p class="ygrps-yiv-2063505876MsoNormal">Hope that helps</p><p class="ygrps-yiv-2063505876MsoNormal"><br></p><p class="ygrps-yiv-2063505876MsoNormal">Steve</p></div></div></div><p></p>

</div>








<!-- end group email -->

<br><!--end of _originalContent --></div>
</p>

</div>


<!--~-|**|PrettyHtmlStart|**|-~-->
<div style="color: #fff; height: 0;">__._,_.___</div>






<div style="clear:both"> </div>

<div id="fromDMARC" style="margin-top: 10px;">
<hr style="height:2px ; border-width:0; color:#E3E3E3; background-color:#E3E3E3;">
Posted by: Jean Richardson &lt;***@azuregate.net&gt; <hr style="height:2px ; border-width:0; color:#E3E3E3; background-color:#E3E3E3;">
</div>
<div style="clear:both"> </div>

<table cellspacing=4px style="margin-top: 10px; margin-bottom: 10px; color: #2D50FD;">
<tbody>
<tr>
<td style="font-size: 12px; font-family: arial; font-weight: bold; padding: 7px 5px 5px;" >
<a style="text-decoration: none; color: #2D50FD" href="https://groups.yahoo.com/neo/groups/SCRUMDEVELOPMENT/conversations/messages/58134;_ylc=X3oDMTJxdDUydTZ1BF9TAzk3MzU5NzE0BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNzA1MDA3NzA5BG1zZ0lkAzU4MTM0BHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTQyMzkyOTIzOA--?act=reply&messageNum=58134">Reply via web post</a>
</td>
<td>&bull;</td>
<td style="font-size: 12px; font-family: arial; padding: 7px 5px 5px;" >
<a href="mailto:***@azuregate.net?subject=Re%3A%20%5BSCRUMDEVELOPMENT%5D%20Re%3A%20minimally%20dependent%20Teams%20sharing%20a%20code%20base" style="text-decoration: none; color: #2D50FD;">
Reply to sender </a>
</td>
<td>&bull;</td>
<td style="font-size: 12px; font-family: arial; padding: 7px 5px 5px;">
<a href="mailto:***@yahoogroups.com?subject=Re%3A%20%5BSCRUMDEVELOPMENT%5D%20Re%3A%20minimally%20dependent%20Teams%20sharing%20a%20code%20base" style="text-decoration: none; color: #2D50FD">
Reply to group </a>
</td>
<td>&bull;</td>
<td style="font-size: 12px; font-family: arial; padding: 7px 5px 5px;" >
<a href="https://groups.yahoo.com/neo/groups/SCRUMDEVELOPMENT/conversations/newtopic;_ylc=X3oDMTJldmU3ODZmBF9TAzk3MzU5NzE0BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA250cGMEc3RpbWUDMTQyMzkyOTIzOA--" style="text-decoration: none; color: #2D50FD">Start a New Topic</a>
</td>
<td>&bull;</td>
<td style="font-size: 12px; font-family: arial; padding: 7px 5px 5px;color: #2D50FD;" >
<a href="https://groups.yahoo.com/neo/groups/SCRUMDEVELOPMENT/conversations/topics/58132;_ylc=X3oDMTM2aTBiNGoxBF9TAzk3MzU5NzE0BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNzA1MDA3NzA5BG1zZ0lkAzU4MTM0BHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTQyMzkyOTIzOAR0cGNJZAM1ODEzMg--" style="text-decoration: none; color: #2D50FD;">Messages in this topic</a>
(3)
</td>
</tr>
</tbody>
</table>



<!------- Start Nav Bar ------>
<!-- |**|begin egp html banner|**| -->
<!-- |**|end egp html banner|**| -->


<div id="ygrp-grfd" style="font-family: Verdana; font-size: 12px; padding: 15px 0;">

<!-- |**|begin egp html banner|**| -->

To Post a message, send it to:&nbsp;&nbsp; ***@eGroups.com<BR>
To Unsubscribe, send a blank message to: SCRUMDEVELOPMENT-***@eGroups.com
<!-- |**|end egp html banner|**| -->

</div>




<!-- |**|begin egp html banner|**| -->
<div id="ygrp-vital" style="background-color: #f2f2f2; font-family: Verdana; font-size: 10px; margin-bottom: 10px; padding: 10px;">

<span id="vithd" style="font-weight: bold; color: #333; text-transform: uppercase; "><a href="https://groups.yahoo.com/neo/groups/SCRUMDEVELOPMENT/info;_ylc=X3oDMTJldWdhcTFuBF9TAzk3MzU5NzE0BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTQyMzkyOTIzOA--" style="text-decoration: none;">Visit Your Group</a></span>

<ul style="list-style-type: none; margin: 0; padding: 0; display: inline;">
<li style="border-right: 1px solid #000; font-weight: 700; display: inline; padding: 0 5px; margin-left: 0;">
<span class="cat"><a href="https://groups.yahoo.com/neo/groups/SCRUMDEVELOPMENT/members/all;_ylc=X3oDMTJmaWlsMDRqBF9TAzk3MzU5NzE0BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwN2dGwEc2xrA3ZtYnJzBHN0aW1lAzE0MjM5MjkyMzg-" style="text-decoration: none;">New Members</a></span>
<span class="ct" style="color: #ff7900;">1</span>
</li>
</ul>
</div>


<div id="ft" style="font-family: Arial; font-size: 11px; margin-top: 5px; padding: 0 2px 0 0; clear: both;">
<a href="https://groups.yahoo.com/neo;_ylc=X3oDMTJkb2I2bTBnBF9TAzk3NDc2NTkwBGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA2dmcARzdGltZQMxNDIzOTI5MjM4" style="float: left;"><img src="Loading Image..." height="15" width="137" alt="Yahoo! Groups" style="border: 0;"/></a>
<div style="color: #747575; float: right;"> &bull; <a href="https://info.yahoo.com/privacy/us/yahoo/groups/details.html" style="text-decoration: none;">Privacy</a> &bull; <a href="mailto:SCRUMDEVELOPMENT-***@yahoogroups.com?subject=Unsubscribe" style="text-decoration: none;">Unsubscribe</a> &bull; <a href="https://info.yahoo.com/legal/us/yahoo/utos/terms/" style="text-decoration: none;">Terms of Use</a> </div>
</div>
<br>

<!-- |**|end egp html banner|**| -->

</div> <!-- ygrp-msg -->


<!-- Sponsor -->
<!-- |**|begin egp html banner|**| -->
<div id="ygrp-sponsor" style="width:160px; float:right; clear:none; margin:0 0 25px 0; background: #fff;">

<!-- Start Recommendations -->
<div id="ygrp-reco">
</div>
<!-- End Recommendations -->



</div> <!-- |**|end egp html banner|**| -->

<div style="clear:both; color: #FFF; font-size:1px;">.</div>
</div>

<img src="http://geo.yahoo.com/serv?s=97359714/grpId=1569064/grpspId=1705007709/msgId=58134/stime=1423929238" width="1" height="1"> <br>

<img src="http://y.analytics.yahoo.com/fpc.pl?ywarid=515FB27823A7407E&a=10001310322279&js=no&resp=img" width="1" height="1">

<div style="color: #fff; height: 0;">__,_._,___</div>
<!--~-|**|PrettyHtmlEnd|**|-~-->

</body>

<!--~-|**|PrettyHtmlStart|**|-~-->
<head>
<style type="text/css">
<!--
#ygrp-mkp {
border: 1px solid #d8d8d8;
font-family: Arial;
margin: 10px 0;
padding: 0 10px;
}

#ygrp-mkp hr {
border: 1px solid #d8d8d8;
}

#ygrp-mkp #hd {
color: #628c2a;
font-size: 85%;
font-weight: 700;
line-height: 122%;
margin: 10px 0;
}

#ygrp-mkp #ads {
margin-bottom: 10px;
}

#ygrp-mkp .ad {
padding: 0 0;
}

#ygrp-mkp .ad p {
margin: 0;
}

#ygrp-mkp .ad a {
color: #0000ff;
text-decoration: none;
}
#ygrp-sponsor #ygrp-lc {
font-family: Arial;
}

#ygrp-sponsor #ygrp-lc #hd {
margin: 10px 0px;
font-weight: 700;
font-size: 78%;
line-height: 122%;
}

#ygrp-sponsor #ygrp-lc .ad {
margin-bottom: 10px;
padding: 0 0;
}

#actions {
font-family: Verdana;
font-size: 11px;
padding: 10px 0;
}

#activity {
background-color: #e0ecee;
float: left;
font-family: Verdana;
font-size: 10px;
padding: 10px;
}

#activity span {
font-weight: 700;
}

#activity span:first-child {
text-transform: uppercase;
}

#activity span a {
color: #5085b6;
text-decoration: none;
}

#activity span span {
color: #ff7900;
}

#activity span .underline {
text-decoration: underline;
}

.attach {
clear: both;
display: table;
font-family: Arial;
font-size: 12px;
padding: 10px 0;
width: 400px;
}

.attach div a {
text-decoration: none;
}

.attach img {
border: none;
padding-right: 5px;
}

.attach label {
display: block;
margin-bottom: 5px;
}

.attach label a {
text-decoration: none;
}

blockquote {
margin: 0 0 0 4px;
}

.bold {
font-family: Arial;
font-size: 13px;
font-weight: 700;
}

.bold a {
text-decoration: none;
}

dd.last p a {
font-family: Verdana;
font-weight: 700;
}

dd.last p span {
margin-right: 10px;
font-family: Verdana;
font-weight: 700;
}

dd.last p span.yshortcuts {
margin-right: 0;
}

div.attach-table div div a {
text-decoration: none;
}

div.attach-table {
width: 400px;
}

div.file-title a, div.file-title a:active, div.file-title a:hover, div.file-title a:visited {
text-decoration: none;
}

div.photo-title a, div.photo-title a:active, div.photo-title a:hover, div.photo-title a:visited {
text-decoration: none;
}

div#ygrp-mlmsg #ygrp-msg p a span.yshortcuts {
font-family: Verdana;
font-size: 10px;
font-weight: normal;
}

.green {
color: #628c2a;
}

.MsoNormal {
margin: 0 0 0 0;
}

o {
font-size: 0;
}

#photos div {
float: left;
width: 72px;
}

#photos div div {
border: 1px solid #666666;
height: 62px;
overflow: hidden;
width: 62px;
}

#photos div label {
color: #666666;
font-size: 10px;
overflow: hidden;
text-align: center;
white-space: nowrap;
width: 64px;
}

#reco-category {
font-size: 77%;
}

#reco-desc {
font-size: 77%;
}

.replbq {
margin: 4px;
}

#ygrp-actbar div a:first-child {
/* border-right: 0px solid #000;*/
margin-right: 2px;
padding-right: 5px;
}

#ygrp-mlmsg {
font-size: 13px;
font-family: Arial, helvetica,clean, sans-serif;
*font-size: small;
*font: x-small;
}

#ygrp-mlmsg table {
font-size: inherit;
font: 100%;
}

#ygrp-mlmsg select, input, textarea {
font: 99% Arial, Helvetica, clean, sans-serif;
}

#ygrp-mlmsg pre, code {
font:115% monospace;
*font-size:100%;
}

#ygrp-mlmsg * {
line-height: 1.22em;
}

#ygrp-mlmsg #logo {
padding-bottom: 10px;
}


#ygrp-msg p a {
font-family: Verdana;
}

#ygrp-msg p#attach-count span {
color: #1E66AE;
font-weight: 700;
}

#ygrp-reco #reco-head {
color: #ff7900;
font-weight: 700;
}

#ygrp-reco {
margin-bottom: 20px;
padding: 0px;
}

#ygrp-sponsor #ov li a {
font-size: 130%;
text-decoration: none;
}

#ygrp-sponsor #ov li {
font-size: 77%;
list-style-type: square;
padding: 6px 0;
}

#ygrp-sponsor #ov ul {
margin: 0;
padding: 0 0 0 8px;
}

#ygrp-text {
font-family: Georgia;
}

#ygrp-text p {
margin: 0 0 1em 0;
}

#ygrp-text tt {
font-size: 120%;
}

#ygrp-vital ul li:last-child {
border-right: none !important;
}
-->
</style>
</head>

<!--~-|**|PrettyHtmlEnd|**|-~-->
</html>
<!-- end group email -->
steve@ootac.com [SCRUMDEVELOPMENT]
2015-02-14 16:34:11 UTC
Permalink
Then I would suggest that the team planning needs close scrutiny.


If everything in the sprint is a 'Must Have' and there is a risk every day of not completing. then I suggest that they are just doing 'mini-waterfalls' - fixed time - fixed resource - fixed cost. Unless the teams' estimates are always equal to their actuals, it will never work.
Charles Bradley - Professional Scrum Trainer and Coach chuck-lists2@emailchuck.com [SCRUMDEVELOPMENT]
2015-02-14 18:35:17 UTC
Permalink
Jean,
I'm with Steve on most of this, with the exception that stopping the sprint is probably not a good answer as that should *only* be done if there is absolutely no business value left in the entire increment.  Canceling a sprint because teams can't execute a good Scrum implementation is not a good idea IMO.
I'm especially in agreement that there really is no such thing as a failed sprint.  The only failed sprint, in my view, is a failure to do Scrum correctly.  (notice I didn't say failure to do it well or awesome - just failure to do it correctly)

You're going to have a hard time finding a case study with the exact specs you're looking for.  We have plenty of Scrum case studies up on the http://ScrumCaseStudies.com web site, but I'm not sure we have any with enough detail that is the exact specs of what you're looking for.
The closest to what you're looking for, IMO, is what is described by Large Scale Scrum.  They have some case studies up there on their site, and their books describe a bazillion different ways of doing team coordination in multi-team scenarios.  And all of their advice is based on real life experiences of organizations up to 2500 people working in Scrum Teams.
I've personally coached teams as you describe(as I'm sure many on this list have), with the one exception that most of the places where I coach Large Scale Scrum are not yet ready to create potentially releasable increments every sprint yet, due to large impediments that they have not yet removed.
 -------
Charles Bradley
Professional Scrum Trainer
Scrum Coach-in-Chief
http://ScrumCrazy.com


From: "***@ootac.com [SCRUMDEVELOPMENT]" <***@yahoogroups.com>
To: ***@yahoogroups.com
Sent: Saturday, February 14, 2015 9:34 AM
Subject: [SCRUMDEVELOPMENT] Re: minimally dependent Teams sharing a code base

#yiv0362034832 #yiv0362034832 -- #yiv0362034832 .yiv0362034832ygrp-photo-title{clear:both;font-size:smaller;height:15px;overflow:hidden;text-align:center;width:75px;}#yiv0362034832 div.yiv0362034832ygrp-photo{background-position:center;background-repeat:no-repeat;background-color:white;border:1px solid black;height:62px;width:62px;}#yiv0362034832 div.yiv0362034832photo-title a, #yiv0362034832 div.yiv0362034832photo-title a:active, #yiv0362034832 div.yiv0362034832photo-title a:hover, #yiv0362034832 div.yiv0362034832photo-title a:visited {text-decoration:none;}#yiv0362034832 div.yiv0362034832attach-table div.yiv0362034832attach-row {clear:both;}#yiv0362034832 div.yiv0362034832attach-table div.yiv0362034832attach-row div {float:left;}#yiv0362034832 p {clear:both;padding:15px 0 3px 0;overflow:hidden;}#yiv0362034832 div.yiv0362034832ygrp-file {width:30px;}#yiv0362034832 div.yiv0362034832attach-table div.yiv0362034832attach-row div div a {text-decoration:none;}#yiv0362034832 div.yiv0362034832attach-table div.yiv0362034832attach-row div div span {font-weight:normal;}#yiv0362034832 div.yiv0362034832ygrp-file-title {font-weight:bold;}#yiv0362034832 #yiv0362034832 #yiv0362034832 #yiv0362034832 --#yiv0362034832ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv0362034832 #yiv0362034832ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv0362034832 #yiv0362034832ygrp-mkp #yiv0362034832hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv0362034832 #yiv0362034832ygrp-mkp #yiv0362034832ads {margin-bottom:10px;}#yiv0362034832 #yiv0362034832ygrp-mkp .yiv0362034832ad {padding:0 0;}#yiv0362034832 #yiv0362034832ygrp-mkp .yiv0362034832ad p {margin:0;}#yiv0362034832 #yiv0362034832ygrp-mkp .yiv0362034832ad a {color:#0000ff;text-decoration:none;}#yiv0362034832

Then I would suggest that the team planning needs close scrutiny.
If everything in the sprint is a 'Must Have' and there is a risk every day of not completing. then I suggest that they are just doing 'mini-waterfalls' - fixed time - fixed resource - fixed cost.  Unless the teams' estimates are always equal to their actuals, it will never work.
Alan Dayley alandd@dayleyagile.com [SCRUMDEVELOPMENT]
2015-02-14 20:16:39 UTC
Permalink
Jean,

You are describing a situation that is not uncommon. You and the teams need
to explore the answers together. Continued transparency and continued
re-alignment will be important. And technology structure, which I'll
address first.

All the teams are working from the same code base. The Definition of Done
for all the teams should be the same. That way when Team A says something
is done, Team B knows what that means, as well as the stakeholders. Also
there should be one integration server or system where all the work of all
the teams is integrated often (at least every 24 hours) or continuously.
The shared Definition of Done should included "Runs on the one and only,
shared, product integration platform." This way if Team A breaks something
that any other team needs, you find it immediately. The integrated product
should always work. You may have to dedicate some time to get such
technological infrastructure in place. It is worth every minute invested!

As to planning the backlogs and work, I suggest using something like what I
call the Product Wall. It is a release plan showing large feature groups or
epics, which team is working on them, where the dependencies are and when
the work is expected to happen. Please see this slide deck if you want
details about how this works:
http://www.slideshare.net/bigvisible/using-the-product-wall-release-workshop-alignment-from-vision-to-sprint-backlogs
In particular the slides 77-82 and 92-97 provide the intra-team
transparency and alignment parts.

There are other ways of doing multi-team planning and work. You could
borrow some of the SAFe (Scaled Agile Framework) ideas around the "release
train." You could divide the code base along "sub-product" boundaries and
give each team a semi-independent sub-product to own.

Lots of options for you to explore. I don't think you will find a read-made
solution that will fit perfectly. Work with the teams to create one.

Alan


On Sat, Feb 14, 2015 at 11:35 AM, Charles Bradley - Professional Scrum
Post by Charles Bradley - Professional Scrum Trainer and Coach chuck-***@emailchuck.com [SCRUMDEVELOPMENT]
Jean,
I'm with Steve on most of this, with the exception that stopping the
sprint is probably not a good answer as that should *only* be done if there
is absolutely no business value left in the entire increment. Canceling a
sprint because teams can't execute a good Scrum implementation is not a
good idea IMO.
I'm especially in agreement that there really is no such thing as a failed
sprint. The only failed sprint, in my view, is a failure to do Scrum
correctly. (notice I didn't say failure to do it well or awesome - just
failure to do it correctly)
You're going to have a hard time finding a case study with the exact specs
you're looking for. We have plenty of Scrum case studies up on the
http://ScrumCaseStudies.com <http://scrumcasestudies.com/> web site, but
I'm not sure we have any with enough detail that is the exact specs of what
you're looking for.
The closest to what you're looking for, IMO, is what is described by Large
Scale Scrum <http://less.works/>. They have some case studies up there
on their site, and their books describe a bazillion different ways of doing
team coordination in multi-team scenarios. And all of their advice is
based on real life experiences of organizations up to 2500 people working
in Scrum Teams.
I've personally coached teams as you describe(as I'm sure many on this
list have), with the one exception that most of the places where I coach
Large Scale Scrum are not yet ready to create potentially releasable
increments every sprint yet, due to large impediments that they have not
yet removed.
-------
Charles Bradley
Professional Scrum Trainer
Scrum Coach-in-Chief
http://ScrumCrazy.com <http://www.scrumcrazy.com/>
------------------------------
*Sent:* Saturday, February 14, 2015 9:34 AM
*Subject:* [SCRUMDEVELOPMENT] Re: minimally dependent Teams sharing a
code base
Then I would suggest that the team planning needs close scrutiny.
If everything in the sprint is a 'Must Have' and there is a risk every day
of not completing. then I suggest that they are just doing
'mini-waterfalls' - fixed time - fixed resource - fixed cost. Unless the
teams' estimates are always equal to their actuals, it will never work.
steve@ootac.com [SCRUMDEVELOPMENT]
2015-02-14 22:32:23 UTC
Permalink
Charles - but that was the point - the teams are releasing every sprint - by which I assume that means go live ie they have an increment every sprint. If one team cannot produce the features that another team depends on for the release, what else can you do but stop the sprint/release?
Ron Jeffries ronjeffries@acm.org [SCRUMDEVELOPMENT]
2015-02-14 23:39:16 UTC
Permalink
Steve,
Post by ***@ootac.com [SCRUMDEVELOPMENT]
If one team cannot produce the features that another team depends on for the release, what else can you do but stop the sprint/release?
Just one answer should suffice to show that this is not the only answer. My answer is: do not stop the Sprint, and do not release that team’s increment, and any increments depending on it.

Now then: we no longer need to stop the Sprint.

In the Retrospective, observe that this did not make us happy. Observe the reason: Team B could not release because there was something in the work of Team A upon which they depended.

That is, Team B was not cross-functional as required by Scrum: It did not include all the skills necessary to complete its work.

Fix that.

Hint: there is more than one way to fix it.

Ron Jeffries
ronjeffries.com <http://ronjeffries.com/>
Before you contradict an old man, my fair friend, you should endeavor to understand him. - George Santayana
steve@ootac.com [SCRUMDEVELOPMENT]
2015-02-15 09:51:23 UTC
Permalink
Thank you Ron for pointing out that I omitted the Retrospective bit; totally agree; that is the 'most effective' way to fix the problem but is it the only way (I know if you are being dogmatic Scrum it is but I'm playing 'devil's advocate a bit here).


However, you took exception to my point about stopping sprint/release. I agree you could do it your way but should you?


My position is based on managing stakeholder expectations (not just the PO but others). During and from the planning they expect 'xyz' from this sprint/increment. One of the major problems with during product development is that too often in the pre-Agile world 'developers' did not tell the stakeholders that they would not be getting what they expected until close to or at 'the end'; this has led to frustration and mistrust.


If we use a process that lets the relevant stakeholders know as soon as practicable that they are not likely to get their 'minimums by the agreed date, then they have a chance to make acceptable changes before that date.


One problem with the original question is that there is no indication of how important to the stakeholders are the specific contents of the releases. What planning have they made on the assumption that 'xyz' will be available? What will be the customer service impact of not getting 'xyz'?


Another problem is that the original question gives no indication of sprint length. If the sprints are longer than one month, then it is possible that fundamental problem lies not with the skill base of the team but with the Scrum implementation.


I agree with you that stopping the sprint is not the only action that could be taken on finding a problem but, to me, it is still the best way to handle stakeholder expectations.
Ron Jeffries ronjeffries@acm.org [SCRUMDEVELOPMENT]
2015-02-15 10:42:22 UTC
Permalink
Hello, Steve,
Post by ***@ootac.com [SCRUMDEVELOPMENT]
Thank you Ron for pointing out that I omitted the Retrospective bit; totally agree; that is the 'most effective' way to fix the problem but is it the only way (I know if you are being dogmatic Scrum it is but I'm playing 'devil's advocate a bit here).
I guess I missed the way you offered to fix the problem. No doubt there are many but the Retrospective is the approach of first resort and you didn’t mention it.
Post by ***@ootac.com [SCRUMDEVELOPMENT]
However, you took exception to my point about stopping sprint/release. I agree you could do it your way but should you?
In my experience, and I hope in your training, stopping the Sprint is an action of last resort. Every other reasonable possibility should be exhausted before stopping the Sprint. To stop the Sprint is to say that much of what has been undertaken in that Sprint is wasted. Unless that’s the case, it would be unwise to stop it.
Post by ***@ootac.com [SCRUMDEVELOPMENT]
My position is based on managing stakeholder expectations (not just the PO but others). During and from the planning they expect 'xyz' from this sprint/increment. One of the major problems with during product development is that too often in the pre-Agile world 'developers' did not tell the stakeholders that they would not be getting what they expected until close to or at 'the end'; this has led to frustration and mistrust.
If the stakeholder expectations are not going to be met, there are at least two significant possibilities. One is that the team somehow cannot do what they thought they could do. Another is that the stakeholder expectations are not what they should be.

For example, quite often, stakeholders are misinformed as to what will be accomplished. If that is the case, it would be better to “stop the stakeholders” than to stop the work.

In addition, I’m not sure we’ve discussed here that the Product Owner is the only one who can stop the Sprint.
Post by ***@ootac.com [SCRUMDEVELOPMENT]
If we use a process that lets the relevant stakeholders know as soon as practicab le that they are not likely to get their 'minimums by the agreed date, then they have a chance to make acceptable changes before that date.
Certainly it is important to keep stakeholders informed. The Product Owner is responsible for making the Sprint progress visible to the stakeholders. The stakeholders can influence the Product Owner to stop the Sprint: they cannot require it. (It might be wise for the PO to do as stakeholders wish. It might be unwise: the Product Owner has responsibility, not the stakeholders.)

If we stop the sprint, as you like to shout, there will be work in process which is lost. Even if it is picked up later, there will be cracks in the code. The team will be demoralized and disrupted. It will be difficult to proceed in a sensible humane fashion. Probably there will be an Inquiry.

After all, the running cost of a team, in US dollars, is probably around $50,000 per week. Especially since you seem to be contemplating very long Sprints (we’ll come to that in a moment), there is a huge cost to stopping a Sprint. It will be far better to do something to bring matters into alignment than to cancel an expensive effort.
Post by ***@ootac.com [SCRUMDEVELOPMENT]
One problem with the original question is that there is no indication of how important to the stakeholders are the specific contents of the releases. What planning have they made on the assumption that 'xyz' will be available? What will be the customer service impact of not getting 'xyz'?
Quite so. And quite likely, the impact will be small. If ‘xyz’ is important, stopping the Sprint will only make it later. The more important ‘xyz’ is, the worse it is to stop the Sprint.

Again, we see that while transparency is important, abrupt termination of development is often far less than ideal. (That’s my subtle way of saying “bad”.)
Post by ***@ootac.com [SCRUMDEVELOPMENT]
Another problem is that the original question gives no indication of sprint length. If the sprints are longer than one month, then it is possible that fundamental problem lies not with the skill base of the team but with the Scrum implementation.
Indeed, since the maximum length of the Sprint is supposed to be “one month or less”, and most everyone these days is using two weeks or less.

When teams using long Sprints have trouble delivering, it is generally considered that shortening the Sprint is one of the best things to do.

I don’t recall anyone suggesting that the problem lies with “the skill base of the team”. The point of Scrum is “Inspect and Adapt”, and while canceling a Sprint may be necessary, it is an action of last resort, not first.

It may be that making abrupt changes is somehow a good thing in your environment, but if it is, I would be quite surprised.
Post by ***@ootac.com [SCRUMDEVELOPMENT]
I agree with you that stopping the sprint is not the only action that could be taken on finding a problem but, to me, it is still the best way to handle stakeholder expectations.
I believe that in the industry we refer to “managing stakeholder expectations”. That is largely a matter of providing information.

If you stop the Sprint, you’ll start wasting $5,000 or $10,000 per day in US terms. The stakeholders will not likely be able to respond instantly to the situation, especially since they’d be fools not to fire a Product Owner who came running to them every time something went wrong, saying “Hello, I’ve started throwing thousand dollar bills into the fire until you come up with some kind of answer”.

I believe that putting a brick wall in front of progress by stopping the Sprint is a far inferior approach to making smaller adjustments that will bring useful results closer rather than further away.

I would be quite interested to read some experience reports about what has happened when you’ve stopped a few Sprints on your projects. I would not expect favorable outcomes, but would be happy to be surprised.

Ron Jeffries
ronjeffries.com <http://ronjeffries.com/>
If not now, when? -- Rabbi Hillel
steve@ootac.com [SCRUMDEVELOPMENT]
2015-02-15 12:58:48 UTC
Permalink
Hi Ron


As always the answer to a relatively seeming straightforward question expands to many ifs, ands and buts!!


I guess I missed the way you offered to fix the problem. No doubt there are many but the Retrospective is the approach of first resort and you didn’t mention it.

I totally agree - it is the first step in the process to trigger that retro that we are at odds with.


To stop the Sprint is to say that much of what has been undertaken in that Sprint is wasted


Not sure that I agree totally with this. Yes, it will be more difficult to return to unfinished code but that can be taken care of with proper forward planning. A judgement has to made about the extra cost of quality checking/refactoring against the cost of slower production; not a waste but a necessary cost of solving an unforeseen problem.


Another is that the stakeholder expectations are not what they should be


I get my Teams and stakeholders to agree minimums from a sprint; that minimum is based on 50-65% of the estimated effort or story points for the sprint depending on 'maturity of the team. The stakeholder expectations are to get the minimums in the 'worst case'. This way, I believe that the stakeholder expectations can never be more that what they should be.


I’m not sure we’ve discussed here that the Product Owner is the only one who can stop the Sprint


We didn't and I agree. The Team or stakeholders can recommend but it would be a brave PO to go against either group unless they have a 'magic sponge'!


The team will be demoralized and disrupted. It will be difficult to proceed in a sensible humane fashion


An interesting assumption. Just jumping ahead to your request for case studies, I have only seen/recommended this 4 times in over 20 years of Managed RAD/Agile experience. In the first case I was the Scrum Master equivalent for a single team and the problem was completely out the control of the team ; in 2 cases where I was appointed a coach this happened in the first or second 2 week sprint; in the 3rd, I was doing an audit for a so-called programme where the teams were supposed to be applying 'Agile' . Yes the team were disrupted (but it was early days in 2 of the cases) but the teams were not demoralised - the opposite in fact! They were grateful that the process highlighted flaws in their thinking as soon as possible. Indeed, in one case, one of the team expressed the feeling that he never thought 'that' would work. So not only were the teams pleased to have found flaws early that they could fix without 'heavy fallout' later but at least one developer learned the 'meanings' of empowerment and joint responsibility.


Especially since you seem to be contemplating very long Sprints


Wasn't me who was contemplating long sprints - I merely pointed out that we don't know the sprint lengths that the original poster is using. My point was that the problem that the original posters teams are having might be based on a flawed Scrum implementation rather than your "That is, Team B was not cross-functional as required by Scrum: It did not include all the skills necessary to complete its work"


Totally agree that most 'Agile' teams are now working to 2 week sprints/iterations/development timeboxes and I note that it is interesting that DSDM originally said 2-6 weeks, Scrum said 30 days and XP 1 week; inspection and adaption seems to have produced a tacit agreement that 2 weeks is optimum.


And quite likely, the impact (of not getting xyz) will be small


Not sure why you assert that. Not getting minimums always has a significant impact in my world. If not getting xyz would have little impact, it shouldn't have been part of the minimums in the first place.


If ‘xyz’ is important, stopping the Sprint will only make it later. The more important ‘xyz’ is, the worse it is to stop the Sprint


Let's just revisit the context of the original question. If other teams are dependant on xyz being produced in this sprint, if xyz cannot be produced, then you not only do not get xyz but you also do not get what is dependant on xyz.
Yes, it will take longer to get xyz by stopping the sprint but you have to balance this with stakeholder expectations and sorting the problems for all the affected teams as soon as possible. IMHO, stakeholder expectations and fixing very significant problems holds the balance in the cases that I have seen.


I don’t recall anyone suggesting that the problem lies with “the skill base of the team”


You did :) - see above


If you stop the Sprint, you’ll start wasting $5,000 or $10,000 per day in US terms. The stakeholders will not likely be able to respond instantly to the situation, especially since they’d be fools not to fire a Product Owner who came running to them every time something went wrong, saying “Hello, I’ve started throwing thousand dollar bills into the fire until you come up with some kind of answer”.


A little inflammatory don't you think and not in any way what I was saying. The relevant stakeholders are not required to fix the problem but they should be involved in the fix and agreeing the re-plan. Again a balance must be made between the so-called waste of money in the short-term with the potential cost in the medium to long term. I have to say that I thought one of the 'drivers' I the Agile movement was to come up with ways to minimise long-term costs from errors by spending relatively little in the short term. What is refactoring all about if this is not true?


I would be quite interested to read some experience reports about what has happened when you’ve stopped a few Sprints on your projects. I would not expect favorable outcomes, but would be happy to be surprised


As I said, I have only seen/recommended stopping a sprint on 4 occasions:
1. An organisational requirement required 3 of the 4 team members to be taken away for other duties at no notice (Armed Forces environment). The stakeholders were not aware of the requirement, so I stopped the current sprint, gathered the stakeholders and remainder of the team together and they agreed a re-plan. The senior stakeholder thanked the team for bringing the matter to his attention as soon as possible as he was now able to revise his department's plans with the minimum of disruption.


2. I was appointed coach to 2 teams after the "project-setup" on the request of the team because they were new to Agile and felt that they would need help; the Scrum Master in both cases had only just completed the Certified Scrum Master course. It became clear in the first or second sprint that the architecture 'imposed on the teams', the stakeholder expectations were actually higher than what they agreed to (one of your points) and the ordering applied to the PB was not logical from a business perspective as well as a technical perspective. I recommended stopping the sprints as soon as the teams realised that they would not meet the agreed minimums. The result of the deliberations with the stakeholders, senior technical people and the team was that the "project setup" was flawed and in both cases the product development went back and "re-ran the project setup". The business stakeholders and senior technical people were very grateful that the problems had been addressed as early as possible and more than one said words to the affect "Now I know what Fail Fast means".


3. I was asked to audit a very large, strategic programme where the 'partner' supplier (on-site) was supposed to using 'Agile'. It was a mess!! I chose to start by auditing the longest running project (18 months and never delivered anything!!!). I sat in on a sprint review where I discovered that agreed minimums seemed to mean nothing to the development team and the business never said anything because it was what they were used to! The team arbitrarily developed low value features before high value ones because 'they were easier'. I kept a close eye on the team during the next sprint attending the stand-ups and asking a 4th question - " are you going to meet your minimums". When the answer was "No", I recommended to the Agile PM that he advise the PO equivalent to stop the sprint. He was reluctant to say the least because he thought it would reflect negatively on his supplier company. However, we both went to the 'PO' and explained and he agreed that a shake-up was necessary and long overdue. Yes, the 'brown stuff' did hit the fan but when all parties were brought around the same table and sensible discussion eventually ensued, it was discovered that the product requirements were actually unachievable without buying something like a Super Cray!!! The product development was stopped. Why it took 18 months to come to that conclusion I never got totally to the bottom of but it was a Civil Service organisation.
The other projects, having seen what had happened, instituted a sort of retrospective including stakeholders to analyse their own product development and with some help from myself changed their approach and philosophy. Even the head of the 'partner' supplier eventually thanked me although he wanted me out the door on a rail when I first recommended stopping the sprint.


In an ideal world we would never not be able to meet minimums but we do not live in an ideal world.


With good planning (my word for 'good') having to stop a sprint is very, very rare but the impact of doing so is far reaching in uncovering and solving 'hidden problems' and getting developers and customers to trust each other.


Phew!!
Charles Bradley - Professional Scrum Trainer and Coach chuck-lists2@emailchuck.com [SCRUMDEVELOPMENT]
2015-02-16 02:36:02 UTC
Permalink
100% in agreement with Ron here (see, we don't always disagree!).
I'll add a couple of things:a) A good Scrum of Scrums can handle some of these challenges as well.  Retrospection and root cause need not wait until the end of the Sprint for the formal retro.  It can be done any time.b) A well functioning product group can handle some of these challenges without the need for a Scrum of Scrums.  How about they "just talk"?
c) A well crafted Sprint Goal would allow for the sprints to continue, as the Dev Team and PO has the right to completely re-write the PBL in the middle of a Sprint, so long as the Sprint Goal is not endangered.  One of the major purposes of the Sprint Goal is to handle complexity/change *even within the sprint*.
(Note also that the other release valve you have in the sprint is to add/drop scope -- again, so long as the Sprint Goal is not endangered)
I'm also very uncomfortable as to your "meet your minimums" practice, which doesn't sound in line with Scrum principles.  Sounds, again, more like fixed scope/fixed date thinking, or command and control leadership.  I'm all for communication both inside and outside the team, but I'm just not sure of your "meet your minimums" concept.  -------
Charles Bradley
Professional Scrum Trainer
Scrum Coach-in-Chief
http://ScrumCrazy.com


From: "Ron Jeffries ***@acm.org [SCRUMDEVELOPMENT]" <***@yahoogroups.com>
To: ***@yahoogroups.com
Sent: Sunday, February 15, 2015 3:42 AM
Subject: Re: [SCRUMDEVELOPMENT] Re: minimally dependent Teams sharing a code base

#yiv7765189257 #yiv7765189257 -- #yiv7765189257 .yiv7765189257ygrp-photo-title{clear:both;font-size:smaller;height:15px;overflow:hidden;text-align:center;width:75px;}#yiv7765189257 div.yiv7765189257ygrp-photo{background-position:center;background-repeat:no-repeat;background-color:white;border:1px solid black;height:62px;width:62px;}#yiv7765189257 div.yiv7765189257photo-title a, #yiv7765189257 div.yiv7765189257photo-title a:active, #yiv7765189257 div.yiv7765189257photo-title a:hover, #yiv7765189257 div.yiv7765189257photo-title a:visited {text-decoration:none;}#yiv7765189257 div.yiv7765189257attach-table div.yiv7765189257attach-row {clear:both;}#yiv7765189257 div.yiv7765189257attach-table div.yiv7765189257attach-row div {float:left;}#yiv7765189257 p {clear:both;padding:15px 0 3px 0;overflow:hidden;}#yiv7765189257 div.yiv7765189257ygrp-file {width:30px;}#yiv7765189257 div.yiv7765189257attach-table div.yiv7765189257attach-row div div a {text-decoration:none;}#yiv7765189257 div.yiv7765189257attach-table div.yiv7765189257attach-row div div span {font-weight:normal;}#yiv7765189257 div.yiv7765189257ygrp-file-title {font-weight:bold;}#yiv7765189257 #yiv7765189257

Hello, Steve,

On Feb 15, 2015, at 4:51 AM, ***@ootac.com [SCRUMDEVELOPMENT] <***@yahoogroups.com> wrote:Thank you Ron for pointing out that I omitted the Retrospective bit; totally agree; that is the 'most effective' way to fix the problem but is it the only way (I know if you are being dogmatic Scrum it is but I'm playing 'devil's advocate a bit here).
I guess I missed the way you offered to fix the problem. No doubt there are many but the Retrospective is the approach of first resort and you didn’t mention it.

However, you took exception to my point about stopping sprint/release.  I agree you could do it your way but should you?
In my experience, and I hope in your training, stopping the Sprint is an action of last resort. Every other reasonable possibility should be exhausted before stopping the Sprint. To stop the Sprint is to say that much of what has been undertaken in that Sprint is wasted. Unless that’s the case, it would be unwise to stop it.

My position is based on managing stakeholder expectations (not just the PO but others).  During and from the planning they expect 'xyz' from this sprint/increment.  One of the major problems with during product development is that too often in the pre-Agile world 'developers' did not tell the stakeholders that they would not be getting what they expected until close to or at 'the end'; this has led to frustration and mistrust.
If the stakeholder expectations are not going to be met, there are at least two significant possibilities. One is that the team somehow cannot do what they thought they could do. Another is that the stakeholder expectations are not what they should be.
For example, quite often, stakeholders are misinformed as to what will be accomplished. If that is the case, it would be better to “stop the stakeholders” than to stop the work.
In addition, I’m not sure we’ve discussed here that the Product Owner is the only one who can stop the Sprint. 

If we use a process that lets the relevant stakeholders know as soon as practicab le that they are not likely to get their 'minimums by the agreed date, then they have a chance to make acceptable changes before that date.
Certainly it is important to keep stakeholders informed. The Product Owner is responsible for making the Sprint progress visible to the stakeholders. The stakeholders can influence the Product Owner to stop the Sprint: they cannot require it. (It might be wise for the PO to do as stakeholders wish. It might be unwise: the Product Owner has responsibility, not the stakeholders.)
If we stop the sprint, as you like to shout, there will be work in process which is lost. Even if it is picked up later, there will be cracks in the code. The team will be demoralized and disrupted. It will be difficult to proceed in a sensible humane fashion. Probably there will be an Inquiry. 
After all, the running cost of a team, in US dollars, is probably around $50,000 per week. Especially since you seem to be contemplating very long Sprints (we’ll come to that in a moment), there is a huge cost to stopping a Sprint. It will be far better to do something to bring matters into alignment than to cancel an expensive effort.

One problem with the original question is that there is no indication of how important to the stakeholders are the specific contents of the releases.  What planning have they made on the assumption that 'xyz' will be available?  What will be the customer service impact of not getting 'xyz'?
Quite so. And quite likely, the impact will be small. If ‘xyz’ is important, stopping the Sprint will only make it later. The more important ‘xyz’ is, the worse it is to stop the Sprint.
Again, we see that while transparency is important, abrupt termination of development is often far less than ideal. (That’s my subtle way of saying “bad”.)

Another problem is that the original question gives no indication of sprint length.  If the sprints are longer than one month, then it is possible that fundamental problem lies not with the skill base of the team but with the Scrum implementation.
Indeed, since the maximum length of the Sprint is supposed to be “one month or less”, and most everyone these days is using two weeks or less.
When teams using long Sprints have trouble delivering, it is generally considered that shortening the Sprint is one of the best things to do. 
I don’t recall anyone suggesting that the problem lies with “the skill base of the team”. The point of Scrum is “Inspect and Adapt”, and while canceling a Sprint may be necessary, it is an action of last resort, not first.
It may be that making abrupt changes is somehow a good thing in your environment, but if it is, I would be quite surprised.

I agree with you that stopping the sprint is not the only action that could be taken on finding a problem but, to me, it is still the best way to handle stakeholder expectations.
I believe that in the industry we refer to “managing stakeholder expectations”. That is largely a matter of providing information. 
If you stop the Sprint, you’ll start wasting $5,000 or $10,000 per day in US terms. The stakeholders will not likely be able to respond instantly to the situation, especially since they’d be fools not to fire a Product Owner who came running to them every time something went wrong, saying “Hello, I’ve started throwing thousand dollar bills into the fire until you come up with some kind of answer”. 
I believe that putting a brick wall in front of progress by stopping the Sprint is a far inferior approach to making smaller adjustments that will bring useful results closer rather than further away.
I would be quite interested to read some experience reports about what has happened when you’ve stopped a few Sprints on your projects. I would not expect favorable outcomes, but would be happy to be surprised.

Ron Jeffriesronjeffries.comIf not now, when? -- Rabbi Hillel
steve@ootac.com [SCRUMDEVELOPMENT]
2015-02-16 08:44:44 UTC
Permalink
Hi Charles


You wrote:


I'm also very uncomfortable as to your "meet your minimums" practice, which doesn't sound in line with Scrum principles. Sounds, again, more like fixed scope/fixed date thinking, or command and control leadership. I'm all for communication both inside and outside the team, but I'm just not sure of your "meet your minimums" concept.


It was me, not Ron, that spoke of 'minimums'.


Firstly, could you please tell me where I can find the 'Scrum principles' that make you uncomfortable about the concept of minimums?


Scrum says nothing about specific technical practices; as a Scrum Practitioner, do you not use any?


But to explain more fully. There is no fixed scope/fixed date thinking and definitely no command and control.


The Team/PO choose what is possible/likely that they can get Done in the next Sprint (The forecast) based on the PB estimates. They then discuss/agree a minimum that will be produced to allow for unforeseen 'problems'. These minimums are called various things like the 'Must Haves', the Minimum Viable Product (MVP), Minimum Marketable Features (MMF) etc.


The amount of the minimums is based on 50-65% of the estimated estimate for the total forecast based on the Development Team 'maturity' and 'comfort'.


I am not saying that the Development Team only work to produce the minimums; historically (and anecdotally) produce between 60-80% of the 'non-minimums as well.


So what advantage do I see in this technique over others?


My job primarily these days is as an Agile Implementation Coach and when I go to newly adopting organisations, the 'management', whilst attracted by the documented benefits of Agile are usually wary of the apparent lack of control and not knowing what is likely to produced when. Marketing departments depend on some sort of fore-knowledge to be able to do their job.


By introducing the concept of minimums at all levels of development (Sprint, Release and whole project), they become a lot more comfortable.


I have also found that many senior managers (business and technical) were junior managers in the early days of RAD which I have seen described as 'the inmates running the asylum' and they see Agile as a very closely related concept. I have to do something very early on to convince them that that is not true; words are not always enough; they have to see it in action from the 'get go'.


All I can say that this technique works very well for me and is completely in-line with the Agile Manifesto and Principles and there is nothing I have read in the Scrum Guide that mitigates against the practice.


If you do not see the same problems that I see in early implementations, then you obviously do not need to consider the technique. If you have a different way of solving these problems, please share them, in detail, with the rest of us.
Charles Bradley - Professional Scrum Trainer and Coach chuck-lists2@emailchuck.com [SCRUMDEVELOPMENT]
2015-02-16 02:23:53 UTC
Permalink
a) replan the work in the sprint so that something is releasable (releasable increment)  (maybe another team could switch off of what they are doing and help get it to releasable)
b) cut scope so that something is still releasablec) not deliver a potentially releasable increment, and then talk about why that happenedd) figure out why your product group can't produce a releasable increment every sprint -- apparently there is an impediment that needs removing.  Possibly a move to feature teams would help, or some other dependency removal mechanism could help.  Or maybe better refinement practice, etc.

Just because you plan a release doesn't mean a release has to happen.  That's fixed date/fixed scope waterfall thinking (which is also a fool's errand in software, and has been for over a decade).
 -------
Charles Bradley
Professional Scrum Trainer
Scrum Coach-in-Chief
http://ScrumCrazy.com


From: "***@ootac.com [SCRUMDEVELOPMENT]" <***@yahoogroups.com>
To: ***@yahoogroups.com
Sent: Saturday, February 14, 2015 3:32 PM
Subject: Re: [SCRUMDEVELOPMENT] Re: minimally dependent Teams sharing a code base

#yiv6482695874 #yiv6482695874 -- #yiv6482695874 .yiv6482695874ygrp-photo-title{clear:both;font-size:smaller;height:15px;overflow:hidden;text-align:center;width:75px;}#yiv6482695874 div.yiv6482695874ygrp-photo{background-position:center;background-repeat:no-repeat;background-color:white;border:1px solid black;height:62px;width:62px;}#yiv6482695874 div.yiv6482695874photo-title a, #yiv6482695874 div.yiv6482695874photo-title a:active, #yiv6482695874 div.yiv6482695874photo-title a:hover, #yiv6482695874 div.yiv6482695874photo-title a:visited {text-decoration:none;}#yiv6482695874 div.yiv6482695874attach-table div.yiv6482695874attach-row {clear:both;}#yiv6482695874 div.yiv6482695874attach-table div.yiv6482695874attach-row div {float:left;}#yiv6482695874 p {clear:both;padding:15px 0 3px 0;overflow:hidden;}#yiv6482695874 div.yiv6482695874ygrp-file {width:30px;}#yiv6482695874 div.yiv6482695874attach-table div.yiv6482695874attach-row div div a {text-decoration:none;}#yiv6482695874 div.yiv6482695874attach-table div.yiv6482695874attach-row div div span {font-weight:normal;}#yiv6482695874 div.yiv6482695874ygrp-file-title {font-weight:bold;}#yiv6482695874 #yiv6482695874 #yiv6482695874 #yiv6482695874 --#yiv6482695874ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv6482695874 #yiv6482695874ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv6482695874 #yiv6482695874ygrp-mkp #yiv6482695874hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv6482695874 #yiv6482695874ygrp-mkp #yiv6482695874ads {margin-bottom:10px;}#yiv6482695874 #yiv6482695874ygrp-mkp .yiv6482695874ad {padding:0 0;}#yiv6482695874 #yiv6482695874ygrp-mkp .yiv6482695874ad p {margin:0;}#yiv6482695874 #yiv6482695874ygrp-mkp .yiv6482695874ad a {color:#0000ff;text-decoration:none;}#yiv6482695874

Charles - but that was the point - the teams are releasing every sprint - by which I assume that means go live ie they have an increment every sprint.  If one team cannot produce the features that another team depends on for the release, what else can you do but stop the sprint/release?
Cass Dalton cassdalton73@gmail.com [SCRUMDEVELOPMENT]
2015-02-14 17:08:09 UTC
Permalink
Agreed. If everything is that coupled in the backlog that every story from

team 1 is dependent on a story from team 2, you should look at how work is

being decomposed and how stories are written. Even with a coherent product
backlog across teams, I would think you could allocate two independent
sprint backlogs that have minimal cross dependencies. If not, then I argue
that you really have one large team split into two rooms, not two separate
agile teams.


And I suggest that just dismissing an answer just because you don't like it
is indicative of not being open to hearing your true impediments. "No one
said Scrum was going to be easy". Its easy to blame the pain you feel when
adopting Scrum on Scrum itself. But its more likely that Scrum is just
showing you systemic dysfunction that was previously hidden from view.


Good luck,
Cass Dalton
Post by ***@ootac.com [SCRUMDEVELOPMENT]
Then I would suggest that the team planning needs close scrutiny.
If everything in the sprint is a 'Must Have' and there is a risk every day
of not completing. then I suggest that they are just doing
'mini-waterfalls' - fixed time - fixed resource - fixed cost. Unless the
teams' estimates are always equal to their actuals, it will never work.
Yves Hanoulle mailing@hanoulle.be [SCRUMDEVELOPMENT]
2015-02-14 16:08:19 UTC
Permalink
Post by Jean Richardson ***@azuregate.net [SCRUMDEVELOPMENT]
Your solution would cause these teams to stop their sprint almost every
day.
you make it sounds like that is something bad. agile lowers the water, so
we see the problems so we can fix them.
for me what was described was such a technique.
Post by Jean Richardson ***@azuregate.net [SCRUMDEVELOPMENT]
Anyone else, please?
when you have multiple people using the same codebase, make sure you add
tons of tests.
and continuous integration.
when tests fail, stop everything till it is fixed.
Post by Jean Richardson ***@azuregate.net [SCRUMDEVELOPMENT]
Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE
network.
*Sent: *Saturday, February 14, 2015 1:41 AM
*Subject: *[SCRUMDEVELOPMENT] Re: minimally dependent Teams sharing a
code base
Hi Jean.
First Point: Sprints do not fail!!
Second Point: Team commitment has been replaced by team forecast in the
Scrum Guide. The commitment used to be to the Sprint Goal but this was so
widely misinterpreted to committing to deliver all User Stories (a very
non- Agile interpretation) that "commitment" has been dropped.
So, to your question about minimal dependencies.
Each team should have some sort of minimum that is guaranteed (Moscow
rules, MVP, MMF etc). This minimum should represent around the 50-70% of
the estimated effort (depending on teams' Agile experience) for all the
User Stories forecast.
Dependencies across teams must always be within these minimums to 'guarantee' no problems.
Ah - you say -what if one team find that they cannot meet their minimums
(it happens very rarely)?
STOP THE SPRINT!
Inform the team(s) that have a dependency on the first team and then they
must decide if they can still meet their minimums. If they cannot - STOP
THEIR SPRINTS.
Affected teams should regroup with the relevant stakeholders and re-plan - "simples".
Although it is the same code base and same Product Backlog, what you have
is a Programme that needs coordination across teams but the application of
the basic Agile and Scrum principles as above will minimise any problems.
Hope that helps
Steve
--
Yves Hanoulle
Phone 00 32 467 43 38 32


Skype YvesHanoulle


Blog: www.Hanoulle.be <http://www.hanoulle.be/>


Coaching Question Of the Day: http://twitter.com/Retroflection
Wouter Lagerweij wouter@lagerweij.com [SCRUMDEVELOPMENT]
2015-02-14 20:35:21 UTC
Permalink
Hi Jean,

I've had a few situations that might be relevant. I've had teams that
worked on different parts of a larger system.

One particular situation had five teams working together, with a large
overlap between four of those teams with regards to codebase and technical
expertise. In that project, a team not managing to complete the
functionality they were working on might have had large impact. We mostly
managed to avoid that by being able to switch off functionality in the
system fairly quickly if needed. This was a batch processing system with
financial calculations. Different instruments could be enabled separately.

The teams I'm currently working with sometimes work together, and sometimes
separately. We change that depending on business needs. These teams are in
full 'continuous delivery' mode, and all new functionality is behind
feature toggles by default. Sometimes having one team not completing a
story might mean that we can't switch a feature on for customer to use. We
do also get situations where we have dependencies between stories,
especially if two teams are working on closely related features. They then
talk to each other...

The whole idea is to use our technical tools (version control...) to deal
with integration issues between teams. Adding feature toggles (and other CD
tools) to that mix improves on the possibilities. In my experience, adding
process layers to deal with this will mainly just slow you down. But it
might be necessary until you get the technical base in order.

Wouter
All –
I’m looking for example cases of multiple teams in the same code base and
sharing a product backlog releasing every sprint and functioning in a
fairly independent manner. Specifically, that their sprint commitments are
Team-specific, and it is possible for one Team to fail their sprint while
the other succeeds. I’m also interested in hearing where the minimal
dependencies are.
Thanks in advance for anything you can provide.
--- Jean
*[image: gate.site.jpg]*
*Jean Richardson*
Azure Gate Consulting
*~ **Repatterning the Human Experience of Work*
*AzureGate.net*
(503) 788-8998
--
Wouter Lagerweij | ***@lagerweij.com
http://www.lagerweij.com | @wouterla <http://twitter.com/#!/wouterla>
linkedin.com/in/lagerweij | +31(0)6 28553506
Michael James mj4scrum@gmail.com [SCRUMDEVELOPMENT]
2015-02-15 00:02:43 UTC
Permalink
I appreciate Wouter’s response because it addresses Jean’s specific request for *examples* of teams sharing a Product Backlog and codebase.

I’m guessing most people have already seen this excellent video about Spotify’s shared codebase.
http://vimeo.com/85490944 <http://vimeo.com/85490944>

—mj
(Michael)
One particular situation had five teams working together, with a large overlap between four of those teams with regards to codebase and technical expertise. In that project, a team not managing to complete the functionality they were working on might have had large impact. We mostly managed to avoid that by being able to switch off functionality in the system fairly quickly if needed. This was a batch processing system with financial calculations. Different instruments could be enabled separately.
The teams I'm currently working with sometimes work together, and sometimes separately. We change that depending on business needs. These teams are in full 'continuous delivery' mode, and all new functionality is behind feature toggles by default. Sometimes having one team not completing a story might mean that we can't switch a feature on for customer to use. We do also get situations where we have dependencies between stories, especially if two teams are working on closely related features. They then talk to each other...
The whole idea is to use our technical tools (version control...) to deal with integration issues between teams. Adding feature toggles (and other CD tools) to that mix improves on the possibilities. In my experience, adding process layers to deal with this will mainly just slow you down. But it might be necessary until you get the technical base in order.
srinivas chillara ceezone@yahoo.co.in [SCRUMDEVELOPMENT]
2015-02-15 06:18:03 UTC
Permalink
No, I haven't, so thanks awfully for the link!I just wonder why this is considered such an issue (common code base) if a high-grade SCM + CI is in place?
cheersSrinivas
From: "Michael James ***@gmail.com [SCRUMDEVELOPMENT]" <***@yahoogroups.com>
To: ***@yahoogroups.com
Sent: Sunday, 15 February 2015 5:32 AM
Subject: Re: [SCRUMDEVELOPMENT] minimally dependent Teams sharing a code base

  I appreciate Wouter’s response because it addresses Jean’s specific request for *examples* of teams sharing a Product Backlog and codebase.
I’m guessing most people have already seen this excellent video about Spotify’s shared codebase. http://vimeo.com/85490944
—mj(Michael)


On Feb 14, 2015, at 12:35 PM, Wouter Lagerweij ***@lagerweij.com [SCRUMDEVELOPMENT] <***@yahoogroups.com> wrote:
One particular situation had five teams working together, with a large overlap between four of those teams with regards to codebase and technical expertise. In that project, a team not managing to complete the functionality they were working on might have had large impact. We mostly managed to avoid that by being able to switch off functionality in the system fairly quickly if needed. This was a batch processing system with financial calculations. Different instruments could be enabled separately.
The teams I'm currently working with sometimes work together, and sometimes separately. We change that depending on business needs. These teams are in full 'continuous delivery' mode, and all new functionality is behind feature toggles by default. Sometimes having one team not completing a story might mean that we can't switch a feature on for customer to use. We do also get situations where we have dependencies between stories, especially if two teams are working on closely related features. They then talk to each other...
The whole idea is to use our technical tools (version control...) to deal with integration issues between teams. Adding feature toggles (and other CD tools) to that mix improves on the possibilities. In my experience, adding process layers to deal with this will mainly just slow you down. But it might be necessary until you get the technical base in order.


#yiv3865930745 #yiv3865930745 -- #yiv3865930745ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv3865930745 #yiv3865930745ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv3865930745 #yiv3865930745ygrp-mkp #yiv3865930745hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv3865930745 #yiv3865930745ygrp-mkp #yiv3865930745ads {margin-bottom:10px;}#yiv3865930745 #yiv3865930745ygrp-mkp .yiv3865930745ad {padding:0 0;}#yiv3865930745 #yiv3865930745ygrp-mkp .yiv3865930745ad p {margin:0;}#yiv3865930745 #yiv3865930745ygrp-mkp .yiv3865930745ad a {color:#0000ff;text-decoration:none;}#yiv3865930745 #yiv3865930745ygrp-sponsor #yiv3865930745ygrp-lc {font-family:Arial;}#yiv3865930745 #yiv3865930745ygrp-sponsor #yiv3865930745ygrp-lc #yiv3865930745hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv3865930745 #yiv3865930745ygrp-sponsor #yiv3865930745ygrp-lc .yiv3865930745ad {margin-bottom:10px;padding:0 0;}#yiv3865930745 #yiv3865930745actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv3865930745 #yiv3865930745activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv3865930745 #yiv3865930745activity span {font-weight:700;}#yiv3865930745 #yiv3865930745activity span:first-child {text-transform:uppercase;}#yiv3865930745 #yiv3865930745activity span a {color:#5085b6;text-decoration:none;}#yiv3865930745 #yiv3865930745activity span span {color:#ff7900;}#yiv3865930745 #yiv3865930745activity span .yiv3865930745underline {text-decoration:underline;}#yiv3865930745 .yiv3865930745attach {clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}#yiv3865930745 .yiv3865930745attach div a {text-decoration:none;}#yiv3865930745 .yiv3865930745attach img {border:none;padding-right:5px;}#yiv3865930745 .yiv3865930745attach label {display:block;margin-bottom:5px;}#yiv3865930745 .yiv3865930745attach label a {text-decoration:none;}#yiv3865930745 blockquote {margin:0 0 0 4px;}#yiv3865930745 .yiv3865930745bold {font-family:Arial;font-size:13px;font-weight:700;}#yiv3865930745 .yiv3865930745bold a {text-decoration:none;}#yiv3865930745 dd.yiv3865930745last p a {font-family:Verdana;font-weight:700;}#yiv3865930745 dd.yiv3865930745last p span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv3865930745 dd.yiv3865930745last p span.yiv3865930745yshortcuts {margin-right:0;}#yiv3865930745 div.yiv3865930745attach-table div div a {text-decoration:none;}#yiv3865930745 div.yiv3865930745attach-table {width:400px;}#yiv3865930745 div.yiv3865930745file-title a, #yiv3865930745 div.yiv3865930745file-title a:active, #yiv3865930745 div.yiv3865930745file-title a:hover, #yiv3865930745 div.yiv3865930745file-title a:visited {text-decoration:none;}#yiv3865930745 div.yiv3865930745photo-title a, #yiv3865930745 div.yiv3865930745photo-title a:active, #yiv3865930745 div.yiv3865930745photo-title a:hover, #yiv3865930745 div.yiv3865930745photo-title a:visited {text-decoration:none;}#yiv3865930745 div#yiv3865930745ygrp-mlmsg #yiv3865930745ygrp-msg p a span.yiv3865930745yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;}#yiv3865930745 .yiv3865930745green {color:#628c2a;}#yiv3865930745 .yiv3865930745MsoNormal {margin:0 0 0 0;}#yiv3865930745 o {font-size:0;}#yiv3865930745 #yiv3865930745photos div {float:left;width:72px;}#yiv3865930745 #yiv3865930745photos div div {border:1px solid #666666;height:62px;overflow:hidden;width:62px;}#yiv3865930745 #yiv3865930745photos div label {color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv3865930745 #yiv3865930745reco-category {font-size:77%;}#yiv3865930745 #yiv3865930745reco-desc {font-size:77%;}#yiv3865930745 .yiv3865930745replbq {margin:4px;}#yiv3865930745 #yiv3865930745ygrp-actbar div a:first-child {margin-right:2px;padding-right:5px;}#yiv3865930745 #yiv3865930745ygrp-mlmsg {font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv3865930745 #yiv3865930745ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv3865930745 #yiv3865930745ygrp-mlmsg select, #yiv3865930745 input, #yiv3865930745 textarea {font:99% Arial, Helvetica, clean, sans-serif;}#yiv3865930745 #yiv3865930745ygrp-mlmsg pre, #yiv3865930745 code {font:115% monospace;}#yiv3865930745 #yiv3865930745ygrp-mlmsg * {line-height:1.22em;}#yiv3865930745 #yiv3865930745ygrp-mlmsg #yiv3865930745logo {padding-bottom:10px;}#yiv3865930745 #yiv3865930745ygrp-msg p a {font-family:Verdana;}#yiv3865930745 #yiv3865930745ygrp-msg p#yiv3865930745attach-count span {color:#1E66AE;font-weight:700;}#yiv3865930745 #yiv3865930745ygrp-reco #yiv3865930745reco-head {color:#ff7900;font-weight:700;}#yiv3865930745 #yiv3865930745ygrp-reco {margin-bottom:20px;padding:0px;}#yiv3865930745 #yiv3865930745ygrp-sponsor #yiv3865930745ov li a {font-size:130%;text-decoration:none;}#yiv3865930745 #yiv3865930745ygrp-sponsor #yiv3865930745ov li {font-size:77%;list-style-type:square;padding:6px 0;}#yiv3865930745 #yiv3865930745ygrp-sponsor #yiv3865930745ov ul {margin:0;padding:0 0 0 8px;}#yiv3865930745 #yiv3865930745ygrp-text {font-family:Georgia;}#yiv3865930745 #yiv3865930745ygrp-text p {margin:0 0 1em 0;}#yiv3865930745 #yiv3865930745ygrp-text tt {font-size:120%;}#yiv3865930745 #yiv3865930745ygrp-vital ul li:last-child {border-right:none !important;}#yiv3865930745
Tim Wright tim@tfwright.co.nz [SCRUMDEVELOPMENT]
2015-02-14 04:23:04 UTC
Permalink
Hi Jean,


I've just spent 18 months in an environment like you describe. Basically:


* We were developing a payments switch
* Had 4 scrum teams in New Zealand and lots more in Finland (although the
Finnish and NZ development was done in different branches of the code - but
we did get them to do work on the NZ branch on the odd occasion).
* 2 teams were working in the "online transaction switching" part of the
code for different projects, 1 in "merchant on-boarding" and one in "batch
file production". Shortly before I left, one of the online transaction
teams split into 2 feature teams for the same project. (the other 2 teams I
class as "component teams").
* We had about 50 members of the development teams (dev, test, ba) on the
switch side in New Zealand.
* In addition, some of the NZ teams had members in Australia
* We also had gateway teams in Uruguay, Scotland, and India delivering
additional components for the gateway
* And we had terminal (embedded software for payment terminals) in New
Zealand and Manilla.
* We had a low level of architectural and design governance - most teams
were self organising.


So, yes. Messy and hard.


Key problems we found were (this goes for all of development, testing, and
analysis):


* Helps to have experts from each team talking about the interfaces
regularly (for those teams that are sending messages to each other).
* For the project teams, it helps to have as much cross-pollination of
design ideas as possible. So key members of each team going to each other's
planning sessions and backlog refinement sessions.
* For the project teams, it helps to have project representatives in each
other's backlog refinement sessions to ensure that a feature built for one
project (or country in our case) will work for the other country.
* It helps to be on top of automated build failures or else everyone starts
ignoring them.
* It helps to track dependancies of stories that have been split and sent
across lots of teams. Otherwise one team can't test properly because
another team hasn't finished a story.


And...if you have different release schedules for different installations,
you have to be really careful and you end up doing lots of cherry picking.


I'm not sure if that's the sort of stuff you want. Am able to take
discussion offline so we don't spam the group if you prefer.


Tim
All –
I’m looking for example cases of multiple teams in the same code base and
sharing a product backlog releasing every sprint and functioning in a
fairly independent manner. Specifically, that their sprint commitments are
Team-specific, and it is possible for one Team to fail their sprint while
the other succeeds. I’m also interested in hearing where the minimal
dependencies are.
Thanks in advance for anything you can provide.
--- Jean
*[image: gate.site.jpg]*
*Jean Richardson*
Azure Gate Consulting
*~ **Repatterning the Human Experience of Work*
*AzureGate.net*
(503) 788-8998
--
Tim
021 251 5593
http://www.linkedin.com/in/drtimwright
Michael James mj4scrum@gmail.com [SCRUMDEVELOPMENT]
2015-02-17 18:31:00 UTC
Permalink
Tim, I love reading these examples, so I hope you'll keep posting here.

—mj
(Michael)
Post by Wouter Lagerweij ***@lagerweij.com [SCRUMDEVELOPMENT]
Hi Jean,
* We were developing a payments switch
* Had 4 scrum teams in New Zealand and lots more in Finland (although the Finnish and NZ development was done in different branches of the code - but we did get them to do work on the NZ branch on the odd occasion).
* 2 teams were working in the "online transaction switching" part of the code for different projects, 1 in "merchant on-boarding" and one in "batch file production". Shortly before I left, one of the online transaction teams split into 2 feature teams for the same project. (the other 2 teams I class as "component teams").
* We had about 50 members of the development teams (dev, test, ba) on the switch side in New Zealand.
* In addition, some of the NZ teams had members in Australia
* We also had gateway teams in Uruguay, Scotland, and India delivering additional components for the gateway
* And we had terminal (embedded software for payment terminals) in New Zealand and Manilla.
* We had a low level of architectural and design governance - most teams were self organising.
So, yes. Messy and hard.
* Helps to have experts from each team talking about the interfaces regularly (for those teams that are sending messages to each other).
* For the project teams, it helps to have as much cross-pollination of design ideas as possible. So key members of each team going to each other's planning sessions and backlog refinement sessions.
* For the project teams, it helps to have project representatives in each other's backlog refinement sessions to ensure that a feature built for one project (or country in our case) will work for the other country.
* It helps to be on top of automated build failures or else everyone starts ignoring them.
* It helps to track dependancies of stories that have been split and sent across lots of teams. Otherwise one team can't test properly because another team hasn't finished a story.
And...if you have different release schedules for different installations, you have to be really careful and you end up doing lots of cherry picking.
I'm not sure if that's the sort of stuff you want. Am able to take discussion offline so we don't spam the group if you prefer.
Tim
All –
I’m looking for example cases of multiple teams in the same code base and sharing a product backlog releasing every sprint and functioning in a fairly independent manner. Specifically, that their sprint commitments are Team-specific, and it is possible for one Team to fail their sprint while the other succeeds. I’m also interested in hearing where the minimal dependencies are.
Thanks in advance for anything you can provide.
--- Jean
<image001.jpg>
Jean Richardson
Azure Gate Consulting
~ Repatterning the Human Experience of Work
AzureGate.net <http://azuregate.net/>
(503) 788-8998
--
Tim
021 251 5593
http://www.linkedin.com/in/drtimwright <http://www.linkedin.com/in/drtimwright>
Loading...