My team, a biz funk team, has been doing Scrum for nearly two years. And we like it. I like it. But recently I’ve begun to wonder if I’m falling into a “see sticky, do sticky” rut. A sticky note prison of sorts.
Meaning, I’ll do what I need to do to get the task completed, even if it goes against my instincts about the best way to do a task. For example, instead of meeting with someone face to face to share feedback, I’ll send them an email. I’ll send out surveys even as my gut says the survey isn’t going to be helpful. I’ll spam potential meeting goers to close a task and risk alienating them for future events. See sticky, do sticky.
Part of the problem is that my initial tasking isn’t perfect, and then I don’t always go back and refactor my tasks when I think of a better / different approach. What seemed like a good idea in sprint planning doesn’t always seem like a good idea a week later when I am doing the work. But this is partly because I’m a little tired of forcing all my work onto a colored square of paper. Sometimes — and this is potentially blasphemous — it feels good to simply follow my instincts when trying to get something done.
My attempts to break out of this sticky prison has led me to miss a few stories, something I never ever did in the past. And, strangely, I feel good about the way the missed stories ended up, even though in one case it took me three sprints to close it out. I feel good about it because I did the story right, and I didn’t let my bad story writing / bad tasking stop me from doing the story right.
Could I simply task better / write better AC? Probably. The good news is — and I’m very excited about this — my team is moving from Scrum to Scrumban this week. We’re going to have a weekly grooming / tasking session, and then just-in-time tasking for any new stories. I’m interested to see if the removal of the artificial two-week timebox removes the perverse incentive to move stickies, even if the ultimate objective of the story is only being tangentially addressed. And perhaps the shorter grooming cycle and JIT tasking will help me write tasks that are better / more relevant.
We now have six business and functional teams that have adopted some agile / lean practices, and only one of them uses a sprint or release burndown. Why is this number so low? Should our agile coaches be pushing harder for biz funk burndowns?
Well, when you roll out agile / lean practices using the “take out menu” approach, which gives more power to the team to select what practices they see value in, you’ll find that not many of them chose the burndown to start. To put some numbers to this sentiment, of our six biz funk agile teams, here are the most commonly selected ceremonies / artifacts / roles:
- Daily (or 3x / wk) Standup (6)
- Product Backlog (6)
- User Stories (6)
- Digital Task Board (6)
- Demo (4)
- Clear Product Owner role (2)
- Retrospective (2)
- Sprint Planning (2)
- Burndown (1)
- Effective WIP limits (1)
- Release Planning (0)
- Story Mapping (0)
A few thoughts about why this might be:
- Not always having a clear Product Owner (allowing the PO role to be handled RACI matrix style)
- Comfort with the status quo of scrambling towards dates also has folks comfortable with not really knowing on / off track
- Continuous flow lean teams don’t need a sprint burndown
That said, our content dev teams, when writing 1,200 page books like this, can certainly use a “Book Burndown” to show if they are on / off track.
To me, burndowns are most useful to two people: 1. the Product Owner who wants to sleep better at night knowing her team is on track and 2. the sponsor who wants to sleep better at night knowing her investment is on track.
My hypothesis is that the low-burndown demand is a maturity thing: going from no burndown to having POs and teams and sponsors demand a burndown takes time. The impact of a standup is immediate and mostly obvious (although I’d argue one big benefit of a standup — that it is easier for new team members to get up to speed in a team that has a standup — is not so obvious). A burndown’s value is less obvious to the team and might even feel punitive (we’re working as fast we can, so why do we need a burndown!). But if a key sponsor is consistently asking if the, say, content for the book is on track, the burndown will be very helpful. So I just need to find the right sponsor and coach them to ask the right questions to the the biz funk content team that is mature enough to get a burndown working.
No data to back this up (yet), but I’m starting to believe that there are two leading indicators that a team is mature: 1. consistent use of video for ceremonies with remote participants, and 2. use of a release burndown (or cycle time).
Join us on July 16th and August 13th!