Stories from being an agile coach, Scrum developer and ScrumMaster. Companies: 2 startups acquired, one in Workforce, Warehouse & TransportaAon

Transcription

1 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

2 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

3 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

4 THING2 First started out as dev/sm soluaoneering in stand up take 45 minutes or more I decided to go last and would 4

5 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

6 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

7 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

8 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

9 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

10 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

11 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

12 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

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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

21 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

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

23 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