Agile Scrum over Prince 2

[nomadd]

Utter nonsense. I've worked in agile teams using scrum, and proper project management is an essential component, as with any project. You clearly have absolutely no understanding of what you're talking about - either that, or you only have knowledge of badly-run projects where buzzwords have been favoured over professionalism.

I think you mis-read his statement: he was being tongue-in-cheek. Chill.

As I replied myself, the "proper project management" is essential. The problem is, most of the "agile" projects I've worked on in the last 10 years have used that "agility" as an excuse to do zero project management, architecture, planning, design, documentation, integration testing, etc.

Like you say, an Agile approach can be extremely productive: if only you implement it professionally. In my experience, unfortunately, most Agile practitioners are nothing more than hackers. The current outfit I work for are a prime example of that; they think that as long as you have the right "buzz words" and use "exclusively open-source tools" - and endlessly deride anything that isn't open-source - then your project is bound to be a winner.

[northernrampage]

They are not interchangeable. Agile/SCRUM works providing someone somewhere has worked out what you're trying to deliver - and that needs Prince or something like it.

WHS.

You combine. I've got PRINCE2, I always do the set-up processes (documentation, controlled stages etc), but tailor them to each project I'm on. e.g you don't need reams of paperwork, change mgt documentation for something diddy, but setting-up roles, communication, defined stages is always needed to avoid confusion at a later date.

I've often been the product owner who works with an Agile tech team to define what goes into the next sprint. So I work with the scrum master as well, sometimes take their role if they're on holiday/not available.

I find Agile and prince (or another more more "formal" methodology) work well together. One is about the overall structure, the agile is about the "doing", the building of the product.

And the jobsites are asking for Agile on the whole. If you don't know anything about it just speak to someone that really gets it and ask them to explain properly.

However, most jobs aren't looking for detailed knowledge, it's usually clear in the adverts if you are to be the scrum master. At interviews I've been asked what are the pros/cons of Agile, and what's good about PRINC2. It's one of the few I can usually answer, one day I'll get a job

And I like teams that use Agile, everyone gets involved.

[Ardesco]

My experience of Agile is that you need a tulip hot development team and a tulip hot testing team to make sure it works. Far too many people in business see Agile as an excuse for not putting proper processes in place, or ignoring the proper process when deadlines are being squeezed. If you have a tulip hot team who can do the work properly, still deliver and push back at the people trying to break all the rules and using agile as an excuse to do it when everything else is going to hell you are onto a winner.

Unfortunately you don't often come across a place that has a dev and test team that can do this.

Just my two penneth

[thunderlizard]

Scrum has self-managing teams & nothing for a PM to do.
PrInCE2 requires the PM to write loads of reports.
So be a Scrum PM and you need never lift a finger again!

Utter nonsense. I've worked in agile teams using scrum, and proper project management is an essential component, as with any project. You clearly have absolutely no understanding of what you're talking about.

I think you mis-read his statement: he was being tongue-in-cheek. Chill.

Yes I was, & sorry to joke about your hobby horse, but interestingly your wikipedia link backs up my point:

Scrum is a “process skeleton,” which contains sets of practices and predefined roles. The main roles in Scrum are:

1. the “Scrum Master”, who maintains the processes (typically in lieu of a project manager)

-because Scruminology really does its best to try to write the Project Manager role officially out of the story. Project management yes: Project Manager no.

[Zippy]

I agree with some of the posters - it is easy to combine Scrum and PRINCE2. Ignore the salesmen - we are not talking about a religious divide.
The scrum master makes sure that a particular set of functionalities gets delivered within an agreed time. And it has to work. That's it.
The PM (PRINCE2 or otherwise) makes sure that the overall product gets delivered within the time agreed. That's it.
The customer has to participate in the requirements gathering, and the product development. An 'embedded' customer works best.

Now, if you are working in teams that think that Scrum/Agile is some kind of free-for-all you are not doing it right. It is actually very disciplined and challenging for all concerned (and measured very closely). The developers have to get their heads round the idea that stuff has to be delivered within a certain timeframe and it is their responsibility to make sure that happens. The developers determine the timeframe for each sub-set of functionality btw. This may mean (shock, horror) talking directly to the client.
The PM can get on with jobs like making sure that resources are available. They are happy.

I've been a scrum master, so if anyone wants to know more please PM me.

Sorry that some of you have had such a negative experience. It shouldn't be that way.

Z.

[NickFitz]

My experience of Agile is that you need a tulip hot development team and a tulip hot testing team to make sure it works.

I would be the first to admit that I've been lucky that way

Yes I was, & sorry to joke about your hobby horse, but interestingly your wikipedia link backs up my point:

Scrum is a “process skeleton,” which contains sets of practices and predefined roles. The main roles in Scrum are:

1. the “Scrum Master”, who maintains the processes (typically in lieu of a project manager)

-because Scruminology really does its best to try to write the Project Manager role officially out of the story. Project management yes: Project Manager no.

Not really my hobby horse, more one that certain former clients of mine rode to good effect.

However, your quote from the Wikipedia entry I linked to can be interpreted in several ways:

1. the “Scrum Master”, who maintains the processes (typically in lieu of a project manager)

To say that the Scrum Master is "in lieu" of a Project Manager strikes me as a poor use of language; if I could be bothered to trawl through Wikipedia's edit history I would castigate the person responsible. Frankly, I'm not sure what the random person responsible for that content was thinking of when they wrote it, but I suspect they were using a high-faluting phrase in the hope of impressing their online "friends".

The Scrum Master role may be, and I personally believe should (usually) be, fulfilled by the same person as the Project Manager role. However, the two roles are distinct.

Scrum is not a formally delineated project management process; it is a generalised framework within which a development process suited for a given set of circumstances (such as organisational requirements, management structure, team structure) can be formulated. Note that a development process is not the same thing as a project management process or strategy. In the successful scrum teams within which I have worked, the Project Manager also assumed the role of Scrum Master.

This is not a requirement of scrum, but the fact that the roles of Scrum Master (which exists within the development effort) and Project Manager (which exists within the management effort) are not required to be fulfilled by the same person does not mean that they cannot be fulfilled by the same person, nor that (if they are fulfilled by different people) one supplants the other. Either way, the Project Manager will have the responsibility of managing the project (as in, all that dull stuff that generates documents that nobody really wants to have to read), and the Scrum Master will have the responsibility of managing the scrum (as in, all that cool stuff where things get made that people like).

It also behoves the person who finds themselves fulfilling both roles to remember which hat they are wearing at any given time - there's no point showing a Gantt chart to a scrum team unless you want to give them a laugh, and there's no point showing a burndown chart to a Technical Director unless you're explaining to them that Gantt charts may be all well and good for building skyscrapers and motorways, but have absolutely zero relevance to the business of constructing software

[Zippy]

Oh dear. I have to disagree with NickFitz here
I would argue that there is every point in showing a burndown chart to 't senior management. We've said we are going to do this (you are paranoid), here are the numbers (we know you don't get it), we got there in the end (in yer face).
It takes a couple of iterations, obviously.

[NickFitz]

Oh dear. I have to disagree with NickFitz here
I would argue that there is every point in showing a burndown chart to 't senior management. We've said we are going to do this (you are paranoid), here are the numbers (we know you don't get it), we got there in the end (in yer face).
It takes a couple of iterations, obviously.

Sounds agile to me

[Zippy]

Sounds agile to me

[RichardCranium]

Hmm. We almost have the makings of a Holy War here. And that's best stopped before it is started.

Hello, opinion coming from an experienced PM here who used to be a developer and has successfully run projects in waterfall, RAD, seat-of-the-pants and what-looked-like-panic methods. Enough of the theory and lets add some reality.

I would argue that there is every point in showing a burndown chart to 't senior management. We've said we are going to do this (you are paranoid), here are the numbers (we know you don't get it), we got there in the end (in yer face).

If you have senior management that is sufficiently interested and competent that that can get their head around the benefits of an agile development method, you are very fortunate. You know they will not interfere inappropriately, forgive inevitable weaknesses in the process and provide support where required. If the development team is competent with an experienced senior developer turning the wheels, there is no need for a stuffed-shirt, shiny-suited formal project manager.

If you have incompetent senior management who do not have the time, interest or nous to comprehend software development methods (i.e. the normal sort of senior management), then the developers need to be protected from management. An effective way of doing this is to show the over-paid chair-fillers that someone knows what is going on (because those pony-tailed, t-shirt wearing, oh-so-clever masters-degree-holding scruff bags in IT are not to be trusted). And the way to do that is to tell them what they think they want to hear and that is best done with coloured pictures. Show them coloured pictures and they feel comfortable, like a baby with its pretty mobile. I.e. Gantt charts, resource breakdown charts and, if they try to show an inappropriate interest, hit the bastards with some Earned Value Analysis output. It is with such tools that the development team can be protected from back-stabbers, bean-counters, bored Directors, anarchic process 'improvers' and all the other negative-worth twats that fill all the nice offices in large organisations.


In a lean, technically competent organisation where the staff are empowered and trusted and communication flows openly and freely, a project manager is not required (except writing a business case and establishing the ground rules at the start, possibly) and imposing heavy project management will be a serious hindrance.

In the public sector, most multi-nationals, large consultancies, IT integrators and other organisations where it is more important to be seen to progress than to actually do any work, project managers are normally vital to making a project survive, let alone succeed. And that is done by creating a bubble for the talent to do what it is paid to do in peace. Oh, and sometimes making the tea for them and telling them they are doing a good job.


One should use the appropriate methods and tools for the job, bearing in mind the environment in which it is to be done and the experience of the people who are going to be using them.

Do not use the golden hammer for everything.