Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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
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!

share|improve this question
1  
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. –  JohnFx Nov 11 '11 at 15:00
1  
An organization doesn't just flip a switch and the next day they are Agile. It's like a battleship, you gotta start turning well before you see the iceberg getting close because it takes a lot of time to turn it around. You may find them in this state, agile-fall.blogspot.com/2010/03/what-is-agilefall.html With that being said, I have been there and concluded I would much rather work for a pure Waterfall shop than a Waterfall shop in transition. I have also NEVER seen it happen successfully either, but then I am limited by my own experiences. I would like to believe it is possible. –  maple_shaft Nov 11 '11 at 15:31
    
@JohnFx, excellent point: I might be subjected to Harwell's laws My attempt is not to lobby against/for, but only make a suggestions on understanding the essence of Scrum. –  Clark Gable Nov 11 '11 at 15:41
    
Um, timesheets are a very important requirement in many organisations. Scrum cannot remove legal/contractual requirements from your processes, obviously! That said, timesheets do not need to be focused on tracking progress within a sprint. –  Robin Green Jan 5 at 12:51

5 Answers 5

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
1  
+1 on mentioning the details of the contract influencing the need for time metrics. I love Agile, don't get me wrong but its Achilles Heel is that the customer has to buy into it for it to be done perfectly. In my experience most customers find this concept alien unless they themselves are a software shop. It seems most Agile shops are just trying to cleverly abstract the hard deadlines from the Agile process or trying to use both Time and Points at the same time. This is what leads to Agilefall more often than not. –  maple_shaft Nov 11 '11 at 15:55
    
If there is a need for two or more full-time people to do the job of product owner, either the main product owner is too busy doing other stuff in addition to their product owner responsibilities, or the team is too large and should be split up. A "scrum of scrums" can be used for coordination between teams. Or, you know, email, talking to people... –  Robin Green Jan 5 at 12:58

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.

share|improve this answer

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.

share|improve this answer
    
I agree to your view, but feel you missed out on a few things: 1. in the structure, development manager is 'outside' the developers+QAs (development team in Scrum) 2. tracking time against a project is counter-intuitive, because it does not tell how long it is to get to 'done' on a story-the crux of Scrum. –  Clark Gable Nov 11 '11 at 15:36
1  
@ClarkGable I disagree that it is counter intuitive. It may not be particularly helpful information, but in the end it is just a different metric that people on the top need to know. Many customers don't care about points, they need A, B and C and they need it in 6 months. They don't want to deal with the involvement that is required of them with Agile vendors. Sure they are stupid for thinking that but they carry the purse. People at the top need to look back retroactively and see actual metrics based on TIME not EFFORT to accurately quote such projects. –  maple_shaft Nov 11 '11 at 15:48
    
your definition is apt for a waterfall method. Scrum is intended to provide working software every few iterations, rather than a long wait. Within a few iterations the customers 'get' something, rather than at the end of a six month wait! The idea is to iteratively build a good working software using the feedback of customers. –  Clark Gable Nov 11 '11 at 15:55
    
@ClarkGable I completely agree with that. So do you think Scrum makes sense for this project? What I am trying to say is that perhaps the contract that was signed declares a hard delivery date, and your leadership is misguided for even considering Scrum. –  maple_shaft Nov 11 '11 at 15:59
    
@maple_shaft - et tu brute... –  Chad Nov 11 '11 at 19:50

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.