Agile consultant behind UK's disastrous Common Platform Programme steps down

The head of the agile company instrumental in the UK Ministry of Justice's disastrous Common Platform Programme has stepped down. His departure follows a Register exclusive exposing the project's failings. Jeremy Renwick, chief exec of Agilesphere, held the role of Programme Manager/Agile Coach from February 2015 until April …

[Anonymous Coward]

"It is a sad tale of missed opportunity. A senior civil servant with no experience of running a complex IT programme; an overbearing Government Digital Service with misplaced philosophical goals..."

..And bears, they shit in the woods.

[John Smith 19]

"on a time and materials basis with no hard deliverables or deadlines "

Isn't that what con-sultantancies and con-tractors dream of?

[Voland's right hand]

Agile and government do not mix

Using agile to deliver a government deliverable cannot work.

Procurement, finance, contract selection and deselection, etc are as waterfall as waterfall gets. Add to that the inevitable pre-election "what we have delivered" fixed dates and you get an environment where Agile has no logical function.

You can use agile as much as you like internally, but the actual shipment of stuff to gov (of any shape and form) and gov's side of planning the programme is not agile territory. It cannot be.

So the person to fall on its sword should not be the Agile consultancy, that should be the mandarin which decided to go all-buzzword compliant and run it as agile.

[Lee D]

Re: Agile and government do not mix

You used "agile", "deliverable", "waterfall" and "mandarin" (in the context of bureaucrat) in the space of one comment.

And you complain about others being buzzword-compliant?

[RyokuMas]

Re: Agile and government do not mix

House!

/buzzwordBingo

[Locky]

Re: Agile and government do not mix

Damn,

I had "sprint" and "Did you snapshot all the servers last night? We've had an unexpected result and need to roll back" left on my card...

[Anonymous Coward]

Re: Agile and government do not mix

Using agile to deliver to government can work, and does. I've done several Agile projects for government and they've all been successful.

Even with a legislative deadline to meet, Agile is beneficial. It might look like a legislative deadline means fixed schedule and fixed scope, but in reality it doesn't mean fixed scope. The legislation will tell you what you have to do, but not how. With Agile the customer has constant visibility of progress, and it should be clear to them whether you're on course to meet their goals, or whether scope needs to be reined in and they need to settle for a simpler solution.

With waterfall, the customer's taking your word for it that everything is on course. They hope you're being honest and realistic with them. You hope they'll be pragmatic with you when you tell them requirements need to be cut (good luck with that if you committed to a fixed cost, fixed scope waterfall contract).

This failure probably isn't an agile vs waterfall thing. If they get 30 months into an "agile" project and all they've delivered is a glorified appointment booking system, clearly they haven't been doing agile very well. I expect if the same team had tried to do it as a waterfall project they'd have failed at least as badly.

[Matt Bryant]

Re: AC Re: Agile and government do not mix

"....With waterfall, the customer's taking your word for it that everything is on course...." Male bovine genetalia. With proper waterfall you get a comprehensive reporting system that keeps the customer well-informed. What happens is this - the customer produces a wish-list of airy-fairy nonsense as a requirements doc; the experienced waterfallists say "no, doesn't pass the feasibility study, go away and map out your requirements properly if you want the project to succeed", but the hipsters say "hey, no probs, we'll just go agile (and make it up as we go along)"; management ignore the waterfallists and accept the pipe dream that agile can solve everything; project fails; management finally bite the bullet, tank the hipsters, and ask the experienced waterfallists to try and rescue something from the wreckage. Seen it in government projects plenty of times.

[Sir Runcible Spoon]

Re: AC Agile and government do not mix

I've just had the oddest experience of fully agreeing with everything MAtt has put into a post on El Reg.

Time to buy a lucky-dip methinks :P

[Anonymous Coward]

Re: AC Agile and government do not mix

"With proper waterfall you get a comprehensive reporting system that keeps the customer well-informed."

Who produces the reports?

Unless they're receiving actual functionality that they can use and test themselves, they're taking on trust that your progress reports are true.

[Matt Bryant]

Re: AC Re: AC Agile and government do not mix

"Who produces the reports?...." That depends on how savvy the customer is. If they are smart they will have one of their staff included in the team to make sure what is reported actually matches real progress.

"....Unless they're receiving actual functionality that they can use and test themselves, they're taking on trust that your progress reports are true." LOL, it's called a court case. As it was once put to me by an experienced PM, lying to the customer is bad, but giving them written evidence of your lie that could be used in court, well that's just downright stupid. The Government has lots of lawyers, time and money to pursue those that are stupid. Any consultant worth his money will make sure any report doesn't put a rope round his own neck by falsifying results. Consultants not worth their money....?

[Anonymous Coward]

Re: AC Agile and government do not mix

But 'proper waterfall' is an even rarer beast than 'proper agile'. The fact is that government projects are hard, and the people undertaking them generally woefully ill-equipped to do so.

[<BLINK/>]

Re: Agile and government do not mix

So true, speaking as someone who previously did system engineering for a public facing Gov organisation. Turns out most of the techies were doing Agile-like within their teams even before the high and mighty picked up on those trendy words. These are the same people who would not allow us to take up a discounted offer from a software supplier and make us go through procurement and end up paying more than even the standard price (as they went with a third party to supply us the same licence) and cause a delay of 6 months on a project.

[TechnoSceptic]

Re: Agile and government do not mix

Well, they have to, thanks to Lord Maude & pals, regardless of whether it makes sense or whether anyone knows what they are doing, else they don't get past the Guard Dogs & Sentries: https://www.gov.uk/service-manual/agile-delivery/agile-government-services-introduction

[Anonymous Coward]

Re: Agile and government do not mix

Unfortunately using waterfall approaches to deliver something to the public sector doesn't work either.

[Anonymous Coward]

Agile doesn't work

If you're a half-decent developer you're already more than enough 'agile' without the need to graft a religion on to what you do; if you're not half-decent, then no amount of consultants and twat-speak will make you better. Instead, try using your brain, or try a different career.

[1Rafayal]

Re: Agile doesn't work

Sounds like you dont know what Agile actually is. It goes beyond the work of one single developer.

The whole point of Agile is to deliver small amounts of work on a very regular basis, it doesnt have anything to do with the individual talents of any one person - much in the same way as every project methodology doesnt rely on this.

[Anonymous Coward]

1Rafayal - "it doesnt have anything to do with the individual talents of any one person"

How can that possibly be true? Good software has everything to do with individual talents. A lot of software is in the state it's in today because people like you think everything can be commoditised if you throw enough consultants at it.

[1Rafayal]

Re: 1Rafayal - "it doesnt have anything to do with the individual talents of any one person"

Looks like we have some AC's who have never worked in a team of others.

[Anonymous Coward]

Re: 1Rafayal - "it doesnt have anything to do with the individual talents of any one person"

Looks like we have an 'Agile Evangelist' who doesn't like their religion being questioned...

[Anonymous Coward]

Re: 1Rafayal - "it doesnt have anything to do with the individual talents of any one person"

I think the point being made is that agile is a project methodology, not a programming methodology.

[Doctor Syntax]

Re: Agile doesn't work

"The whole point of Agile is to deliver small amounts of work on a very regular basis"

My experience is that there's a fairly substantial minimum of work that must be delivered to be of any use at all. If your first delivery is, say, a simple order entry screen and a database behind it there's no use anyone entering any data because there's no way of using it because the warehouse needs to be able to get its instructions from the system.

And if the next delivery is to print a despatch note it's still no use. Maybe the third delivery will be a picking list print so it's usable.

Then when the invoicing is added someone realises that the data collected is inadequate. Then go back to the beginning, revise the database and order entry.

A few iterations of this nonsense and you get confronted with an angry DBA who wants to know why you have to keep buggering about with database reorgs and can't you get a simple thing like designing a database right the first time.

[Mike Timbers]

Re: Agile doesn't work

That first delivery *is* useful because although it can't be used it can be tested and accepted. A sprint - especially at the beginning - doesn't have to be shippable, it just has to be testable. It may take multiple sprints to get to the minimum viable product but each sprint along the way should deliver incremental benefits - an interface, a database table, a screen layout with accepted UX.

And as for the DBA, just buy him a pint and he'll shut up!

[eldakka]

Re: Agile doesn't work

@Mike Timbers

I work in Operations/system management.

Our experience with Agile projects is similar to the DBA reference.

We've had to rebuild 10 servers across multiple environments 2 times (in addition to the original build) because the Agile team has gone off half-cocked, had servers built for them for how they like to work, then come to us and said "oh, and when we go into production, you have to manage/support these systems". They used their own deployment system, filesystem layouts and so on.

So our first 'rebuild' (2nd build total) was to set the systems up in the standard we had that just slotted into our existing deployment methodologies and support/monitoring frameworks. And of course, since they were iterating through these sprints, detailed requirements were always changing, from environment-to-environment (dev, testing, integration, production), and since they had drop deadlines we had to, effectively, hand tune each server, so no 2 servers were exactly alike.

So after we got a couple drops into production, so we'd finally been able to nail down exactly their final (well, to date!) configuration requirements, we are rebuilding again with a consistent build/configuration across their servers, so that all are built the same way. So that's the 2nd rebuild, for 3 builds total.

The issues with your "just buy him a beer" are:

1) We don't have the staff resources to do that much repeat work for 1 project when there are dozens happening, we just don't have the manpower -irrespective of the ACTUAL budget- to perform that much work dedicated to 1 project. Doesn't matter how much money they give us, we have an allocated staffing level and we are not allowed to exceed (hire more staff) that irrespective of how much money a project team will throw at us (a projects budget is transient - capital, whereas hiring staff is a permanent employee, an ongoing operating expense, so the project money might fund 2 more staff for 1 year, but who's going to cover those staffs wages when the project is completed? Therefore we can't hire based on project funding).

2) They expect us to do work for them on-the-fly, to immediately respond to their emails/calls/IMs since they are 'agile' and need work done for them to complete this weeks sprint. This basically assumes we've got nothing else to do other than sit their waiting for their calls to do work. Whereas we may be

busy doing work for a project that submitted it's work request 3 weeks ago and have no time to work on their shit - until they cry and whine that we are the reason they can't make their sprint/release objectives and manage to find someone senior enough to either tell us to do their work as higher priority or increasingly often as my manager's manager is starting to do - tell em to fuck off and submit a proper work request and get in the queue behind everyone else

The problem is, Agile seems to require a massive increase in staffing level to support their iterative - i.e. read redoing the same work multiple times (a least in the infrastructure/middleware/backend sides) - and quick turn-around - i.e. expect you to be able to drop anything else you are doing and do work for them - approach because they haven't provided an end-state DB/hardware/support/operations/monitoring/capacity requirements that we can plan around and just build once and mostly forget about.

So buying the DBA (insert here other backend-type staff, infrastructure, server support, etc ) a beer is going to do fuck all for all the extra work and stress the agile teams are throwing around.

[Mike Timbers]

Re: Agile doesn't work

@edlakka, sorry but it's not agile that's at fault in your situation.

your agile teams didn't work with you at the beginning to agree the server build.

or

your agile teams could have developed their software, their table layouts etc. then worked with your teams to implement the service once the solution was functionally complete

or

your agile teams could have built their software to not have dependencies on your builds

or

your agile teams could have deployed onto cloud platforms and supported them themselves

Agile isn't at fault here because agile doesn't specify any method beyond iteration and constant checking with the stakeholder as the iterations progress.

You're describing a failure of process agreement, maturity and delivery.

[Anonymous Coward]

Re: Agile doesn't work

This government project has failed precisely because of ITIL jockeys like you in very senior posts. People who do not realise what cloud and agility REALLY means. YOU should 1) be able to provision a box in minutes. Clearly you can't. 3 rebuilds? Are you fucking joking? It should have been closer every single mother fucking deployment. 2) Your box configuration should PARTICIPATE in the entire pipeline flow. I'm certain this is not the case either with your static shitty infrastructure.

[Primus Secundus Tertius]

Re: Agile doesn't work

I spent my career wondering how to turn science and engineering graduates (whom one would expect to think logically) into competent programmers. That is, produce programs which handle correct cases correctly, and error cases with error handling that does not crash. Programs which were tested to see whether they fail, not whether they barely scrape through a cursory test or merely compile.

Those skills cannot be imparted by management.

I never did find the answer.

[BebopWeBop]

Re: Agile doesn't work

One of the reasons that our experience has been that decent mathematicians make extremely good coders and designers (in real time systems anyway) - got to work to stop them getting bored :-) but the documentation is good if sparse!

[Anonymous Coward]

Re: Agile doesn't work

From what I've seen Agile is insecure and full of holes and often promoted by comedians and slipshods. Fine for a short lived task but fails when reliability, privacy and security are concerned.

It takes discipline and training to implement effectively.

[1Rafayal]

Re: Agile doesn't work

How is Agile less secure than a waterfall methodology?

Or any other project management methodology?

[Anonymous Coward]

Re: Agile doesn't work

Because it allows cock ups like the scheme this article is about and the reason why the emperor has been called out for having no clothes.

I have seen many areas where secure thinking is overruled in the name of delivery leaving the support function to pick up the pieces. With decent design and control this situation is avoidable, but in the interests of cost reduction this seems to go by the wayside. Agile allows people to forget tasks while they move (or are moved) onto other tasks and more glory.

It's not a personal thing as waterfall can either be like a trickle from the meltwater that is management or can result in a whirlpool that everyone gets sucked into.

[1Rafayal]

Re: Agile doesn't work

Agile isnt the reason this project failed.

It failed because its a government IT project and would have failed regardless of the project methodology used.

Your comments on security make no sense what so ever.

[Anonymous Coward]

Re: Agile doesn't work

I'm a taxpayer, voter and citizen and I expect my data always to be secure.

By allowing this project to fail are you saying the government doesn't take security seriously?

Security should be the first and foremost consideration of any project whether government or not. I've found this approach ensures projects are more likely to achieve their objectives if this approach is taken.

[Doctor Syntax]

Re: Agile doesn't work

"trickle from the meltwater that is management"

That trickle from management - I don't think it's meltwater.

[Mike Timbers]

Re: Agile doesn't work

Agile does work and saying it doesn't is ignoring vast numbers of successful agile projects. It's like saying that waterfall doesn't work because of all the failed waterfall projects (and let's be honest, there are some fantastic examples of government waterfall project disasters).

This scheme seems like it was doomed no matter how it was delivered because the whole point of agile is that it delivers iteratively and continuously. If there isn't a step forward for more than a couple of sprints, a good agile project would be asking why and doing something about it. It sounds like this project simply didn't follow any governance. That's not a methodology failure; it's a governance failure.

[The Commenter formally known as Matt]

Re: Agile doesn't work

> Agile doesn't work Because it allows cock ups like the scheme this article is about and the reason why the emperor has been called out for having no clothes.

um no. Thats not agile allowing cockups like this, its management/stakeholders.

The projects been running for 3 years. With agile (assuming 2 week sprints) that means management have had 78 demos/releases showing a complete lack of work being completed, and they ignored them all.

Waterfall would wait for 3 years and then give one release showing a lack of goodness.

[The Commenter formally known as Matt]

Re: Agile doesn't work

No framework will give you the skills you are talking about.

If you don't test fro reliability, privacy and security then they won't be there, Agile or Waterfall.

[Jonathon Green]

Re: Agile doesn't work

No project methodology works.

33 years of experience suggests to me that well motivated teams of talented developers working with good management will produce good quality results in a timely fashion while demotivated[1] teams of mediocre[1] developers working with mediocre management will produce poor quality results late.

In both cases it will be in spite of the methodology adopted rather than because of it...

[1] Trust me, in the absence of competent management if they aren't at the beginning of the project they will be by 6 months in...

[Anonymous Coward]

Re: Agile doesn't work

@JG: Hammer, meet nail head. Bang on, thanks for coming.

[zebthecat]

Sounds as if they weren't actually doing Agile at all but merely spouting the management bullshit that can surround it.

The projects I have been a part of that did use Agile were all about delivering working software first and foremost. From what i can remember that is pretty much top priority in the original manifesto.

[Anonymous Coward]

Yes, no design, no documentation, minimal testing. Just working software. Yeah, right.

The problem is that although all developers think they can do that, very few are actually capable of it. The inevitable result is a large quantity of buggy poo, with a few decent bits here and there that the competent developers worked on.

[Anonymous Coward]

Yeah, so an agile team comprised of shit developers will deliver crap code just like a waterfall team composed of shit developers will. The question is whether a competent team work better under agile or waterfall. Given the correct environment (ie. proper backlog management) an agile team of competent developers will out perform the same developers doing waterfall. This is because agile done properly allows developers the freedom to manage their own effort.

So many posters on here effectively saying "I can't be trusted to organise myself"....

[Vic]

Yes, no design, no documentation, minimal testing. Just working software. Yeah, right.

That isn't Agile!

Agile simply asks you to prioritise working software over complete documentation. Nowhere does it say that the documentation should be absent, nor does it place anything other than working software above documentation.

It should be patently obvious to all that failing to go through a conventional design process never produces anything of value; it becomes development-by-evolution, and almost all evolutionary experiments become extinct.

An old colleague of mine had a wonderful phrase: "A week's worth of keyboard-bashing can sometimes preclude the need for an hour's thought". That pretty much describes the approach of so many people who claim to be "Agile" (and clearly aren't).

Vic.

[Anonymous Coward]

"Sounds as if they weren't actually doing Agile at all but merely spouting the management bullshit that can surround it."

P much.

I've done formal Agile processes in government (usually some form of scrum) and it goes one of two ways.

1) You're working directly for a small, operational team who just want shit done and you're able to deliver on time every couple of weeks. Nothing is perfect but everyone is happy because real things are being delivered, until central IT take over and it all turns to shit as they graft your delivery process onto their corporate standard. From then on you spend more time exporting JIRA reports to their standard project reporting spreadsheet template than you do producing useful stuff.

2) You're working on a "strategic initiative" or "digital transformation" with dozens of consultants where no one has any fucking idea what is to be delivered or what the overall goal is and there are dozens of disparate projects organised into programmes competing for funds. Senior leadership spend their days being bamboozled by the supplier and firefighting one thing at a time. GDS swan into the project once a quarter to tell you you're all shit and should use Ruby for everything. Nothing serious gets delivered but everyone gets paid because it's all T&M because government has *no idea* how to structure a contract to support iterative delivery.

It's not fun, but neither is it unique to agile or unique to government.

[Anonymous Coward]

Agile fine until it hits the real world?

"1) You're working directly for a small, operational team who just want shit done and you're able to deliver on time every couple of weeks. Nothing is perfect but everyone is happy because real things are being delivered, until central IT take over and it all turns to shit as they graft your delivery process onto their corporate standard. From then on you spend more time exporting JIRA reports to their standard project reporting spreadsheet template than you do producing useful stuff."

Not to be cynical but it sounds like everything is fine while the development team asses its own progress and outputs but as soon as the software is used and assessed by someone outside the bubble of self congratulation reality bites but instead of accepting what was delivered did not meet the customers needs the customer gets blamed for not drinking the coolade.

[Anonymous Coward]

Re: Agile fine until it hits the real world?

When the customer is sat a handful of feet away from you using the stuff you're building and shipping once every week or two it's really rather hard to make the argument that the dev team is "assessing its own progress" or that the product "did not meet the customers needs". I would further propose, based on experience, that the delivery teams and end users are far better placed to report progress than a professional project manager whose sole purpose in life is to change the colour of boxes on his ever-sliding Gantt chart.

This is actually at the root what most Wagile frameworks get wrong - particularly in government. Someone takes on the title of "Product Owner" but they're not empowered to make decisions or knowledgeable enough to represent their peer stakeholders. What you'll usually end up with in the civil service is some mid-level fast-streamer from the IT delivery organisation acting as a classic business analyst. You end up without the iron-clad requirements and specifications of proper waterfall and without the empowered decision maker required by agile processes.

What you need is a decision maker with enough clout to bring round a consensus. Doesn't matter if the consensus is wrong - you fix it in the next iteration. It does matter if you spend 2 years and £200m dithering over requirements to the point nothing ever gets built, fooling yourself that it's ok because "it's agile", during which time the carousel of fast streamers and ever-changing senior senior civil servants has been refreshed four times over.

Guess which one happened here.

[Robert Grant]

Re: Agile fine until it hits the real world?

Yeah agree - powerless (and probably 95% absent) product owner makes a huge difference.

To all the waterfallists: you'd be surprised how similar Agile and Waterfall are in achieving results, if both are done properly. The main difference is Agile will deliver what you need now, whereas Waterfall will deliver what you thought you needed two years ago, and now have to lawyer up to argue about what features have or haven't been delivered.

[Roland6]

Re: Agile fine until it hits the real world?

>The main difference is Agile will deliver what you need now, whereas Waterfall will deliver what you thought you needed two years ago

Not heard of change control?

From my experience, the primary difference between Agile and waterfall is in the contracted deliverables and the ownership of risk. With waterfall, I the supplier commit to delivering a complete system that satisfies the requirements within a defined timeframe. With Agile, I the supplier commit to delivering some functionality through a number of development iterations within a time period.

[Anonymous Coward]

Re: Agile fine until it hits the real world?

"Not heard of change control?"

Change control: the act of trying to wrestle reality into being what you decided it should be two years ago, instead of evolving and adapting to reality as it is now.

"From my experience, the primary difference between Agile and waterfall is in the contracted deliverables and the ownership of risk. With waterfall, I the supplier commit to delivering a complete system that satisfies the requirements within a defined timeframe. With Agile, I the supplier commit to delivering some functionality through a number of development iterations within a time period."

You are comparing apples and oranges. The waterfall situation you describe is about delivering a defined outcome. The agile situation you describe is just T&M delivery of services, not delivery of a defined outcome. Agile can be used for both, but agile has a far better chance of delivering to expectations because of far better risk management abilities - unless, of course, management only pay lip service to agile without actually being agile.

[Doctor Syntax]

"The projects I have been a part of that did use Agile were all about delivering working software first and foremost."

At which the users gaze in desperation because there's no documentation on how to use it.

And the developers successor s throw it away and write something that they hope does the same thing because there's no documentation for them either.

[Anonymous Coward]

Your definition of "working" must be particularly perverse if it includes software users can't use. That is not working software, it's just code.

The "we prefer working software..." tenet of the agile manifesto is often read way, way too literally. To put it into the specifics of this context (i.e. government IT delivery), it could read something like:

-"We will not spend one week in three writing Low Level Design word documents that will be filed away, never to be read again, just because the enterprise architecture says we have to"

-"We will not spend half our resource budget on unskilled test resources just because the corporate test strategy says we have to"

-"We will not spend ninety minutes every morning on a daily status call, just because that's the only way the project manager knows how to work"

But that's not to say none of those things won't happen.

It's a rejection of process for process's sake, not an abandonment of the valuable artefacts those processes can sometimes produce.

[Vic]

At which the users gaze in desperation because there's no documentation on how to use it.

Then it wasn't Agile.

Agile prefers working software over complete documentation, not over any documentation.

Vic.

[Joe Drunk]

This never would have happened if they had used DevOps

DevOps^TM, used by savvy bleeding edge consultants everywhere a PHB is seeking a solution for a problem that doesn't exist. Now available in fresh minty flavor.

[Anonymous Coward]

So, £270M for a diary!?

Which begs the bigger question, why in 2017 are people still able to run a viable business developing diaries?

[John Miles 1]

Re: So, £270M for a diary!?

Anyone who has ever been involved with the UK courts will know that the justice system has an almost boundless ability to run up costs and delay. So combining that with a software programme seems a fatal mix.

[Anonymous Coward]

Re: So, £270M for a diary!?

Anyone who has ever been involved with the UK courts will know that the justice system has an almost boundless ability to run up costs and delay. So combining that with a software programme seems a fatal mix.

The problem is that there are WAY too many incompetent idiots involved. If you let competent people do what they're good at you can also deliver something, but it usually has to get to a panic stage before the idiots get out of the way so you can get something done.

I've been there and cleaned things up. It's unbelievable that some companies are even allowed near government IT, but I guess that's why they spend so much money on lobbying.

[Doctor Syntax]

Re: So, £270M for a diary!?

"why in 2017 are people still able to run a viable business developing diaries?"

It sounds more like an unviable business failing to develop diaries.

But in answer to your question, from extensive experience around the courts in the past, looking at it as a diary is probably the wrong approach. Think in terms more of a production planning system where some stages are unpredictable in duration and where the resources needed are being shared with other production processes, some of them quite some distance away.

[John Brown (no body)]

constantly testing our new systems and processes with users.

Oh, great! So add in the wasted time where the users are testing and figuring out how to do today what they did differently yesterday instead of doing the jobs they are paid to do.

Testing is good. Continuous testing with users as guinea pigs is bad.

[Roland6]

Re: constantly testing our new systems and processes with users.

>Continuous testing with users as guinea pigs is bad.

Just the new zelgeist - Windows 10 etc.

[Steve Davies 3]

Agile == Fragile

Coat with really big pocket and a copy of 'Fragile' on 12in Vinyl in it.

[Charlie Clark]

Re: Agile == Fragile

The failure has nothing to do with the methodology and everything to do with the people involved.

[GrumpenKraut]

Re: Agile == Fragile

Methodology, when done as a perversion of some real methodology, is a fine way to terminally destroy the spirit of any good programmer. It is some years since I am out of industry, but, boy, do I hear stories of that!

What stays in such a company is the not-so-good programmers.

[1Rafayal]

Re: Agile == Fragile

@Charlie Clark

Quite true.

[jMcPhee]

Same old con game

In less than 10 years, my former outfit pulled in big buck consultants: McKinsey, then SAP. They got thoroughly hosed by the results.

Agile can work - but not if corporate management uses it as an excuse to evade doing their jobs.

[Primus Secundus Tertius]

Re: Same old con game

Almost any kind of management can work if the programmers can actually design and write software, and are allowed or encouraged to do that.

[Aristotles slow and dimwitted horse]

It's odd...

There is more to this than meets the eye because from an actual solution build and delivery perspective, Agile should have been an approach that could have worked quite well in this instance, and again, should have avoided the normal bollocks arguments that come with the whole Agile vs Waterfall approach. That's not to say though that an Agile approach would have been suitable for the overall and wider programme or that the tenets of a good Agile delivery weren't lost in the presumed quagmire of over zealous and underskilled sales and delivery managers.

For any company to have won the contract to deliver and build they would have had to have gone through a competitive tender process which would have required all of the functional requirements etc etc to have been completed and discussed up front. After all, who would bid on a government tender without understanding those requirements right?

From what I've read this has all the hallmarks of "Agile" not necessarily being the issue, but once again, a total lack of proper programme management controls, resourcing, planning and governance which in itself equates to an 80% chance of failure before you've even lifted a finger.

[mathew42]

Re: It's odd...

> After all, who would bid on a government tender without understanding those requirements right?

Just about everyone. It is damn near impossible to uinderstand the requirements when the government 'subject matter experts' don't have a clue, which isn't helped by branches in different geographical locations follow a different process for the same task achieving a slightly but significantly different result. Managers incapible of making a decision and unions protecting jobs further adds to the complexity.

Yes, I'm emotionally scarred by government contracts. I need to breath deeply and remember that simply delivering a mostly working solution under these conditions should be considered a success.

[JimC]

Re: all of the functional requirements etc etc to have been completed and discussed up front.

The trouble is, as has often been observed, in order to be able to generate functional requirements and all the rest to a suitable standard t reduce the chance of failure to something small, you need probably need a sufficiently capable in house IT service that you don't need to go out and tender anyway.

Managing such contracts is an art in itself. The demonstration I remember was many years ago when my then employer had in house IT in a competitive tendering basis with all procurement responsibility devolved to the departments. The, shall we say Wotsits department's IT 'specialist', whose enthusiasm exceeded his practical ability by a very considerable margin, devised a tender with an amazingly complicated multi level client/local server/central server setup that would have solved all sorts of problems if it could have been made to work properly. However the complexity was such that the chances of it working properly in a reasonable timescale was about zero.

The in house IT department, being a bit naive about such tenders, said this will never work, and proposed a solution based on a central server with some very small local boxes doing nothing more than caching static reports. ICL (that's how long ago this was) won the tender with a proposal that very closely matched the customer specification, and complimented the customer lead on his vision.

Having won the tender, ICL then carefully managed the customer to accept a few minor changes to the system design. What these turned out to be were to increase the power of the central servers an reduce the role of the local boxes to caching static reports...

It was a lesson in the vital importance of customer management I've never forgotten. But think about how high risk it was. If the customer hadn't been sweet talked into, without realising it, completely abandoning his high risk design in favour of something practical then the whole project would have gone comprehensively and spectacularly pear shaped.

[Matt Bryant]

Re: Aristotles Re: It's odd...

"....After all, who would bid on a government tender without understanding those requirements right?...." Er, no. In consulting sales this is called a "Never Ending Story" - a project that, if negotiated around flexible milestones on time and materials terms, will deliver far more revenue than a "deliver X that meets set requirements A through Z for a fixed fee". Remember, consultancies are out to make money, and if a customer will continue to hand over cash for virtually zero progress then the consultancies will take it. Some Never Ending Story projects will keep consultancies paid for years after a properly scoped and managed project would have completed, and the ironic bit is the customer's will end up perpetuating the whole deal because they won't want to own up to failure.

[kmac499]

Seagull Consultants

Everyone was amazed at the beautiful white bird that arrived having flown in so gracefully showing complete mastery of the air.

It was only when it was gone that people realised, while it was there all it did was make a deafening noise drowning out everyone else, it stole all the bread and left a pile of shit behind.

[Anonymous Coward]

Management Repeat after me

Agile does not mean no plan!

by all means split the above sentence in to individual characters, get your devs put the individual words together order is not important at this time. Ensure there is a test to make sure each word is as it should be when it is done. Make sure all words and their test are all complete complete in time to assemble your sentence according to the planned order. Release to the customer.

[Justicesays]

Re: Management Repeat after me

Agile , A Tanned Lemon Spoon!

Not what you were looking for?

Oh well.

[Matt Bryant]

Re: AC Re: Management Repeat after me

No, not Agile. Means does plan?

[sebt]

According to his LinkedIn profile...

...Jeremy Renwick, chief exec of Agilesphere, held the role of Programme Manager/Agile Coach from February 2015 until April 2017.

Also according to his LinkedIn profile, he discovered antibiotics, destroyed Carthage, and turned water into wine.

[Anonymous Coward]

Re: According to his LinkedIn profile......

I am big into the Agile scene. I've never heard of this guy or this company.

That sets my alarm bells ringing.... most big names know each other.

[Anonymous Coward]

Re: According to his LinkedIn profile......

I am really big into the Agile scene. I've worked with this guy and he's very good.

The AC hater set my alarm bells ringing. I mean, who would bother posting this meaningless, contextless bullshit?

[tedleaf]

How about the simple idea of cash on delivery or stage payments ?

If a company is so under funded that it can't finance a project itself,then stage payments,if larger firm then nothing until you deliver a tested working system that does what it's meant to in the real world used by the people it's meant to be used by..

Are there any claw back clauses in the gov contracts ?

[Richard 12]

Claw back clauses?

Hah!

The Government contract teams are apparently almost universally idiots, who even allow clauses saying "If we fail to deliver anything we still get paid. If we are fired for not delivering anything, we still get paid."

As evidenced by a great many examples. *sigh*

[eldakka]

Re: Claw back clauses?

Tenderer contract teams are usually those big law firms who pay their associate lawyers 100K-500K, with partners starting at about 1m.

Government contract teams are usually in-house lawyers that make 40-100k/year who were rejected by the big law firms the tenderers are using.

[FlossyThePig]

No mention of scrum

There's a term that got lost in translation (or perhaps not for government projects).

However, simplified for effect:

A scrum is where two teams push against each other with very little gain in territory

but

A rolling maul can be very successful for one team to gain territory

The Americans couldn't cope with maul as it sounds like somewhere they go to shop.

[Anonymous Coward]

Re: No mention of scrum

That's why scrums should be short... it's a way of getting play restarted but you really want to get the ball out quickly to make any real progress.

[GrumpenKraut]

Re: No mention of scrum

> That's why scrums should be short...

Here is how one company, which shall go unnamed, does it.

Scrum is on Friday and everybody has to attend. Scrum happens at the location the owner lives, which is about 400 Kilometer away from where actual work is done. Scrum lasts 8 hours, with just a short mid-day break. So folks have to get up really early to drive (own cars, train tickets are expensive; traveling time does not count as working time) to that other location, survive that Very Special Scrum[TM], and arrive back at their place only late in the evening.

I was told that your will to live reliably ended before mid day.

This, as an utter surprise, did not work as expected. So now scrum is only every second week, procedure as above.

[Anonymous Coward]

Re: No mention of scrum

All scrums need a good hooker, supported by good props.

[Anonymous Coward]

Re: No mention of scrum

I'm more of a number eight... I'm involved in every scrum, somehow, but mainly I just hang on to the coat-tails of those in front of me without really putting in much effort myself.

[Anonymous Coward]

Re: No mention of scrum

Agile scrums only have one team.

[eldakka]

Re: No mention of scrum

All scrums need a good hooker, supported by good props.

I hope there's more than one good hooker, I don't like sloppy seconds.

[Anonymous Coward]

having delivered numerous agile projects, i can confirm that HMG is perfectly able to work in an agile way.

- deliver one kick-off/workshop about the benefits of agile and talk about the backlog for 20 mins

- prefix the gantt chart spreadsheet name with "agile"

- send periodic boilerplate notes about agile to senior management (generic hipster imagery *very* useful here, i cant stress that enough!)

its that easy.

[AlasGou]

Most agile techniques used in government aren't really agile. It's normally the same people who've failed before but given some agile training. They don't really understand it, so they give their existing process a veneer of agile sounding workflows and wording. But the core is the same.

[Grunt #1]

Who remembers this phrase?

Good enough for government work.

[Anonymous Coward]

The program failed due to a lack of agil

CPP is not agile, which is one of the key reasons it failed. Sure there's lots of lip service paid to agile development methodologies, but at its core it's still a big enterprise-y, waterfall, silo'd, IT project that has learned nothing from past failures.

Unfortunately the Reform program, which has largely followed CPP but with a much larger budget (CPP started with £200m, reform £700m) appears to be following suit with a crazy mandate to affect full end-to-end change of existing services, rather than taking an agile divide & conquer, deliver small pieces quickly and respond to user feedback, approach.

[Anonymous Coward]

Re: The program failed due to a lack of agil

The Reform Programme is run by people who burnt Channel 4's millions and delivered nothing. It is now being sold to consultancies like Atos and slowing removing any independent contractors. It has already started with User Researchers and Business Analysts being asked to leave. It has been unable to digitise simple application like Apply for Divorce even after an year of 20 people working on it.

Unfortunately the Reform programme cannot differentiate between Digitisation and Transformation.

[anoncoward89]

DABLing with Architecture

Jeremy isn't the only one who has left... The Lead Architect has jumped ship and is now architecting the Met Police. Dabbling indeed, what could possible go wrong?

https://insidehmcts.blog.gov.uk/2016/08/12/dabling-with-architecture/

[Roland6]

Re: DABLing with Architecture

DABL - Looks a bit like a waterfall to me, but then given this is Agile, it is probably more akin to a series of rapids - not as impressive as a waterfall, but a lot more exhilarating to ride down.

[Breen Whitman]

"Agile" gets your foot in the door. Boards connect with the word. It implies new and smart. Project approved.

From there, Agile just means feeling your way, because no one knows what they are doing.

[eldakka]

Ahh, so it's like tender pricing as opposed to actual price?

[Long John Brass]

Once upon a time....

I remember doing some Systems Analysis work for an large(ish) education organ. (Yes it was a VERY long time ago)

We talked to all the management to try and figure out what each department did and how it related to the larger organisation. These were the days where most functions were completed via paperwork. When we went to talk to the people at the coal face, we discovered that what the managers thought the department did and what it ACTUALLY did were two different things.

Had a mate who also got roped into some Govt consulting work (Against his will) some 15 years later

He mentioned to me that that although working for a different part of the Govt; The same bullshit was still going on. Additionally, trying to contain the scope creep/churn from the customer was a nightmare! They were constantly changing specs, scope, requirements for parts of the system even completed and signed off ones; every couple of months. When the clients were told by his PHBs that this could be done but it would cost T&M they always said yes, right until the invoices came due; then the client nit-picked every single detail, argued every toss of the coin.

He and his team spent the next ~18 months fighting the customer tooth 'n nail to actually get a system out the door that would actually meet requirements. I believe it was lauded as an shining example of Govt/Private partnership and what could be achieved.

Arguing Waterfall v. Agile in that sort of environment is like arguing the relative merits of paper v plastic bags; While plummeting to the earth from 30,000 feet without a parachute.

[EnviableOne]

What ever methodology you use, EVERYTHING must get done. Its just how you go about it, a dead waterfall project tends to leave quantifiable chunks, wheras a dead agille project tends to leave multiple bits of code that do part of some of the requirements, but dont come together. If both methods are executed fully, you should have a stable, tested, secure and documented deliverable, with all the parameters met, the issue is good Project managers are hard to find, and they usually aren't teamed with good delivery people, so most projects aren't perfectly executed from end to end, and something slips, usually the documentation and security.

HMG and Agile have a culture mis-match HMG havent worked out how to write a contract for waterfall yet, let alone an agile one (incremental payment for incremental work)

Along with the age old problem that HMG dont know what they want from one day to the next (Scope Creep is the no1 killer of large projects) and they are operating on limited funds, with pennywise and pound foolish purchasing departments, which means materials and expert staff are scrimped on, this leaves me wondering how any projects actuall get completed, let alone on time or budget.

[Anonymous Coward]

Unfair

A little late to the party. "A senior civil servant with no experience of running a complex IT programme" THAT is the problem. Not the contractors fault. Take it from someone who knows. Poor, exceptionally poor governance governance governance, is the root to all the badness. Therefore, the people who manage said senior civil servant should be held accountable. Said civil servant should never have been given the job. This is a much wider issue than anyone can imagine. The root cause is governance, the public service is systemically broken much higher up on the ladder.