While I’m finishing the wool-gathering for the last post in my Social History/Neuroscience of Agile series, here’s some reflections on the last couple of retrospectives and what’s going on around them
I’m still fairly new to the team. When I joined them, they were halfway through a sprint, and since then we’ve completed three sprints. They’re one of many teams, in a very complex business environment, and the code they’re producing operates as an integration point for the code from several other teams.
The major challenges they’re facing are, in no particular order:
- Environmental delay
- Cross-team coordination
- Starting too much work
Environmental delay
By this I mean the impact of discovering that an environment (say a QA Integration server) is not ready, and it turns out that the infrastructure team have a ten day lead time on building the server. Or an essential service needs to be configured to expect new connections and this has a four week lead time. Or opening a firewall takes four weeks to pass security review.
Why’s this a problem?
Two reasons: first the lead times are not widely publicized or, in some cases, even predictable. This would suggest that the teams involved probably could use a Kanban approach to track their lead time and cycle time and then be able to publicize a more reliable service level. For instance, “A request to open the firewall typically can be completed within 20 working days 80% of the time.” An escalation path could be offered as well “Urgent and important requests (i.e. to resolve production outage) can be processed in twelve hours, and must be followed by a risk mitigation review to minimize repetition of the issue”.”
The second problem is that often these lead times are longer than the sprint length. So if work in sprint n reveals a need for an environment change in sprint n+1, tough! You ain’t getting it until sprint n+x, buster! We all know that in the real world, no matter how good our release planning, all the time we discover things only during story grooming. So having environment teams work to reduce their lead time to be less than one sprint’s length would be a major step forward.
Cross-team coordination
Do I need to tell us why this is a problem? Oh, ok.
So in this case, it’s basically because more than one team is working on the same code base. Probably not the same code modules, but all the time we see that Team A does x, that break the code for Team B in module y. Team A’s code is essential, so Team B updates code y to take this into account. Team C’s code z promptly breaks. Guess what happens when they fix it.
Oops. Test Driven Development and Continuous Integration anyone?
Both of these problems require collaboration across boundaries, and that’s one area that is being worked on. Remember this: Scrum is designed to reveal organizational dysfunction. Taa-daa!
Starting too much work
When does value become real? When we put working features into (paying) customers hands. So we need working features. They’re working when they are finished, so finishing is a good thing. Duh, right?
So imagine a team that for one reason or another seems to be “falling behind” (read: their progress is not visible). Their workload increases as they have to keep dealing with the work on hand, and of course, someone up there keeps piling on more.
If the team’s capacity has been reached, and you add in more, it MUST mean that stuff ends up being late. Adding more cars into traffic slows the traffic. My calendar is full, if you give me something else to do, something I can’t magic up more time, so either it’s not going to happen for a while, or something else is going to be late. Fact.
Put another way, we want to stop starting and start finishing.
|
Worst sprint so far, they’d started sixteen stories, and finished one. They split (ow!) fifteen and didn’t recognize what this was concealing as they pretended that they’d finished all sixteen. Hmmm….
How did we fix it?
Well we haven’t – yet.
But here, much abbreviated, are the exercises we did for the last two Sprint Retrospectives. By the way, I always follow the format Set the Stage, Gather Data, Draw Conclusions, Design an Experiment, Retro the Retro. I’m only going to talk here about the middle three exercises.
Sprint N
Gather Data: We had the burn down, that showed we’d done only 35% of what we’d set out to achieve. So then we did a real quick Start Doing, Stop Doing, Keep doing exercise where the team brain-dump onto stickies and put them up on the board under these three headings. (Five mins.)
Then we had the team swarm on the board and group the stickies into related themes, and finally dot vote on the as things they were interested in.
Draw Conclusions: Now I had the team undertake three exercises. First, they had to sit in silence, and write on stickies any ideas that they had about the number one topic. I enforced the silence with librarian-like shushing. It was kinda fun! Next I had them pair up, and the rule was you couldn’t pair with someone with the same role as you. Then in pairs, they could compare stickies, discuss them, come up with something else if they wished.
Lastly, I had each pair pitch their conclusions to the rest of the team for two minutes. At the end of the two minutes, they were invited to comment on what it had been like to do this alone, and what it had been like to do this in a pair.
By the time each pair had gone, the place was a frenzy of people demanding another go to pitch again, discussions where breaking out all over the place.
In effect, we stepped from being lone guns, through pairing, to working as a team in this one exercise.
To wrap it up, once again, up went the stickies on the board, and we swarmed and grouped them.
Finally, once again, we dot-voted, and we had a topic for consideration for the experiment. In this case it was Focus on Story Grooming (with a strong hint of Cross-Team Coordination).
We decided that the experiment was to focus on this in the Sprint Planning session, and in the next Story grooming session.
Follow-up
About six days into the sprint, the question was asked in the daily stand-up “Hey, are we tracking our experiment?” We all looked blank, and guilty, as once again the Sprint was off track.
On reflection (Failure Bow time!) I realized that of course we were tracking it. That’s what the Burn-down chart was doing. It was showing that we’d sucked at Story Grooming! We’d been adding tasks up the wazoo!
Sprint N+1
This time, to gather data, I displayed the burn-down. We’d done much better, but there’d been some gaming of the numbers still, and stories were all getting finished at the last minute.
So here’s the exercise we did.
Gather Data: I had them stand in two rows, pairs facing each other. The instructions were A interviews B “Tell me two things that you think we should pay attention to” and write them down. Then B interviews A with the same questions. When we’re all done, the person on the end of row A runs round to the other end and all the A’s move along one spot. Then we repeat the interviews. We do this until you meet your original partner again.
This actually took something, it was fascinating seeing the guys struggle to understand what I was asking them to do. They hated it to begin with!
Oh, and one of the guys was on a video link, so one of us was interviewing a laptop!
But by the time were were done, it had turned fun and noisy! They loved it.
They we went to the board, of course, and started to cluster the stickies.
Draw Conclusions: This was simply a brainstorming exercise. I quietly left to go to the restroom, and by the time I’d got back, they were working on this on the whiteboard themselves.
The Experiment: We had realized that we tended not to create a decent support structure for our experiments. So as we came up with the things we wanted to do, we simply recorded them in Story format in Rally (not an endorsement, good though Rally is, it’s just the tool we happen to have).
This ensures that the stories will be sized and included in the upcoming Sprints.
Next Sprint
At the start of the Sprint Planning, I’m going to have the guys use the “Write your team’s names” exercise. It’ll only take a couple of minutes, and may have them get what’s going on with taking on too much work and trying to start it all.
But what about…?
Did any of this progress towards solving the Environment Delay and Cross-Team Coordination issues? Not directly, but it’s looking to me like the team are getting very quickly more skillful at undertaking the kind of exercises and using the kind of thinking that has people collaborate to produce solutions.
I’ll blow more about this as we progress.