What are the common mistakes in 'tailored Scrum approaches'?

Question

I have seen this before. Management wants to be agile and be scrummified, but does not want to step out of the status quo. My latest observation is no different; here, the Scrum is 'tailored' to the organization; specifically into a weird many-people-process.

Here http://img684.imageshack.us/img684/6175/modifiedscrum.jpg
The diagram showing the different participants.

I am putting together a document listing why this will not work. Here are the obvious ones:
1. There are product owner agents (an obvious WTF), who report to the product owner: causing dilution of decision making capability
2. There is a role that looks similar to a manager in the traditional approach - development manager: an obvious attempt at command-and-control model
3. The ScrumMaster's role includes collecting timesheets, which are used to track progress instead of burndown charts: detrimental to agile's efforts to build teams with motivated individuals

Leaving the question "how would you convince the management?", my question is more at, "what else do you see as failures in this/similar 'tailored Scrum approaches'?

EDIT: The diagram might use a few more details
1. The development manager is not part of the development team, with not very clearly defined responsibilities, except: developer performance assessemnt, recruitment, etc.,
2. There are more than two teams (with ScrumMaster+development manager+dev team) with the same product owner for all teams!

Answer 1

Moved from the comments...

Have you considered giving it a go and seeing how it works before lobbying against it? As long as they are open to adapting the structure over time I don't see any fatal flaws in this plan other than that it doesn't follow the Agile dogma to the letter.

Another thing to consider is that you want to incorporate enough of the business leader's ideas into the approach so they feel ownership in the Agile adoption. If they do, they will be vested in making sure it succeeds instead of disparaging it (because their approach would have been better) if things get sideways. And it will inevitably go sideways, especially at first. People are usually resistant to change and are often clumsy for a while when they are forced to adopt a new way of doing things.

Make management a partner in the process not an adversary.

Answer 2

The Development Manager and to some extent the ScrumMaster are variations of the traditional role of the tech lead. I don't see the Development Manager necessarily having any more or less command and control as you put it than a typical tech lead.

The Scrum Master is a little bit more special than that though. The Development Manager shouldn't also be the Scrum Master but there is no reason why the Scrum Master couldn't just be the PM anyway since they have the most interest in timesheets. Tracking time on a project schedule is not disjoint with the concept of User Stories, Points and Burndown Charts.

You do kind of have a point about the Product Owner Agent role. I don't see a person in that role having any clear unique responsibility other than being an additional link in the chain of command.

The Product Owner is ridiculously important though. He owns the product. I am not going to explain the importance of it but if you have ever worked on a project where there was no clear product owner because the middle managers were too chicken-$$$$ to take any ownership of the PRODUCT direction and decisions regarding the PRODUCT then you will see how it completely sabotages all projects before they even start.

Answer 3

You need them to differentiate how the company is structured and how the people in a scrum development process are structured. This is fine for an org chart.

For a very large ERP project, you could have nearly separate section that have their own product owners. They may report to someone, but from the Scrum perspective, there needs to be one product owner working with the group assigned to that part of the project.

The development manager is more the person who may do the evaluations, organizing days off schedules and other manager duties that have nothing to do with development.

Just show them how you separate the two. No reason small scrum groups can't exist in a large corporation. You have to know where people fit in both worlds.

Answer 4

It's actually not that far off. It depends on what certain people's roles are.

• There can be more than one person in a team that fills the role of Product Owner (as in the decision-making entity that is responsible for requirements generation, prioritization and acceptance). On large projects one person simply cannot do it all. What is important is that there is a single communications path to and from the Product Owner, to which questions are directed and from which requirements directives come, however many people are behind them (or even in front of them) assisting with the process. In short, there should always be one guy you can call with a question, no matter who he talks to to get the answer or who he communicates the answer through. So, if the Agent is simply someone from the Product Ownership "team" who participates as a chicken in the IPMs and daily standups, and reports back to the PO, that's fine; the PO cannot be everywhere. If this is a person capable of making decisions independently of other agents or the Product Owner, or who is designed to restrict access to the PO, THAT can be a problem.

• Development Manager sounds like either "Project Manager" or "Team Lead" to me. It could also be "Architect", which is the guy responsible for maintaining a good design structure and deciding the enterprise-level patterns to follow in developing certain areas. There's usually only one Architect, like there's only one Product Owner, so if this guy is a "Project Manager" or "Architect" role it should be a cross-team job, not one per.

• I don't see BAs in this chart. At my last Agile job, BAs received and reviewed the raw stories, determined dependencies that would create schedule conflicts and a "critical path", and usually also did some QA. They were also the ones on the phone the most with the PO. That freed the coding teams to do what they do best - heads-down coding.

The idea of timesheets as opposed to a burndown to track progress does seem odd. It sounds like the contract was negotiated for time and materials, and they want TIME, not an estimate of time based on points complexity. That's fine, to a point, but the point of Agile is that your clients would rather pay per-point instead of per-hour; a point is a calibratable unit of work, and when its done you have a real product that should be worth that amount as a fraction of the whole project.

Answer 5

I don't think that is is obvious that things would fail.

There are product owner agents (an obvious WTF), who report to the product owner: causing dilution of decision making capability

Assuming that someone needs to represent customer (in case where real customer is absent) this is not a goof up. However, the criteria of success is the visualization of real customer needs.

There is a role that looks similar to a manager in the traditional approach - development manager: an obvious attempt at command-and-control model

This happens usually where a traditional tech guy is a not senior enough (or known to be good enough to do project manager but knows most tech stuff better than most. (unless it is other way). Real difference comes on the basis as to what they actually do.

The ScrumMaster's role includes collecting timesheets, which are used to track progress instead of burndown charts: detrimental to agile's efforts to build teams with motivated individuals

This is sounds surprising though. However, i believe most traditional software companies cannot get rid of timesheet. Donno why. But there is no alternative to tracking the project from the point of view of

There are few criteria that will make or break things.

1. The real challenges in Agile is not process and accuracy with which one adheres to it. The real challenge is when you begin pure ritual rather than helping to simplify processes for developers so that they can concentrate on what they do good - programming!

2. Getting to know the real need and iteratively going better at it. What you need is to get clarity (and transparency) across all people and personal commitment from all to get to achieve the right targets.

Of course, there are 12 core principles that you should know. My point is stick to those core concept - you can make agile work under any organization structure.

If this basic things fail, everything will fail - else all else is good.