A square peg in a round holeI got into a mini debate on Twitter last week and it got me thinking about my views on a few things Scrum. I’m not going to chew over the specifics of the to and fro as it’s very difficult to have a reasoned debate with only 140 characters per point but I thought I’d explore some of the issues arising from it.

The thrust of the argument was “We don’t need you, managers. We’re developers using scrum and can do anything you can do”. The answer to that is, of course, “Yes, you can”.

According to the Scrum Guides you can get from http://www.scrum.org/scrumguides/ your Product Owner and your Scrum Master can both be members of the team (but never the same person). So, leave “the Team” alone and they’ll produce top-drawer results, end of discussion, right? ‘Fraid not.

It all goes back to what Scrum is all about – hyperproductivity/maximising ROI (choose your phrase). I’ve got another article under my hat about how Scrum actually creates that hyperproductivity but, from the perspective of any business, for the sake of efficiency, it’s imperative that the right people are doing the right jobs – jobs that they’re fully equipped for. If you’ve got someone in a role that they don’t possess the right skills/experience for (e.g. a developer filling the BA role as a sideline) then, by definition, you’re spending money training them on the job and they’re making their novice mistakes on your watch. That’s fine, if you’re making a conscious decision to do this*, but don’t be fooled that a productive, self-organising team can rule the world and turn their hand to anything. Developers are good at cutting code, make sure they have the head-space to do so.

Skill matching is not the only thing to consider, there are also some very basic operations management principles at work in a Scrum team too. One of the many ways in which Scrum achieves hyperproductivity is by reducing the time-costs associated with task switching. Developers who are also BAs, the voice of the customer, support guys (& gals) etc on top of their Developer role will waste buckets of time jumping between one thing and another. Besides the wasted time, the developer won’t be able to get so much “done”, thereby reducing his/her sense of achievement/motivation and, it’s a fact, multi-tasking makes you stressed.

There’s another facet to this debate, too. Even though “The Rules” say you can have a Product Owner as part of the Scrum team, I’d strongly advise against it. Why? Imagine the conflict of interest a Product Owner would experience if they were put under pressure (external/commercial) to change the contents of the Sprint Backlog half way through a sprint. Imagine how uncomfortable the Scrum Master would be if the team-based Product Owner started making “I know we shouldn’t really do this…but” sort of noises. The Product Owner in this scenario is probably the business owner too and, in terms of the food chain, almost certainly sits above him. This is exactly the sort of situation you shouldn’t design in to your team if you can possibly avoid it.

A relevant, recent example in my own experience could have played out like this but, for exactly the reasons outlined above, we went with a far-too-techie Product Owner sitting outside the team, picking off Product Backlog items at his leisure, outside the Sprint Capacity timebox. It works pretty well.

The bottom line is, whilst you can stick a square peg in a round hole, it requires some effort and you’ll find there are gaps around the edges.

* I believe strongly that investing in your team in respect of their training is imperative, but only when you can afford it.