It’s either Scrum or it’s not, you either fully commit to a methodology or you don’t.

What I’m not so sure about is the possible alienation if you don’t fully commit.

I don’t see any issue with taking elements of any methodology and working them into your bespoke project delivery process, perhaps on a project by project case.

The aim of all project methodologies is to assist with the delivery of successful projects.

Project success is usually graded on delivering a project on time and to budget, meeting the specifications defined by both client/sponsor and project team.

If in order to achieve this result the project manager decides it’s appropriate to use elements of one methodology and other self devised elements, then so be it, as long as it helps achieve the final goal.

There is currently an obsession with classification, whether it be music or project methodology.

What everyone should be focusing on instead is the quality/effectiveness of the delivery and end the product.

After moving from the IT industry (now obsessed with classification) to the Digital Media industry I am alarmed at the number of agencies that are stating they always deliver using Prince2 methodologies.

Firstly I am not sure that Prince2 is the best methodology to deliver flexible products to 3rd parties such as websites and on-line campaigns.

Secondly I fear half of this is just to reassure clients who need to hear a classification of a methodology, without really understanding what that means. It’s a blind faith reassurance. Misguided and inappropriate.

All methodologies have their place and work well when used appropriately. But if you want to use elements from one and decide other elements to use yourself, then do so.

Don’t call it Scrum or Agile, you can call it what you like, call it Ed’s methodology if you like.

But ensure you keep the process transparent, define your objectives and keep your targets realistic and achievable.

Let’s not obsess with names so much, instead lets focus on delivery.

I’m going to write some more about this sometime soon when I find some down time!

Thanks for the post.

I’m so sorry to pick on your example, Joe, but Daily standups are actually a great example of a practice that can turn out very badly if done without some of the other key agile things like working against a prioritized backlog and having the team work together in a self-organized fashion.

But, meetings look easy to managers so I’ve been on multiple non-agile projects where – after being asked to get more agile – the manager has reluctantly agreed “okay, we’ll try these daily standup things to start with.”

The problem is that trying to have a 15 minute meeting where the team checks in with one another on their commitments is next to impossible when it really isn’t quite clear WHAT people should be working on (just the next most urgent thing!) and when the team isn’t even necessarily working TOGETHER (just each off fighting their own fire).

A couple problems occur – first, if they’re not working together, nobody really cares about anyone else’s updates because they’re too busy with their own problems so it’s not clear who – beyond the manager – is gaining anything from the meeting. Second, the meetings stretch out way more than 15 minutes when their aren’t clear tasks to report against and I’ve seen this turn into daily 1 hour long status meetings which are the most painful things in the world – make the team less effective (huge waste of time) and give them a very poor view of agile, pretty much guaranteeing they will fight further attempts at it tooth & nail.

I read both your blogs (as well as your articles elsewhere). I have read three of your books and will be buying “Manage Your Project Portfolio” when it is published.

I am not someone here to troll or nay-say; I am here to learn and I think it was fair of me to ask for clarification.

That said, my point is this:

A lot of XP, Agile, SCRUM, etc. folks seem to broadcast the message “it’s all or nothing” and I think this discourages new people from adopting their good practices.

If, for example, some mid-level programmer wants to improve their company’s sub-par development process and proposes “Hey, guys, let’s try daily stand-up meetings,” I think we should praise and encourage them and not be overly concerned that it’s not “real” SCRUM nor (ATTN: Dwayne) mock them as cowards.

Amongst other things, introducing Agile was discussed. Linda Rising would apparently disagree somewhat with what you’ve written here in that it can help to introduce Agile, using Agile.

That is take a few small steps, assess how it went, go around again. I can’t agree that it has to be all or nothing, just to be called Agile, when Agile is not really defined strictly enough to necessarily even know when you’ve properly taken the plunge.

In fact I don’t think you can ever say you’ve completely taken the plunge because you should always be assessing and changing, iteratively.

(Thanks for the blog, nice work.)

Sigh.