Who really gives a toss if it's agile or not?

"It doesn't matter whether a cat is white or black, as long as it catches mice," according to Chinese revolutionary Deng Xiaoping. While Deng wasn't referring to anything nearly as banal as IT projects (he was of course talking about the fact it doesn't matter whether a person is a revolutionary or not, as long as he or she is …

[AMBxx]

Re: 'What's Real and What's for Sale'...

Seems to be a case of 'it depends'. It's a methodology, problem is when people think it should apply to all projects. Always seems odd to me that a company would lead their sales effort for consultancy based upon the project methodology rather than successfuly outcomes.

It's very good if you have a budget to use up before the year end, but haven't decided what you need to achieve with the budget - I guess that's why it's so popular in public sector.

[Anonymous Coward]

Re: 'What's Real and What's for Sale'...

> ...based upon the project methodology rather than successfuly outcomes

Gosh, you mean like "I'm a devops engineer"?

[Oh Homer]

Misapplication of methodology

This is what happens when the person designated as most qualified to figure out how to win the America's Cup is the accountant, and he chooses the Caterham.

Agile? Yes, but not on water.

Generally it's probably better if engineering decisions are left to actual engineers.

[oldtaku]

Re: 'What's Real and What's for Sale'...

Technically 'agile' just means you produce working versions frequently and iterate on that. I firmly believe in that basic concept - we have a git repository and a build server, and every time someone adds a new feature or fixes a bug, no matter how minor, they check it in and it builds and we run it. Usually I check something(s) in every day, for the most major things it may take a week, but the goal is always to get it in and working so it can be tested.

In practice, 'agile' is just something people who don't want any accountability at all for the terrible shit they write - who don't want to have to bother designing anything, or documenting anything - invoke as a buzzword. Even the most non-agile projects invoke agile as a get out of work free card.

[Dogbowl]

Re: 'What's Real and What's for Sale'...

Ha! About 21 years back, working at Racal in Bracknell on a military radio project, we had a 'round-trip-OMT' CASE tool that did just that. It even generated documentation from the code so as you added classes and methods the CASE tool generated the design document. Also, a nightly build if it failed, would email the code author.

I have also worked on agile for UK gov projects a few years back when it was mandated for all new projects and I was at first dead keen. However, it quickly become obvious that the lack of requirements, specifications etc made testing a living nightmare. Changes asked for by the customer were grafted onto what become baroque mass of code. I can't see how Agile is a good idea except for the smallest trivial projects.

[breakfast]

Re: 'What's Real and What's for Sale'...

I can't see how Agile is a good idea except for the smallest trivial projects.

It works well if you are in an environment that is built around it and working towards a clear vision. If I was creating a startup, I would definitely use an approach built around Agile because it allows you to get something working quickly and to build new functionality together, adjusting it as you need to, in order to grow your product. A lot of the things that work well about it are related to keeping everyone in a team communicating and aware of the work you are doing- it would be fair to say that a good team will probably do that anyway.

The problem comes when you are working in an environment that is not built around so you end up with diverging expectations - if you are trying to move fast but it takes three months for someone to come back with a key requirement, you're going to have to wait or you're going to implement something half-assed and have to change it when the requirement does come through. If there's no clear vision then you don't know what you are working towards. In government it seems to have been seen as an excuse for changing specification every few days, which in the past was very costly because charging for changes was built into the contracts, but now because they're "agile" it just holds the project up for longer and keeps it in an incomplete middle ground where it is no use to anyone. The charges come from the project taking longer rather than from an upfront cost for changes, but in either case the solution would be to have a clear idea of what the product is supposed to do way earlier. Agile does tend to discourage a complete architectural overview of a product as it is developed, which can be a problem on large projects for sure, but that is quite avoidable if you have competent leadership.

Developing solid, reliable, software is a result of culture more than methodology and unfortunately the culture within the civil service in this country seems actively opposed to it.

[Robert D Bank]

Re: 'What's Real and What's for Sale'...

Yeah, so what have you specified here in any way that doesn't take away from:

'I can't see how Agile is a good idea except for the smallest trivial projects'

[PatientOne]

Re: 'What's Real and What's for Sale'...

"Technically 'agile' just means you produce working versions frequently and iterate on that."

It's more to do with priorities: On time, on budget, to specification: Put these in the order of which you will surrender if the project hits problems.

Agile focuses on On time. What is delivered is hopefully to specification, and within budget, but one or both of those could be surrendered in order to get something out On time. It's just project management 101 with a catchy name, and in poorly managed 'agile' developments you find padding to fit the usual 60/30/10 rule. Then the management disgard the padding and insist the project can be completed in a reduced time as a result, thereby breaking the rules of 'agile' development (insisting it's on spec, under time and under budget, but it's still 'agile'...).

[Doctor Syntax]

Re: 'What's Real and What's for Sale'...

"On time, on budget, to specification: Put these in the order of which you will surrender if the project hits problems."

In the real world it's more likely to be a trade-off of how much of each to surrender.

[Doctor Syntax]

Re: 'What's Real and What's for Sale'...

"Usually I check something(s) in every day, for the most major things it may take a week, but the goal is always to get it in and working so it can be tested."

The question is - is that for software that's still in development or software that's deployed in production?

If it's the latter and your "something" just changes its data format you're going to be very unpopular with your users. And that's just for ordinary files. If it requires frequent re-orgs of an RDBMS then you'd be advised to not go near any dark alley where your DBA might be lurking.

Software works on data. If you can't get the design of that right early you're going to be carrying a lot of technical debt in terms of backward compatibility or you're going to impose serious costs on your users for repeatedly bringing existing data up to date.

[goldcd]

Re: 'What's Real and What's for Sale'...

All boils down to "problems are hard to solve"

Methodology doesn't matter really, as whenever the rules change we are all exceptionally good at gaming the system and will do so faster than you can change the rules to compensate.

The sole solution irrespective of methodology is to ensure that there are as few parties as possible involved and all their fates are bound together on targets that are equivalently those that will solve the problem.

[FozzyBear]

Re: 'What's Real and What's for Sale'...

I was told in my earlier years by a Developer.

For any project you can have it

Cheap, (On Budget)

Good, (On spec)

Quick.( On time)

Pick two of the three and only two. It doesn't which way you pick, you're fucked on the third. Doesn't matter about methodology, doesn't matter about requirements or project manglement. You are screwed on the third and the great news is, is that the level of the reaming you get scales with the size of the project.

After almost 20 years in the industry this has held true.

[Dagg]

Re: 'What's Real and What's for Sale'...

Technically 'agile' just means you produce working versions frequently and iterate on that.

No, technically agile means having no clue as to what is required and to evolve the requirements as you build. All well and good if you have a dicky little web site but if you are on a very / extremely large project with fixed time frame and fixed budget you are royally screwed trying to use agile as there is no way you can control scope.

Hell under agile no one has any idea what the scope is!

[Steve Davies 3]

Government still spends an outrageous amount of money on IT

shouldn't that be

Government still wastes an outrageous amount of money on con{sultants}, more con{sultants} and eventually, IT

As for Agile... Government....

ROFL

[Prst. V.Jeltz]

Re: Government still spends an outrageous amount of money on IT

" hundreds of millions of taxpayers' cash"

Call me naive, I really dont understand how these systems can cost even 1% of the amount of money they manage to piss away.

Computers automate stuff , computer systems are scalable. Computer power has Moore's Lawed its way along for decades now - i have over 1000 times the memory in my pc i had in my first one in 94ish

There are only 60 million people in the uk ,so the amount of criminals is less than that.

A decent excel spreadsheet could hadle this ffs ( joke , no not really obvs)

But seriously , a couple of programmers , a big database , a standard agreed - whats tricky about that?

scaleable - it dosent matter if you are developing for 10 users or 100million really

[Anonymous Coward]

Re: Government still spends an outrageous amount of money on IT

"Call me naive, I really dont understand how these systems can cost even 1% of the amount of money they manage to piss away."

You've never worked in Gov IT projects have you?

I had the misfortune to work on a Gov IT revamp project around 1993. We needed to replace one database server, 45 desktop terminals and a database app that had maybe 25 screens in 80x40 text format. It took close on 3 years, a dozen developers, 3 system integrators and 4 managers!!! I remember as a lowly user getting a week in a seaside town in Lancashire to test 3 screens of the app after 8 months of work. We did 5 hours work on one day and the rest of time spent on the beach eating ice cream and waiting to be called in for more testing. I remember once having 3 people come into the office to to install 2 PCs with Windows, that took all three of them a week to do, this was WIndows 3.1, half a dozen floppies and 25 mins per PC. When they left only one PC would boot up! After 6 months and no fix in sight, I rebuilt it myself and used it as it had been written off.

It's not so much pissing money up the wall as using a tanker load of cow and pig urine and then piping through a fire engine at colossal pressure to spray it up the side of a warehouse!!

[Doctor Syntax]

Re: Government still spends an outrageous amount of money on IT

"There are only 60 million people in the uk ,so the amount of criminals is less than that."

Courts, at least high courts, seem to have enormous scheduling problems.

That's from personal experience. In the worst cases I've spent several hours on each of several consecutive days waiting to be called as a witness despite the fact it would have taken, worst case, about half an hour's notice to get from lab to witness box.

They need to schedule judges, barristers, barristers' juniors, instructing solicitors, witnesses and jurors. Whilst the sittings are built around the judges' schedules it's not always easy to estimate how long a particular trial will last and if one overruns then it might disrupt not only the remainder of the list but also other courts where one of the barristers or witnesses might be scheduled to appear. Add to that the fact that start of business can sometimes be held up as some other matter has to be urgently brought before the judge.

It's not surprising that magistrates' courts are the one thing they've sorted out - my limited experience there is that they have multiple brief cases so, although one might waste half a day, there's no "can you come back tomorrow?".

There could be a huge win by improving high court scheduling but I doubt it could ever be an easy job.

[Anonymous Coward]

Re: Government still spends an outrageous amount of money on IT

I hope you were joking. If not, try reading the classic book "The Mythical Man-Month".

[Prst. V.Jeltz]

Re: 'What's Real and What's for Sale'...

So agile means "constantly adapating " ? read constantly bouncing from one fuckup to the next , paddling like hell to keep up , constantly firefighting whilst going down slowly like the titanic?

thats how i read it

[rh587]

Re: 'What's Real and What's for Sale'...

So agile means "constantly adapating " ? read constantly bouncing from one fuckup to the next , paddling like hell to keep up , constantly firefighting whilst going down slowly like the titanic?

thats how i read it

Yes, no.

The Agile Manifesto is really quite broad. It's a set of aspirations and promotion of a particular mindset.

For instance, SCRUM is not Agile. It can be agile, it can also be very non-agile. I know an agency which does continuous development on a scale of hours. Commits go through automated unit testing, which pitches it onto the Selenium testing battery and then goes to production - or flags red. Instant feedback for the developers - you're not trying to remember what you did two weeks ago and how it's now breaking your release, and because you're committing little and often, you know exactly what has caused a build failure. You submit the changes you made today and you fix anything you break today. They use SVN rather than Git specifically because SVN doesn't let you branch stuff off and then have massive merge conflicts when you try and commit massive changes in three weeks.

But they wouldn't say they subscribe to any particular acronym. They're just Agile. For a different company, or a different industry, Agile might mean something different - how they achieve the aims of rapid release and continuous development are entirely up to them, but might (for instance) draw inspiration from the Toyota Way, Kaizen and continuous improvement principles.

[Lost In Clouds of Data]

It's a Marathon?

You got a problem with a 4 year Sprint?

Just been through a project plan presentation at my place of work for a SAP implementation. It was the most waterfalled Agile plan I've seen in years.

That's the trouble with Agile, it's so flexible that there's way too many assholes who have bastardized it beyond an inch of its life.

[oldtaku]

'Agile' means nothing at this point. Unless it means terrible software.

At this point, courtesy of Exxxxtr3333me Programming and its spawn, 'agile' just means 'we don't want to do any design, we don't want to do any documentation, and we don't want to do any acceptance testing because all that stuff is annoying.' Everything is 'agile', because that's the best case for terrible lazy programmers, even if they're using a completely different methodology.

I firmly believe in the basics of 'iterate working versions as often as possible'. But why sell ourselves short by calling it agile when we actually design it, document it, and use testing beyond unit tests?

Yes, yes, you can tell me what 'agile' technically means, and I know that design and documentation and QA are not excluded, but in practice even the most waterfall of waterfall call themselves agile (like Kat says), and from hard experience people who really push 'agile agile agile' as their thing are the worst of the worst terrible coders who just slam crap together with all the finesse and thoughtfulness of a Bangalore outsourcer.

[richardcox13]

Re: 'Agile' means nothing at this point. Unless it means terrible software.

> At this point, courtesy of Exxxxtr3333me Programming and its spawn, 'agile' just means 'we don't want to do any design, we don't want to do any documentation, and we don't want to do any acceptance testing because all that stuff is annoying

All too commonly it is simply because people (especially anyone with "manager" or "director" in their job title) doesn't bother to understand what agile is, or explain it to the customer. This includes explaining that constantly changing requirements and/or priorities will mean lots of work being abandoned and the time (and money) wasted.

The Agile Manifesto is a good start, with string emphasis on the last paragraph:

> That is, while there is value in the items on the right, we value the items on the left more.

So

> Working software over comprehensive documentation

Does NOT mean "no documentation"!

But that would require spending time learning...

[Dagg]

Re: 'Agile' means nothing at this point. Unless it means terrible software.

Everything is 'agile', because that's the best case for terrible lazy programmers, even if they're using a completely different methodology.

Worst are the lazy BAs who can't get their shit together to actually put functional and non functional requirements together. All they do if wait for something to appear then say "That's not what I wanted". Maybe if they had pulled finger out and actually defined the requirements they would actually get what they wanted first time through without wasting all the time and money.

[Anonymous Coward]

Re: 'Agile' means nothing at this point. Unless it means terrible software.

As one of those lazy BAs, there's nothing worse than providing comprehensive requirements to the design and build teams and getting told "We can't do that, go change it!"

Then you spend weeks/months going back and forth between the business and technology teams with both sides hating you for just doing your job.

My personal favourite is when you are doing a regulatory project - you interpret the requirements, you get legal and compliance approval and everything's just grand - then the developer sees it and tells you that the people with the decades worth of experience in interpreting government regulations have got it all wrong....

But, yeah, it's ALWAYS the BAs who are lazy....

[Dagg]

Re: 'Agile' means nothing at this point. Unless it means terrible software.

Then you spend weeks/months going back and forth between the business and technology teams with both sides hating you for just doing your job.

That just means you aren't actually doing your job. The whole thing about being a BA is being a Business Analyst which mean working out what are the actual problems and pain points of the business. Being a BA is NOT just passing on a solution that has been requested by a customer.

I am qualified as BA and have worked as a BA and the first thing you learn (if you don't you are an idiot) is that humans all ways define the problem in what they perceive as the solution.

<Trainer Mode>

A little example is the person who comes into the shop looking for a star shaped piece of glass to fix a broken window.

So instead of giving a set of requirements to the build team defining a star shaped piece of glass the actual requirements are "Replace Window" simple.

<End Trainer mode/>

If as a BA all you do is pass through what the client asks for then you deserve all the shit you cop.

[Adrian 4]

It's like any exciting new methodology : same shit, different name. In this case, one that allows you to pretend the tiny attention-span of a panicking project manager is a good thing.

When someone shows me they've learned the lessons of Brooke's tarpit,. I'll be interested to see how they did it. Until then, it's all talk.

[jamie m]

25% Agile:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Working software is the primary measure of progress.

[kmac499]

Re: 25% Agile:

From Jamie M

Working software is the primary measure of progress.

Brilliant few word summary which should be scrawled on the wall of every IT project managers office in Foot High Letters.

I've lived through SSADM, RAD, DSDM, Waterfall, Bohm Spirals, Extreme Programming and probably a few others.

They are ALL variations on a theme. The only thing they have in common is the successful ones left a bunch of 0's and 1's humming away in a lump of silicon doing something useful.

[Doctor Syntax]

Re: 25% Agile:

"Working software is the primary measure of progress."

What about training the existing users, having it properly documented for the users of the future, briefing support staff, having proper software documentation, or at least self documenting code, for those who will have to maintain it and ensuring it doesn't disrupt the data from the previous release? Or do we just throw code over the fence and wave goodbye to it?

[Mike Timbers]

Re: 25% Agile:

So he says "working software" and you assume it's undocumented and thrown over a fence? You must have some scars (don't we all?).

Agile doesn't mean no documentation. Agile doesn't mean no implementation planning/testing.

I've never seen such antipathy on these forums for something that - just because it's often done badly - is proven to work. And work well.

No, we don't start without some scope. We get a vision. We work on what that might look like from a solution perspective. Some basic NFR. From those we write some epics. We organise those into sprints and start to break them up into user stories. Hopefully we have enough of a business case to get some idea of budget. We fit the solution to the budget and set some expectations of when an MVP will be ready and how much of the scope will be covered by it. The MVP has *appropriate* levels of documentation/training/infrastructure/etc. but since this MVP might just crash and burn we haven't spent a fortune on an end-state architecture.

If the MVP is successful, we start on the backlog and look at what might be necessary to meet the new NFR.

I really don't understand why so many of the comments on here are so negative.

[Anonymous Coward]

Re: 25% Agile:

I know that is what happens/is supposed to happen, but just the terms involved shit me to tears.

There's nothing to make people think "Info Weekly buzzword bullshit" more than "From those we write some epics. We organise those into sprints and start to break them up into user stories."

That terminology just makes my skin crawl.

[Anonymous Coward]

Re: 25% Agile:

>>>So he says "working software" and you assume it's undocumented and thrown over a fence?

>>>You must have some scars (don't we all?).

>>>Agile doesn't mean no documentation. Agile doesn't mean no implementation planning/testing.

If you have a competent project manager who understands it, that is.

At least now we don't have to throw code over the fence. With Devops, we get to bung it into production ourselves and hope it works.

[HmmmYes]

Are you not making a mistake in limiting your 'UKGOV fckedup' stuff just to ICT (a hated term - its mainly software FFS).

Im sure as you look at other UKGOV spending youll find similar fckups.

Its not a problem with ICT; its a problem with governments and civil service accountability.

A read of Tony Collins report on this project is even worse:

https://ukcampaign4change.com/2017/04/05/another-whitehall-failure-no-officials-responsible-fluid-facts-and-doubtful-ethics-plus-ca-change/

[Anonymous Coward]

If you aren't making mistakes in IT

You live in some sort of awesome utopian parallel universe or you work on a help desk.

IT and cockups go hand in hand since IT is the fastest moving target ever.

[BebopWeBop]

Re: If you aren't making mistakes in IT

But how about addressing the point made by the post you replied to (at least I assume it is the one immediately above your 'reply)?

[Alister]

Re: If you aren't making mistakes in IT

@BebopWeBop

The AC made a comment, it was not a Reply at all.

[quxinot]

Re: If you aren't making mistakes in IT

>IT and cockups go hand in hand since IT is the fastest moving target ever.

Incorrect. Management buzzwords would be the fastest moving target ever.

[bbsimonbb]

Limits of pragmatism

Yup, here you're up against the limits of your culture, anglophone. Agile sometimes seems like just a cliché of english speaking pragmatism and philosophobia. It's been a big success in speeding up and freeing up software creation, but it never promised to give you a unifying vision. At some point, bottom up needs to meet top down, and for that you're going to need a continental. Watch how they do it - GSM, Amadeus, www, the EU. You've got to see a long way into the future, come up with an attractive, credible, vision, accomodate but subtly redirect existing actors/projects, then stick with the vision even when it appears not to be working machin machin. In France "naviguer à vue" is pejorative. Face it. You can't see past your nose. The vision thing has never been your strong point, and now you're on your own brexiter.

[Anonymous Coward]

Re: Limits of pragmatism

You done, or you got some more abuse to hurl at the Brits?

You really think that somehow this is just a British thing? Wow... I can begin to see now why so many Brits voted Brexit with an attitude like yours...

Think they have a word for people like you... Tosspot? Or was it Wanker?

[Anonymous Coward]

Re: Limits of pragmatism

Let's cut down on the nationalistic trolling and focus on the problem at hand maybe? Here is pragmatic.

Think of weight loss programmes...people want a "0 effort" magic bullet that will make them drop 5 stones in 3 weeks while stuffing their face with fish&chips watching telly on the sofa. Well guess what... it doesn't work.

Agile as it is sold to decision makers, not as a principle, is a the same type of snake oil promising results with no effort.

Don't misread me, Agile can be a great methodology... if it used with common sense and not as an excuse to cut corners.

Tell a big business or a government that you have a "Agile" or "Lean" approach to deliver complex IT projects in a quarter of the time/budget and you will always find gullible buyers.

Thing is... you don't lose weight by laying down on your sofa and you don't deliver successful IT by skimping on requirements, design or testing....

[Dan 55]

Re: Limits of pragmatism

That's GSM 2G where you can fake any base station and the phone happily connects to it, Amadeus where you just type in a PAX and get all their data, WWW which was invented by a Brit, and the EU which is made up of 28 countries, two and a half of which are francophone.

Your point, if there ever was one, is lost on me. There are bad projects everywhere.

[Rosie Davies]

Re: Limits of pragmatism

Oh very well done! I think that may win the prize for the most tangential insertion of the UK leaving the EU I've yet seen.

Looks, I understand you're upset. There are a lot on this side of the channel who feel the same way. I also understand the anger and abuse but you need to move past that. You might want to think about seeing a counsellor if it continues to affect you in this way.

Back on thread.

I quite like the idea of thinking of projects in terms of size/complexity (first came across this from the Robertson's categorisation of rabbit, horse and elephant). If you've few stakeholders and can turn on a sixpence then you're in a rabbit project and agile is great. If there are multiple stakeholders (especially if they're in different organisations), heavy regulatory frameworks and generally need to be pointed in the right direction then you're you're in a elephant project and waterfall/Bohm is probably a better fit.

Horses for courses (to continue the animal theme). This project has all the hallmarks of an elephant so it looks as though the rabbits have been crushed underfoot.

Rosie

[bbsimonbb]

Re: Limits of pragmatism

I actually don't have strong feelings about Brexit, despite being affected personally (Going to have to apply for a 3rd nationality. Let's hope Marine Le Pen doesn't get up.) I wanted to talk about cultural reasons for the success and failure of IT projects. If you don't think there are any, or if you can't see that agile is a caricature of anglo cultural values, then really you need to get out more. From the replies, it's not clear anyone's considered that IT is also practised in non-English speaking countries.

[Charlie Clark]

Re: Limits of pragmatism

In France "naviguer à vue" is pejorative.

Software development in France* which also gave us ah yes, it may work in practice but does it work in theory.

The story is about the highly unusual cost overrun of a government project. Never happened dans l'héxagone? Because it seems to happy pretty much everywhere else with relentless monotony because politicians are fucking awful project managers.

* FWIW I have a French qualification.

[JLV]

Re: Limits of pragmatism

>ah yes, it may work in practice but does it work in theory.

Zut alors, j'allai le dire moi-meme ;-)

[Anonymous Coward]

Agile only works if all stakeholders agree on an outcome

For a project that is a huge change of operating your organisation it is unlikely that you will be able to deliver, at least the initial parts of your project, in an agile way. Once outcomes are known at a high level stakeholders have something to cling onto when they are asked what they need, if indeed they exist yet. (trying to ask for requirements for a stakeholder that doesn't exist yet is tough).

Different methods have their own issues, but in this case I would have expected failure to be reasonably predictable.

You wont have much to show for it, as they shouldn't at least, have started coding to a business model that itself needs defining. This is predictable, and overall means that no one agrees what the business should look like, let alone how a vendor delivered software solution should support it.

I have a limited amount of sympathy for the provider for this as it will be beyond their control (limited as they are an expensive government provider after all)

This is a disaster caused by the poor management in UKGOV and the vendor should have dropped and ran well before this.

[1Rafayal]

Re: Agile only works if all stakeholders agree on an outcome

what, you mean just like every other methodology?

[Anonymous Coward]

Re: Agile only works if all stakeholders agree on an outcome

Yep,

but contracting out seems to blind management teams to the need for their own participation. The vendor is their to build software, not define an organisation.

I believe this is less visible in agile as it is far easier to find something to burn resources on (and bill for) when basic foundations are not defined, let alone signed off.

[breakfast]

Re: Agile only works if all stakeholders agree on an outcome

A big part of the problem is that all the in-house software expertise in the civil service got privatised in the 90s, so they have nobody of their own with any knowledge of software development at all. That makes it really hard to get solid co-operation between the in-house people with domain knowledge and the development teams or even for the in-house management to appreciate how important that is.

[FlossyThePig]

Flossy's rules of computing

I've just added Rule 2.

Rule 1

Any project using new tools or methods with "ambitious" timescales will fail.

Rule 2

Any large scale public sector development will exceed the initial budget by a factor of x* times and will be late.

* - choose any number but you may underestimate the value.

I will add more when something else blindingly obvious occurs.

[Anonymous Coward]

I'm a one man, self employed business - I do some very complex sites - but if they don't work I don't get paid. If they spew ugly bugs I get paniced emails from unhappy clients.

So I test after each update and comment code and add features to make my life easy when it comes to debugging. Woo, it even send me emails for some bugs.

I'm in agreement with the guy above - a dozen devs, a page layout designer or two, some databases. One manager to co-ordinate and no bloody jargon.

There's a MASSIVE efficiency to small teams but all the members need to be on top of their game.

[Doctor Syntax]

"I'm in agreement with the guy above - a dozen devs, a page layout designer or two, some databases. One manager to co-ordinate and no bloody jargon."

Don't forget a well-defined, soluble problem. That's in your case, where you're paid by results. If you're paid by billable hours it's a positive disadvantage.

[Jonathan 27]

Agile is just today's favourite methodology, and it doesn't fit all cases. I'm sure that in 10-15 years we'll be all about something else. I also find that a lot of companies only implement the parts of agile methodologies that they find easiest to implement, which sometimes leads to unnecessarily complications or lack of any real benefit. Most agile proponents are all or nothing guys, so there is a case to argue that what these guys were doing wasn't agile at all.

[Munchausen's proxy]

Agile Expertise?

" I'm no expert in project management, but I'm pretty sure it isn't supposed to be making it up as you go along, and constantly changing the specs and architecture."

I'm no expert either, but I honestly thought that was quite literally the definition of agile. (maybe disguised with bafflegab, but semantically equivalent)

[Zippy's Sausage Factory]

Re: Agile Expertise?

I always thought that one of the key goals of agile is to be able to cope with clients who continually try to change the specs and architecture. Although to be fair, hiding under the desk with some painkillers and a bottle of gin are also a possible (if shorter term) solution...

[Doctor Syntax]

Re: Agile Expertise?

"I always thought that one of the key goals of agile is to be able to cope with clients who continually try to change the specs and architecture."

it works if you're able to exhaust their capacity to change; at some point they need to stop so you can deliver something. When politicians are the clients that's not going to happen this side of the heat death of the universe.

[Zippy's Sausage Factory]

Sounds like what I have said for a while...

The "strategy boutiques" saw "agile" becoming popular and they now use it as a buzzword.

These days, I put it in my "considered harmful" bucket, along with GOTO, teaching people to program using BASIC, and "upgrading" to Office 2016*.

* Excel, in particular.

[EnviableOne]

The lot in charge might change, but sir humphrey still runs the country

The mechanisms in Whitehall and all government run organisations are archaic and a complete anachronism to modern business practice and operate like many firms were in the 80s, and are completley resistant to any change.

if they stopped going back to the same old incompetents that failed last time, but can put in a good bid document like: G4S, Capita, Atos, Serco, BT, CSC ... then they might actually find someone who achieves something.

if they said solve this problem and let competent people get on with it (within a defined SLA) then they might actually achieve something.

[Tim99]

Re: The lot in charge might change, but sir humphrey still runs the country

But they do achieve something. We might think that the purpose of a publicly funded project is to produce a working system. Their real purpose is to funnel extremely large amounts of public money into the pockets of the anointed few. If the project is inexpensive and produces something that works, it has failed. A perfect project has an exorbitant cost, and does not produce a working solution - Failure is expected, otherwise you can't keep respeccing and redoing it over years at high daily rates.

[a_yank_lurker]

Buzzword Bingo

All too often a sound development ideas are perverted. The concepts are sound but the mistake is to view each as the perfect panacea to produce bug free, working code. Each has its purpose and scope of effectiveness. What should be understood and applied is not a precise cookbook method but principles - Agile focuses communication between groups and ensuring all on the same page. Others focus more on low level development (test driven development, e.g.) but one can lose sight the goal is use an appropriate tool set to make sure quality code is produced. Again, is the code being tested, are the tests correct, are junior developers being mentored, are developers working together appropriately for the nature of the projects are issues to be addressed not the precise formalism of the insultants.

Uncle Bob Martin has noted that one of the problems the formalisms try to address is the large number of junior developers who need proper mentoring, training, etc. in real world situations. He noted that in the old days many IT pros were mid level professionals who wandered over to IT and many of the formalisms so beloved by the insultants were concepts they did naturally. Cross functional team meetings - check, mentor - check, use appropriate tests - check, etc. These are professional procedures common to other fields and were ingrained mindset and habits.

[Doctor Syntax]

It's worth remembering that it's the disasters that make the news. I've worked on a number of public sector projects which were successful. After a few years of operation, however, the contract period was up and the whole service put out to re-tender.* At that point someone else gets the contract so the original work on which the successful delivery was based got scrapped.

* With some very odd results, it has to be said, but that's a different story.

[russell 6]

Project Management

I'm not a project manager but I deal with a lot of them. Here is what I understand. Never allow the customer to convince you to create the specification for the project. The customer should have a very good idea of what they want before they talk to you. If you create the specification for them, you are setting yourself up to fail as the spec will get changed so many times along the way, so much time will be lost before you even begin the real work, it is also a way for the customer to shift the blame if something goes wrong as you created the specification for them.

Make very clear to the customer that what might seem like small modifications to them can actually take a huge amount of time and expense to impliment and deadlines will be missed.

Make sure you have a very accurate picture of the existing systems you need to integrate with before you agree to anything x100

Seems like little of the above happens on Government IT projects

[goldcd]

I like agile

especially compared to the alternatives, but always struck me as something fundamentally better suited to smaller pieces of on-going work.

Bluntly for stuff you can break and then fix, within a sprint.

Now I'm fully aware your agile guru will tell you that this isn't an issue and it scales, but at a personal level I've yet to meet a budget-holder or a dev, who will sanguinely accept that tested and paid-for code is going into the bin and it should simply be considered to be "part of the process" and there is no need to attribute blame.

My personal niggle is that a team has "velocity" rather than "speed" - and that seems to be a somewhat deliberate and disingenuous selection. The team should have speed, the project ultimately a measurable velocity calculated by working out how much of the speed was wasted in the wrong/right direction.

Anyway, off to get my beauty sleep, so I can feed the backlog tomorrow with anything within my reach.

[Notas Badoff]

Re: I like agile

Wanted to give you an up-vote as "velocity" vs. "speed" is exactly the sleight of hand that infuriates me. We do want eventual progress achieved, as in "distance towards goal in mind", right?

Unfortunately my reading the definitions and checking around leads me to think that you've got the words 'speed' and 'velocity' reversed above. Where's that nit-picker's icon....

[goldcd]

My take would be "Agile in moderation"

Think of building something else "non-software", such as a building...

'I want to build a 100 storey skyscraper' - LET'S GO!!

"erm I'm making the foundations, what do I need to do?"

'Support 100 storyes you fool!'

"Give me a clue, what will they weigh?"

'Take an educated guess on Monday and start build on Tuesday'

"erm OK, I've made some foundations that could technically support the minimum weight of 100 storyes, but I'd really like to shore them up a bit, I mean they're definitely foundations and you were very happy when I showed them to you, but.."

'Start building the ground floor, we'll come back to foundations when they're a priority!'

"b.but. OK."

'Nice Ground floor, well done. Have a pizza on me!'

"They did come in a few percent heavier than we had previously planned."

'No matter, we'll lighten them if the first floor is too heavy for them. Keep Agile!'

"The first floor is fine, I've no qualms about that, nor the next dozen, but I *really* think we might hit a problem a year from now. I've jotted down some projections for the next 99 I could maybe share with you?"

'Your projection indicates you want me to both re-work the foundations AND the single floor we've built so far. I spoke to the budget holder and they're concerned about the re-work you're suggesting. We're only two sprints in and you want to undo two sprints?'

There are two ends to this story of storeys.

[bfwebster]

I literally less than an hour ago gave my CS 428 ("Software Engineering") class here at Brigham Young University (Provo, Utah, USA) my final lecture for the semester, which included this slide:

Process is not a panacea or a crutch or a silver bullet

Methodologies only work as well as the people using it

Any methodology can be distorted to give the answer that upper management wants (instead of reality)

When adopting a new methodology:

-- Do one or two pilot projects

-- Do one non-critical real-world project

-- Then, and only then, consider using it for a critical project

Understand the strengths and weaknesses of a given methodology before starting a project with it. Also, make sure a majority of team members have successfully completed a real-world project using that methodology.

[Pete 2]

Save some fun for us!

> under the guise of "agile?". I'm no expert in project management, but I'm pretty sure it isn't supposed to be making it up as you go along, and constantly changing the specs and architecture.

So why should the developers have all the fun? Why can't the designers and architects be "agile", too? Isn't constantly changing stuff all part of the "agile" way?

[Potemkine]

"once-in-a-lifetime opportunity"

Taking so much money when giving so few in return is indeed such an opportunity.

[Anonymous Coward]

It is not Agile it is Gov

Having worked at number of digital Gov projects across different departments over period of 2 years here is my 5 cents.

The problem is not Agile it is Gov.

Now it would seem Agile just becomes a scape goat for Gov mismanagement that has very little to do with Agile methodology itself.

To add some background story. Gov transformation programme was not about methodology - it was about building open software using open source technologies in-house rather than paying hard £££££££££ for blackbox solutions provided by the Big Suppliers. Since the drive was to use OpenSource and in-house development obvious choice of approach and methodology became Agile/DevOps.

Agile/DevOps does not work if the whole "Company" top to bottom is not behind it - and many Public Servants doesn't understand it or treats it as an invasion and often create roadblocks. This organisational size also brings immense complexity to projects which are rarely independent and standalone components and often depend on interacting with other parts of Gov that is worse-than-waterfall - again more road blocks.

Gov is immense larger-than-enterprise organisation, what is more is by definition "political". By political I mean there is constant political war inside of Gov departments and projects over influence and power and this is what is screwing the whole idea. There is constant war between old-world of Big Suppliers trying to regain their grip on Gov purse and new comers invited to implement things in-house, this creates very un-Agile and unhealthy environment where such methodologies have difficulty to trive.

In many cases Agile is just smoke-and-mirrors with very few Gov projects that get the Agile.

Once eye-opening example - unnamed Gov department has what it calls proudly "Cloud" provider - however to get new instance of a vm - one has to fill in spreadsheet and wait a week to get the VM up.

One big Joke.

[EnviableOne]

Re: It is not Agile it is Gov

Firmly agree, trying to get gov projects to work like private sector is a hiding to nothing.

90% of UK.Gov projects fall apart at layers 9 and 10 of the OSI model

http://www.vca.ag/financial-osi-layers-8-9-10/

[Anonymous Coward]

In Finland we have this thing called Kieku. It is a 175000000 € badly working spreadsheet web app for writing down work hours for government workers.