Is it okay to have people with multiple roles in a Scrum team?

Question

I'm evaluating some Agile-style methodologies for possible introduction to my team. With Scrum, is it allowable to have the same person perform multiple roles? We have a small team of four developers and a web designer; we don't really have a lead (I fulfill this role), QA testers or business analysts, and all of our development tasks come from the CIO. Automated testing is seen as a total waste of time, and everything focuses on speed and not quality.

What will happen is the CIO will come up with a development task (whether a feature or a bug) and give it to a developer (not to the whole team, to an individual, often in private or out of the blue) who is then expected to get it completed. The CIO doesn't gather requirements beyond the initial idea (and this has bitten us before as we'll implement something only to find out that none of the end users can use the feature, because they weren't consulted or even informed about it before we developed it, and in a panic we'll be told to revert the change) but requires say in/approval of everything that we do.

First things first, is a Scrum style something to consider to introduce some standards and practices? From reading, Scrum seems to rely on a bit more trust and communication and focuses more on project management than on development, which is something we are completely devoid of as we don't have any semblance of project management at present.

Second, if it can work is it unreasonable for someone, let's say myself, to act as both ScrumMaster and a developer? Or for a developer to also be the Product Owner (although chances are this will be the CIO, who isn't a developer)? I realize the Scrum Master and the Product Owner should be different people but at the same time I don't think we have anyone who has the qualities of a Product Owner (chances are it would turn into a "I need all these stories, I don't care how but get it done" type of deal and/or any freeze would be unfrozen on a whim).

It seems to me that I might need to pick and choose pieces of Scrum/XP/Lean to compensate for how things are done currently, as it's highly unlikely that the mentality can be changed; for instance Pair Programming would never fly (seen as a waste, you get half the tasks done if you need two people for everything), TDD would be a hard sell, but short cycles would be welcomed.

Answer 1

Scrum, Kanban or any other Agile methodology is primarily a methodology focused on software development projects. In other words, it is a project management practice by its very nature.

As much as you desperately want you and your team to be doing project work, you will find that Agile will just simply not work in your organization because of the fact that you really are not doing "project" work or devoting yourselves as a team to a "project commitment".

You may organize a mini project around a complex feature, but in reality you have no connection to business analysts or the end users so how can you verify that you are delivering on User Stories when you have no way of really knowing what it is the user wants?

Your only stakeholder is your boss, and he basically ensures that your team doesn't exist to serve the other stakeholders of the project, you exist as a team to serve him and his needs regardless how this affects the other stakeholders.

On top of all of that, he is giving individual tasks to individuals and probably reprioritizing things immediately as he decides that they should go. You can't function in an Agile project methodology if individual project resources are going to reprioritized at a moments notice, or if the sprint will be put on hold.

It is not supposed to work like that

A sprint is a commitment by the entire team to deliver a subset of user stories by a specified date. Once started, a sprint should be gone through to completion before any reprioritization or changes are to occur. How is a project supposed to be managed when run in such a chaotic ad-hoc environment?

You don't work in an environment that is conducive to Agile project management methodologies. You don't even work in an environment conducive to Waterfall methodologies. You work in a monarchy and you are merely the kings pawns doing his bidding and putting out fires.

This is not the makings of a software development project team.

So in a very obscure way I am answering your question in saying that in your situation that it really doesn't matter if individuals are playing multiple roles. You have much bigger problems on your hands. You are asking how to get water stains out of carpet on a house without a roof.

Answer 2

As I noted here, if either the Scrum Master or the Product Owner have actionable tasks, they are also members of the Team.

That said, you are going to have serious problems going Agile unless you have real buy-in from both your CIO and your customers. Is your CIO willing to abide by the fact he cannot add a work item mid-sprint, but will have to wait until the next? Is he willing to prioritize the items to be developed? From what you've written, it sounds like he owns what you do, and thus should be the Product Owner. If he is unwilling, you're not going to succeed any more than you currently do.

Answer 3

Scrum could be a good solution for your problem of the CIO assigning work to a developer ad hoc, but only if the CIO will buy in to the process. I suspect that your CIO is not going to like being taken out direct assignment. But if you can get the CIO to buy in to the idea of him writing user stories and then prioritizing them, he could find it a very effective way to manage. But it will start with you convincing your CIO to stick to the process.

Answer 4

Scrum is something to consider, sure. However, there is something to be said for getting all those involved on the same page and accepting a few changes to the structure along with getting at least a few sprints to work out various initial issues in using this methodology.

The Product Owner should be outside of the development team as there would otherwise be a bad conflict of interest presented here. The Scrum Master may be a developer though as there isn't as bad of a conflict in this case.