You can't do PRINCE2 and Agile at the same time

I've been getting on with two things since my posting that They still think Waterfall's a really good idea... First I've been true to my word - I've been researching a presentation for my more Waterfall-minded colleagues (did you know waterfall was first coined as an antipattern?). Secondly I've become a certified PRINCE2 Practitioner.

This post isn't about bashing PRINCE2. Doing the reading, sitting the course and revising for the exams really sharpened my understanding of some aspects of project management, under any methodology - unless you take the rigid view that eg a Scrum Master is not a Project Manager, in which case you have no-one to do the useful little jobs. Like PRINCE2's disciplined approach to Risk Management, which would have been useful on any project I've ever worked on, in any capacity.

There are some projects on which I'd rather use PRINCE2 than an Agile approach.

The PRINCE2 manual has this to say on the subject of Agile methods:

Many industries or professions have developed lifecycle models for particular types of projects, such as waterfall or agile methods. PRINCE2 works well with such models as they primarily focus on the activities to create and verify the project's specialist products - the aspect of projects that PRINCE2 deliberately does not address.

Address them or not, this just ain't so.

Conflicting assumptions

PRINCE2 provides for "efficient and economic use of management time". Customer management is meant to be involved in the ongoing project as infrequently as possible - their time is just too valuable. Ideally they set the ball in motion, get involved at key decision points and take delivery. If the project goes off course - an exception - they may have to provide a little input.

Agile methodologies take the opposite view. Management should be involved frequently, to guide delivery of a more valuable product and prevent exceptions from arising in the first place. And the product itself is delivered in incremental slices, offering business value even before the project close.

PRINCE2 and Agile methodologies are fundamentally incompatible, from their basal assumptions.

Does anyone try?

In the last few days I've read seven agency proposals for a project that we've put out to tender. Four of the seven promise a seamless blend of Agile and Waterfall, before describing in detail a fundamentally Waterfall process. One promises Agile and PRINCE2.

I said it was the agencies who like Agile.

Guy

Computers are hard

My company's web development platform that uses X.509 user certificates as the primary means of access control. It's great - the platform infrastructure handles authentication and provides HTTP headers which the sites and services deployed on it use to manage authorisation. Documentation, CMSs, development tools - access to everything is controlled through your cert.

A couple of weeks ago I put a new site live with CMS authorisation managed through the certificates, per best practice. Problems started when I was asked to authorise new business users for the CMS. I provided (what I thought were) fairly simple instructions as to how to find their certificate details so I could add them to the whitelist. Some followed them and some - intelligent people - guessed at their credentials based on their email details. In fact some of them didn't even have certificates, though they were convinced they did, and instead reported bugs because they couldn't access the system.

I was left wondering uncharitably "I don't think I can use an edit suite. Why do they think they can use a computer?"

Why do they think they can use a computer?

Quite simply because Microsoft, Apple and others have spent have spent millions of dollars and cumulative decades persuading them that it's easy. It's not - using a computer is hard.

Don't believe me?

• How many new PCs are sold because inexpert users don't know to de-fragment their drive or avoid installing process-hungry system tray apps?
• How many more are sold because experienced users clutter up their registry?
• Why can't I, a software professional, get a consistent keyboard-driven user experience on my Mac?

OK I'll soften that statement a little. Using a computer to a basic level is pretty simple. Using a computer well requires experience and commitment.

What do we do about it?

My experience with user certificates went awry because it was a system developed for developers. No-one thought to make it accessible to non-technical users, and it wasn't.

Remember that using computers is harder than you think. Don't rely on your users' intuition - don't even expect them to hit 'Save' without being led by the hand. Expect them to ignore complex instructions or unfamiliar user journeys ('Open Internet Options and...'). They'll just walk away if they can, and make a mess of things otherwise.

Value your Interaction Designers and Information Architects.

Make it easy for them.

Guy

They still think Waterfall's a really good idea...

I read a bunch of project management blogs - they (almost) all take agile approaches as read. I'd hoped this meant that everyone now understands that agile methodologies give better results than waterfall with lower risk. But maybe agile types are more likely to blog. Or maybe I'm just selecting content that I already agree with.

Last week I was handed a project spec to read that was decomposed into 4 themes:

1. Integrate the microsite fully into our website's strategic architecture
2. Do some interesting archive exploration work
3. Do some more really flashy archive exploration work
4. Add some really really flashy UGC and social network features

This is intended to go a number of agencies to tender for lots and lots of money. There's something wrong with this picture.

What's the problem?

You don't need to know the project or the host site to see that this spec is looking to deploy rather more than the Minimum Viable Product. We're probably not in a position to go live with a beta, and we're commissioning this site from an agency so we can't launch then keep releasing new features. That pushes the boat out, but this spec is clearly well beyond the MVP even under our circumstances.

The risks are familiar:

• Less likely to have a complete release on time
• More likely to incur poorly controlled changes and change-request costs

If we reduce the scope to parts 1. and 2. we can deliver a really great site, using an agile approach, and consider further down the line whether the site needs these particular fancy features or if something else would work better.

Retaining parts 3. and 4. automatically means Big Design Up Front, with complex features planned before basic ones have even been delivered.

Who thinks this is a good idea?

In a word, clients. They still seem to think if they specify the solution up-front they can get exactly what they're asking for.

This is a slightly separate problem from their thinking they're in a good position to specify solutions. A client may well take my advice that "we can't offer you this (at acceptable cost / within the timescale / without breaking the laws of physics) but we can offer that instead". But either way they think we can and should promise something specific. Six months before we code it.

I think the problem's one of education. I've seen scads of books, seminars and websites extolling the virtues of agile, all aimed at technologists. I doubt anyone's ever even explained to my project stakeholder what the difference is, much less why one might be better than the other.

I guess I'd better start educating them!

And then there are the agencies...

True coincidence - the very same day I read this spec I bumped into a non-technical friend who had just been commissioning a new website for his charity. All specified up-front, waterfall all the way. I told him the agency are going to murder his budget on the change requests. He already knows their change-request charges are high.

We know there are some agencies who want to write valuable software well and who battle to educate their clients and exercise agile methodologies.

I'm sure there are many more who'd like to do so, but find it easier to sell work with a waterfall plan.

And I'm just as certain that there are plenty of black-hat agencies who strategically promote waterfall plans to their clients and extract high change costs. Frankly they give our professions a bad name.

Guy

Do It Right or Do It Right Now?

A question I face in software projects on almost a weekly basis: do we implement the feature Right or do we do it Right Now? Of course ideally we want to do it Right and now, but sometimes that's just not possible.

Case in point: we have a bug in a website that we deployed about a month ago. The bug is fairly serious, it's impacting the user experience and the stakeholders are quite rightly clamouring for a fix. On the other hand their critical date has passed - the bug has already done more damage in the last two weeks than it's likely to do in the next two.

We can fix it right now using a perfectly good proprietary solution or we can wait two weeks for a feature to be rolled out across the corporate web stack, enabling a more standard and simpler solution. There's no doubt that in an ideal world this is the better fix.

There are three ways we can go:

1. Do It Right
2. Do It Right Now
3. Do one now and the other later

On the first project I formally managed we did a lot of Option 3. We called it the Tactical solution and the Strategic solution. Now I have rather more experience, I wonder if I should have been more decisive.

I think the choice you make should come down to business value and risk:

• What is the additional value of doing it Right?
• What is the business cost of delaying to do it Right?
• Does either solution involve appreciably more risk than the other?
• What is the additional cost of doing the work twice?

Additional value of Doing It Right

There must be something that makes the Right solution Right. Is it more robust? Easier to support? A strategic enabler? In our case it moves a lot of the work and maintenance responsibility to another team and delivers a business-standard solution. That's a lot of Win.

If it doesn't deliver any value perhaps it's just an engineer's whim - hey I've been that engineer ;)
Do It Now!

Business cost of delay

Presumably there's some pressure to Do It Now and not later. In our case the bug is making some user interactions fail, alienating the users and probably doing reputational damage. Delaying another two weeks would be significant Fail.

No pressure and no cost? Then you're probably not even having this conversation - hold off and Do It Right!

Solution risks

In my example above there's a significant dependency risk in the Right solution. If I make that decision, I'm relying on another team to deliver in a timeframe that I have to commit to my stakeholders. On the other hand, there's also a small risk that the Now solution won't actually work...

Cost of Doing It Twice

There's a cost to doing anything, and double the cost in doing it twice. I don't care if your project doesn't have an explicit budget - while your team's doing the Tactical then the Strategic implementation they're not burning down your product backlog.

So..?

If the cost of the delay plus the value of doing it Right is greater than the cost of Doing It Twice, then maybe you want to go for both the Tactical ans Strategic solutions..

If not, then does the value of Right exceed the exceed the cost of delay? That should tell you which way to go.

And what have we decided? In the end the engineering team didn't deliver the proprietary solution before the new feature hit the corporate stack anyway.

Guy

ps.

I wrote almost all of this post a couple of months ago, when I planned to build my own website (previous post). That would have been Doing It Right, but the cost of delay just became too high. Posting on Blogspot is Doing It Right Now and I'm really pleased with that decision.

Will I Do It Twice?

Having my own site still has its attractions, and if it's worth it maybe I will. This blog may provide part of that answer...and I think that will form the basis of my next post

Damn - it's almost as if I planned this thing!

Why am I here?

Cause time's a-tickin'.

A few months ago I thought I had nothing to say on a blog. I started making a list and found it was surprisingly long. Plan A was to knock up a quick website. I wrote my first post, did some basic site design...and never managed to find a host for it.

Time's a-tickin' so here I am.

Does the internet need another blog about the internet? I don't know. If some people like what I have to say I'll really be quite flattered. And maybe one day I'll take this blog and put it on my own website.

Which segues nicely to that first post. Damn - it's almost as if I planned this thing!

OK let's see where we go!
Guy