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.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s