Multidisciplinary Teams vs Teams of Multidisciplinaries

Two working days from the end of Sprint Three, here’s how our “Task Time” burn-down looks:

Screen Shot 2016-05-12 at 17.01.27

Sprint 3 Task Time burn-down

It’s remarkably similar to Sprint Two’s, with the red line never really catching up to the grey guideline, and with red and green crossing far too far to the right of the mid-point of the sprint for my liking:

Screen Shot 2016-05-12 at 17.02.51

Sprint 2 Task Time burn-down

This is over-commitment, pure and simple. There’s pretty good symmetry between the red and green lines, so assuming that nobody’s “gaming” the stats this would imply that our estimates for how long each Task will take are reasonable. Where we’re falling down is planning how much of our time we’re going to have available to work on Sprint Tasks.

Reflecting on why we’re falling into this trap two Sprints in a row, and thinking back to Sprint Planning, I was struck by a thought. We call ourselves a multidisciplinary team because we have all the skills needed to deliver our software:

  • Tech Lead
  • Front-end developer (PHP)
  • Back-end developer (Java)
  • DevOps
  • User Researcher
  • Designer
  • Test Lead
  • Tester
  • Product Owner
  • Scrum Master

The problem with this, is that we have one person who can do each role. If that person gets stuck, there are very few options to provide them with a bit of extra support. The developers can go to the Tech Lead, who understands both the back and front end, but he’s a busy guy already. Likewise, if my tester gets stuck on his cucumber/selenium/Jenkins he can go to the Test Lead, who also has a full workload.

For all practical purposes, there’s absolutely no fungibility. For example, the back-end developer has massively improved the performance of API call “bobbins” by rewriting the entire thing. He’s kept it functionally identical, but has put his new work into “bobbins2” at the insistence of the Tech Lead who apparently has a Thing™ for backwards compatibility. This means that to benefit from all this good work, we need to update the front end every place it calls “bobbins” to add a “2”. Simple, right?

Except that the back-end developer doesn’t do PHP. He hasn’t got the code. Or an IDE. Or know how to release it back. So now we have to add a new Task to the Sprint so that the Front End developer can add some 2s.

Now imagine if the back-end developer had some rudimentary PHP knowledge. It’s a fairly simple search-and-replace job, so it’s not like he needs to understand the finer workings of <insert heavily nuanced PHP subtlety of your choice here>.

I’m not suggesting that the only good team member is the one who can do everyone else’s work as well, just advocating T-shaped skills rather than I-shaped.


Marvo the Marvellous Multi-Tasker

Frustrating times.

One of the team, let’s call him “Marvo”, wasn’t too sure about how to break his work down for this sprint. He was planning to use a new-to-him tool to do something he’d not done much of before. With that much uncertainty I created a Spike for him, time-boxed at three days, to spend some time getting to grips with the tool and the work.

So far so normal.

My first mistake was that I didn’t book the review meeting at the end of day three. Nor did I stick a reminder in my own diary to check in on Marvo in case he forgot.

My second mistake came half way through day two, when Marvo indicated that, having talked things over with the consumers of his work, he changed his mind about which tool to use, and would now go back to using an old, familiar tool instead. My question, “how much time will you now save?” was answered with: “None.”

That loud noise you can probably here,  that’s the Agile Violation Alarm going off in my head. Unless it’s your own AVA going off in your own head. It probably should be. With a bit of follow-up questioning, it turns out that there was as much uncertainty in the scope of the work as there was in the use of a new tool, and doing the same work in a familiar tool was still a largely-unknown task.

In retrospect, the right thing to do at that point was probably to start a new time-boxed spike for that work in a familiar tool. What actually happened was that the vague and woolly “do the work in a new tool” Task remained as-is in Jira, and was joined in the “In Flight” column by all the other Tasks for Marvo for this Sprint.

The explanation was one I’ve heard before many times: “they’re all kind of interlinked.” That translates in my head to “Either I have no idea how to break the work down into distinct, measurable tasks,” or “I’m not willing to expose the work to you in distinct, measurable pieces because it leaves me no place to hide or dissemble on whether I’m making progress or not.” I’ve worked with people who meant it both ways, sometimes at the same time.

The only thing that I’ve found works is to keep coaching them to think about what they’re actually doing and guide them into slicing their tasks up differently. On this occasion it only took a couple of sprints, but I’ve known it take much, much longer.