Stories from being an agile coach, Scrum developer and ScrumMaster. Companies: 2 startups acquired, one in Workforce, Warehouse & TransportaAon SoBware SoluAons 1 in online booking & payment for tourism a few mulA‐naAonals, including one in Search where I worked in RnD a couple in Network Systems SoluAons and I’m now an Agile Coach working mostly in e‐commerce, healthcare, and networking services Along the way, I’ve discovered some (Atle) 

1 

Here’s the first thing: THING1 problem: code coverage low, many bugs Manager Introduced TDD Not a lot changed sAll had code reviews had 15” low res monitors Convinced manager to purchase large, high‐res 28 inch monitor put in small empty room next to group to go in room, had to work with someone else at work staAon low resistance way to 

2 

create a pair room. 

had to find someone to join manager didn’t code. aWracted more people bought second monitor.  4 people make 6 pairs. got in to ping pong pairing,  switching pairs every couple of hours more people joined. eventually 6 monitors,  we found that the short term hit wasn’t double hours on a task, but about 1.3 

and the effect of no defects made up for that Ame,  as defect fixing was typically taking over half the Ame before 

swapped small and big rooms not everyone liked pair programming needed place to concentrate, ignore people 

how many pairs are 12 people? 

3 

‐‐‐‐‐‐‐‐‐‐‐ THING2 First started out as dev/SM soluAoneering in stand up take 45 minutes or more I decided to go last and would 

4 

note who speaks about what,  

someone answering 3 quesAons  someone else chimes in write down who spoke  and a couple words about the subject give the people a liWle Ame to talk about it  then, ask politely to stop,  conAnue around the circle 

on my turn  answer the 3 quesAons,  run through who I noted was speaking  ask if they would need to follow up 

helped me find implicit impediments my quesAons included what impediments I had resolved was working on, or was impeded by  

5 

nearer to end of sprint people ask,” how is the sprint going? are we going to make the demo?”  

beyond stand up talking too much hold quesAon unAl end of sprint.   just too much reflecAon.  

the shorter the review,  the longer the retrospecAve. I learned very early on to 

6 

design good retrospecAves. 

great venue for team members to gripe.  if nothing changes, the whole thing can shut down. 

mentor recommend “Agile RetrospecAves” weave acAviAes together, build up effect of the retrospecAve.  amplified by tying retrospecAves together another level of build‐up,  one retrospecAve to the next.  

suggest only put in a couple of hours for review good retrospecAves take 3 hours to prep. an hour and a half to run a couple more hours to debrief and put in to effect the following sprint. 

7 

‐‐‐‐‐‐‐‐‐‐‐ THING4 The Product Owner started quesAoning our esAmaAon methods although in every planning poker meeAng. 

spent Ame tending to the backlog fairly detailed backlog, most of it sized. velocity was stabilizing.  too much to fulfill promise to customer how could we be sure of our numbers? esAmated before we did any work, could be off 

looked at all the work on the backlog, including the work we had done, resize it if needed.  took about a day  did changed some of our esAmates.  yet same total So we learned that day that we can 

8 

resize stories and create the same size backlog.  

We took our work seriously.  too many stories to game it It just naturally happened.  esAmated done work,  help us to triangulate on some of the upcoming work we thought was similar.  

we had a great idea on what needed to be done.  wouldn’t fit in to the date promised.  signed on the contract between us and our customer.  Missing it would be a big deal.  customer might not pay on the contract.  

9 

THING5 was beginning of winter.  the customer told us that it needed to be out in the spring.  our company wanted buffer promised end of winter.  put it in the contract!   our company started to talk to the client  wouldn’t hit the date,  customer saw demos could see that we were responsive just a lot of work customer admiWed that it really wasn’t needed unAl the summer.  All‐in‐all, we got everyone to 

10 

admit to the real date.  

Unique about situaAon :everyone believed the data they were seeing.  someAmes when presented with all the evidence,  some people will conAnue on the same track. 

Everyone here was able to get real,  greatly improved the relaAonship.  We esAmated that we could get 80% of the work in by the needed date.  

customer started working closer with us,  providing frequent feedback on the direcAon.  We launched within the window predicted by our velocity and backlog size.  The customer eventually wound up acquiring  our company. 

11 

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ THING6 asked to embed as scrum master stand‐up seemed confused, unrelated (give examples) using a Acket tracking system 

asked around people working on many backlog items at once some, more than a dozen next stand up, asked if people would write it down  put on the board  even though in Acket system. 

enough sAckies to fill a wall. made visible, everyone could see  too much of it. the acAvity of gekng it all on the wall meant that  

12 

we could expose the work and limit it.  

group like work together,  talking together about similar work agreed to get items down to no more than 3 being worked upon then one then less than one 

13 

‐‐‐‐‐‐‐‐‐ THING7 giving up on esAmaAng when no idea when to expect anything find that people start demanding dates 

relaAvly sizing works, what about when lots of items, all unsized? That’s when I like to get out the buckets and  

14 

rough sort the esAmate. 

team esAmaAon game 

distribuAon paWern always same clumps in middle 

works when everyone knows the scope planning poker sAll important 

15 

‐‐‐‐‐‐‐‐‐‐‐‐‐‐ THING8 whole business unit going to scrum start in san jose, over 70 people  managers decide to create 3 large teams  along architectural boundaries integraAon issues one feature, people from each team works on long stand ups see same person in mulAple stand ups month‐long sprints aBer 2 sprints, I helped to 

16 

let the team decide 

wriWen different themes of what was being worked on (about 6) asked those that were working on a similar theme to gather around double‐check, are these the people you work with, regardless of team? could the team deploy any feature within the theme? 

now had 6 teams, with one person only on one team one stand up and someAmes, sos 

17 

_________________ THING9 team seeing inconsistent velocity tough to predict when things would finish had another backlog of defects, not allowed to size only points have value and should be esAmated 

story points related to effort, risk, complexity level of investment, threrefore we 

18 

we esAmate relaAve size for cost 

wouldn’t it be good to understand the cost of defects? understand their scope and expected behavior, like a story? 

now size the whole backlog velocity stabilizing can see what classes of things are being worked on can determine where to invest like fixing defects or beWer to prevent them? 

19 

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ THING10 most groups have a funcAonal reporAng hierarchy and a matrix structure  common issue: one person on many projects one place, refusal to use matrix led to problems user story break‐down showed funcAonal teams wouldn’t work needed to re‐organize teams some managers didn’t like, execuAve blocked stopped the agile transiAon and release planning I was asked to leave unAl they came up with a plan couldn’t afford a re‐org so, they had to convince everyone to 

20 

use the matrix 

could only work for/with direct manager and cohorts on team all arranged funcAonally and by architectural area such as front end, back end, appliance, engineer, quality assurance, user experience, etc 

then I was asked back conAnue on with release planning execuAve sAll there could work through problem w/o lekng people go except for the appliance, had all the roles accounted for and on teams for the appliance, had a team and also an ambassador to each of the other scrum teams 

21 

‐‐‐‐‐‐‐‐‐‐‐‐ in a few of these stories, the results improved because somewhere along the way the company did truly 

22 

let the customer in 

it was a couple of minor things lekng the customer through firewall and to source control 

inviAng through webex and other remote collaboraAon tools to aWend reviews starAng to see them at bigger reviews 

working at each other’s offices 

observing the lab as a bunch of people play with the funcAonality the team just built 

co‐creaAng the plan 

having that trust increases the chance of delivering customer value, which should increase profits 

people working together… 

23