Agile will fail GovIT, says corporate lawyer

| 58 Comments
| More
In a guest blog, corporate IT lawyer Alistair Maughan argues that Agile development is an evangelical fad ill-suited to government IT.
 
Maughan_Alistair High Res.jpgThe Government ICT strategy had some good ideas. Agile project management isn't one of them.

The Cabinet Office expects Agile will reduce the risk of ICT project failure. It's a nice idea in theory. But it won't work in government IT. It won't work in the real world.

Two of the most cautionary examples of failed ICT projects in recent years demonstrated the drawbacks of Agile.

The court battles of BSkyB v EDS and De Beers v Atos Origin showed that when Agile projects go wrong, they can go spectacularly wrong.

The Agile methodology is meant to deliver IT projects flexibly, in iterations. It's meant to involve customers more directly and adapt quickly to their changing needs. This means the final system only emerges gradually. It means customers don't pay a fixed price for a complete project. They pay for a commitment of resources.

But the lack of clearly defined project roles and requirements is a problem for Agile.

Agile evangelists argue fiercely that the conventional waterfall development methodology is unrealistic. They say the sheer scope of work required by its pre-set deliverables often leaves it unable to fulfill expectations. They set themselves up to fail, say the evangelists, when they should be working collaboratively for success.

I'm prepared to accept on trust that, if all goes well, Agile may reduce the risk of project failure. But Agile simply won't work in the real world of government ICT. We need a Richard Dawkins to bust the myth of the Agile gospel.

Sceptical

There are four clear reasons why Agile won't work in government ICT. The most obvious is that government customers want to know up-front how much a system will cost. That's not so unusual, is it?

Under Agile projects, you pay a given amount of money for a set amount of effort. But you can't guarantee a specified outcome for a specific price.

This won't work in government. Departmental budgets are managed very tightly, and they must be approved. Agile implies that charges for time & materials should be open ended. Government departments won't accept that.

Government is also legally required to follow open procurement rules.

That means comparing different bidders on a like-for-like basis, and deciding on best value for money. Agile can't give you a clear specification of outputs up-front. Nor can it give a definitive up-font price.

So how are government bodies supposed to make Agile comply with the legal requirement that public procurements are fair and open?

Unprotected

As if that isn't problem enough, Agile offers insufficient means of remedy if things go wrong.

This is a particularly sensitive issue for government, where departments suffer public opprobrium if their project isn't a resounding success. The press, the National Audit Office, and the Public Accounts committee (PAC) will give government a kicking if they can't make suppliers pay for the damage they caused.

Agile makes it hard to apportion blame because the customer is intimately involved in the work. Since Agile contracts lack clear contractual delivery obligations or remedies, how do you enforce properly? How do you recover loss or damage if there's a problem?

I wouldn't want to be the first Permanent Secretary to admit before the PAC that his or her department has no real right of legal recovery from a failure.

Poor fit

Agile is fourthly not suited to public sector management structures.

Decision-making is centralised in government. Civil service structures ensure every important decision flows up to senior levels. The Cabinet Office has under the current government taken even greater power over ICT projects. But Agile decision-making (over requirements, for example) flows down. This is key, so small devolved teams can react quickly and adjust to new scenarios.

It is inevitable that Agile decisions will go through management hierarchies in central government. This will be like kryptonite to Agile projects.

Agile projects rely on decisions based on mutual trust. They are therefore well suited to in-house projects. But the faith they ask customers to have in service providers makes them ill-suited for external developments.

You can have an ICT project with a watertight contract, clear deliverables, openly and legally procured, with a fixed price and appropriate remedies if you don't get what you want. Or you can have an Agile project. You can't have both.

I do appreciate that as a lawyer specialising in large ICT projects, you may think, "Well, he would say that, wouldn't he?". But my job is the help create successful projects.

I've seen too many projects flounder for a lack of trust between customer and supplier to think the answer to government's ICT problems is the Agile credo of, "Let's trust each other some more".

Partner and head of Technology Transactions at international law firm Morrison Foerster, Alistair Maughan has advised on large public and private IT contracts including HM Revenue & Custom's controversial 10-year £8.5bn deal with Capgemini. Follow him on twitter @ICToutsourcelaw

58 Comments

  • Agile is a broad camp and encompasses a number of methods. Your comments are not applicable to all of them, therefore this invalidates much of your argument. With DSDM Atern for instance, the cost, timescale, quality are fixed and the scope is variable. How does this sit with your assertion that the cost is not known?

  • I agree with some of Alistair's points, but I think this article is way too black and white. Any methodology can be adapted to suit the culture and environment in which is it being applied. A great benefit of an Agile method is transparency which the current government seem very keen on. It's also worth noting that Agile is not really a methodology - it provides a set of principles and way of thinking.

    This point in the article is very misleading:

    "Agile can't give you a clear specification of outputs up-front."

    With the Scrum methodology user stories provide a very clear specification of the outputs up-front, without prescribing *how* the outputs will be achieved. In my experience of using Scrum in local government (for the last 2 years) we've found that business stakeholders can easily relate to user stories, unlike more prescriptive technical specifications. Because user stories are simply a way of clearly expressing how a system will meet user needs, they can be used as requirements within procurement processes.

    "Under Agile projects, you pay a given amount of money for a set amount of effort. But you can't guarantee a specified outcome for a specific price."

    From what I've read in research literature (and heard anecdotally about failed government IT projects) I don't think the waterfall method has been particularly successful in guaranteeing a specified outcome either!

    For anyone interested in debating this article, there have been some interesting discussions about the application of Agile principles in Government IT projects on Twitter at #pubsecagile.

  • "You can have an ICT project with a watertight contract, clear deliverables, openly and legally procured, with a fixed price and appropriate remedies if you don't get what you want."

    Sure, and you can also believe in fairy tales. The real problem is that this is an illusion. But if you want to compare fairy tales, be my guest. Meanwhile, the JSF fighter is get more and more expensive, and milestones are postponed. Here is your example what you get if you believe these fairy tales...

  • Absolutely right.

  • The author rightly points out that Agile won't work in the public sector, but points at the symptoms rather than root cause while actually mentioning some of the root causes.
    The culture and management structure are the very issue and root cause: public sector culture and management structures have become fundamentally politicised, dysfunctional and unable to deliver, a system whereby apportioning blame after the fact is more important than ever delivering anything.
    The prospect of Agile is likely a vendor response to the fact that most public sector bodies cannot even remotely begin to specify what it is they are actually procuring, something that the author seems to deem rather important.

    Culture and management structure are the very issue. Leave that unaddressed and no amount of "processes", Agile or no Agile will ever be able to do anything about the ills of public sector IT projects.

  • "Under Agile projects, you pay a given amount of money for a set amount of effort. But you can't guarantee a specified outcome for a specific price."

    Agile is not a single method, but a set of principles and tools. It ranges a from complete aversion to up-front requirements and project management (very 'pure'), through to a pre-defined set of high level requirements and a strong project management and governance model - as in DSDM (as mentioned above).

    With the latter it is possible to guarantee a minimum specified outcome for a set price. (As much of a guarnatee as can be given for more tradtional methods at any rate).

    I do accept that agile methods are significantly more feasible within an in-house development team, because external suppliers are reluctant to provision resources rather than deliverables. This would need to change for agile to be widely applied across government.

    It's in big supplier interests to keep things as they are - where the costs of minor changes once projects have commenced are often prohibitive and the users suffer.

  • A typical lawyer's perspective: The problem with getting projects delivered is the lack of adequate formal accountability mechanisms.

    I doubt that we need a lecture about the "real world" from someone supporting the status quo that has demonstrably failed to deliver adequate results over time.

    So rather than saying that Agile is a bad fit for government, maybe we need to look at the aspects of government culture that inhibit the development of successful IT projects.

    Some of these might be:

    - Overambition: Projects are too large and too long. Break them up and get something useful in the short term rather than taking the risk that specifications are still going to be relevant years ahead.

    - Lack of competition: Government procures large projects and needs large suppliers to deliver them. The vast majority of work goes to a handful of firms who carve up the market between them, none of them with any real motivation to do a better job.

    - Inflexibility: The same bureaucratic structures that the author believes won't tolerate Agile are the very same ones that are unable to adapt in time to a dynamic political, economic and technological context. Rather than having cumbersome IT development that suits cumbersome government, everyone should become more flexible.

    - Scepticism: The author believes that suppliers can't be trusted and only watertight specifications and contracts will make them behave. I agree that there's no point in giving firms trust that haven't earned it. But this is just a straw man argument: No Agile proponent says that giving blind trust to a supplier will make them do a better job. Instead, you need to cultivate relationships with firms that actually deserve your trust so that work between client and supplier can genuinely be more collaborative and less antagonistic.

    So if anyone's looking for instruction about the "real world", it's this:

    - Detailed requirements aren't always known up front and simply writing down your best guess and setting it in stone doesn't guarantee good results

    - Things change outside in the real world and the longer your project goes on, the more they'll change

    - No contract can compensate for a project that is delivered according to specification where the spec is wrong. In conventional terms this is considered a success when it's actually a failure.

    - The inability of government IT projects to exploit emerging opportunities mid-project probably costs as much as conventional project failure. Yet it's completely unaccounted for.

    In short, design simply isn't a bureaucratic process. If you try to shoehorn it into one you'll either get conventional project failure or bad design. Government needs to adapt itself to effectively manage good design process. I doubt that corporate lawyers have much expertise to offer on that matter.

  • I think that this article by Tom DeMarco has something useful to add to the debate, most notably the notion that tight control only really matters on projects where the benefits narrowly outweigh the costs. If a 5% cost overrun makes your project non-viable, that suggests that you probably shouldn't be doing that project.

    These judgements are often difficult to make in the public sector, because "value" is not always clear. In these cases, it can certainly be tempting to set clear (but arbitrary) targets and aim to hit those, in lieu of being able to say that, even with a 5% (or 50%!) cost overrun, the project delivered more value than it cost. This might be more satisfying and might give an outward appearance of order and clarity, but it reflects a narrowness of focus that ignores or denies the fundamental questions about why a project is being undertaken to begin with.

  • I have just skimmed through the judgements from the two court cases that Alistair mentions. There were nearly 600 pages - and I may well have got this wrong - but my feeling was that, whilst the ideas of 'Agile' methods were perhaps used to sell the projects in the first place, the actual failure of these methods was not central in either case. In fact, it seems that both projects followed a traditional waterfall approach:

    * In BSkyB vs EDS: " ...[EDS] accepted that the more detailed ... plan was a classic Waterfall plan and not an iterative RAD plan."

    * In DeBeers vs Atos Origin: "...Atos had begun to realise that it would no longer be possible to deliver the software using an iterative approach as had been the original intention. It resolved, and agreed with DB at a meeting held on 18 December 2007, that delivery would be in the form of a 'Big Bang' at the end of June 2008...".

    That said, I can't disagree with Alistair's assessment, at least in the short term. The context of existing ways of thinking, governance, culture, policy, law and so on, will make it tough genuinely to adopt agile principles. If Government tries to to force the use of these new methods without attending properly to these wider issues then it's easy to envisage repeats of Sky's or DeBeers' experiences.

  • This is rubbish...

    I have personally been involved in delivering a fixed price Agile project to a government customer. The project was a huge success that delivered something a traditional waterfall approach had spent 3 years trying to deliver and failing.

    You may not know how to deliver fixed price Agile projects yourself, but that doesn't mean they can't be done.

    Andy

  • This is rubbish...

    I have personally been involved in delivering a fixed price Agile project to a government customer. The project was a huge success that delivered something a traditional waterfall approach had spent 3 years trying to deliver and failing.

    You may not know how to deliver fixed price Agile projects yourself, but that doesn't mean they can't be done.

    Andy

  • I've worked on several "agile" public sector projects, and none of them have delivered any of the promised advantages of Agile. The reasons are probably familiar to anybody who's worked on government IT projects: slow and bureaucratic internal processes, inability to take decisions, inability to decide on requirements (ever), lack of commitment from business users, lack of understanding of Agile in IT departments, inability to deliver rapid iterations, lack of rapid feedback between users/developers, lack of empowered business representatives, grotesque over-engineering by consultancies, inefficiency of IT staff/processes, and much more. All too often you get the worst of both worlds: the bureaucracy of waterfall and the vagueness of Agile.

    I'm sure Agile can work in the public sector in theory (but then so can waterfall approaches - in theory), it's just that I've never seen or heard of it doing so anywhere.

  • Agile is just a buzz word for common sense.

    I guess even government projects could benefit from common sense ?

  • The article is just FUD, his entire revenue stream is based on negotiating adversarial contracts that expect failure so he can cash in on the ensuing litigation. Nice work if you can get it!

    An interesting presentation on working with suppliers in an agile way, by Standard and Poors
    http://tinyurl.com/6ceajuf

    Another example of how it can work
    http://zakholdsworth.com/tag/agile-contract-negotiation/

  • It is not only goverment / public sector that likes to know costs upfront before committing to a contract. There are many 'low margin' private industries where key investment decisions hinge upon knowing some features / benefits can be achieved within a set budget and timescale. This puts many service suppliers in a position where estimates have to be made and risks taken even if the delivery is performed using Agile.

    For a simplified example, imagine a change enforced in a fixed timescale by government on private companies, e.g. a new tax. Agile or not, all those companies have to develop their systems to meet that capability in the deadline very often for a known cost.

  • As a brief response to this I'd say


    1. It's good to see intelligent discussion of this topic from an non-technologist, and those genuine concerns need substantive responses. And to that end...

    2. Agile still needs strong and effective project (or programme) governance. Agile development does not have all the answers, but agile development plus appropriate governance provides very effective delivery, and addresses most of Alistair's concerns

    I've blogged a longer response, too: http://niksilver.com/2011/04/27/agile-ukgovit/

  • "Under Agile projects, you pay a given amount of money for a set amount of effort. But you can't guarantee a specified outcome for a specific price."

    That is true. It is equally true of the methods governments and others have used in the past, and of the methods recommended for government ICT today. It is true of all software development methods, past and present. Therefore, the statement does not distinguish between any two methods.

    "Agile implies that charges for time & materials should be open ended. Government departments won't accept that."

    That is true. Is it a problem with agile methods, or a problem with conventional bureaucratic thinking? Management approaches and development methods do not address the latter. Therefore, the statement does not distinguish between any two methods.

    "Agile can't give you a clear specification of outputs up-front. Nor can it give a definitive up-font price."

    That is not true. It is a question of how fixed-price proposals are structured, not a question of development methods or management practices. The clearly-specified outputs need not represent detailed descriptions of complete systems. There are other types of deliverables that can be specified, and that may in fact provide better alignment with customer needs than traditional ones. Therefore, the statement does not distinguish between any two methods.

    "Since Agile contracts lack clear contractual delivery obligations or remedies, how do you enforce properly? How do you recover loss or damage if there's a problem?"

    This is another issue that is a question of how contracts are structured, and not something that is connected with management or development methods. "Agile" as such is silent on the subject of how to structure contracts. Is the government's intention to enter into contracts that cannot be satisfied, so that they can make money by suing the software suppliers, or is it their intention to obtain useful software solutions to support government services?

    "Agile makes it hard to apportion blame because the customer is intimately involved in the work."

    That is not true. Intimate customer involvement makes it quite easy to apportion blame, although the finger of blame may not point in a direction the customers would prefer.

    "It is inevitable that Agile decisions will go through management hierarchies in central government. This will be like kryptonite to Agile projects."

    That is not true. Central management of large-scale programs that use agile methods where they are appropriate (and other methods where those are appropriate) is a very common pattern in the US Department of Defense, NASA, and other government agencies and government contractors.

    "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth." - Sir A. C. Doyle.

    If we take Sir Arthur's quote to heart, then we must ask how the author could have reached the conclusions he shares in the article. All his comments about "agile" are either (a) false, or (b) true and irrelevant. Let us see if we can discover how this can be so.

    The author is a lawyer. To become a lawyer, one must complete a long and arduous educational program and pass a rigorous examination. Therefore, it is not credible that a qualified lawyer could be lacking in basic intelligence or reasoning skills.

    It follows, then, that the author does not believe the nonsense he has written here. What remains, no matter how improbable? The author is employed by the very government in question. Government officials may have good reason not to desire transparency in their work. The author, then, may have been directed (or may have understood it was expected) to discredit "agile" by any means necessary.

  • I broadly agree with this article. It's clear to me the mismatch in social capital culture between government and the conditions under which Agile is designed to work.

    However, the article assumes that government is an immovable object and that policy set in law (that is currently "legal") cannot be changed. Perhaps this is valid in a 1 to 4 year timeframe but the assumption that it is immovable is depressing and apathetic.

    Rob Knight's comment quoting DeMarco is correct. Managing cost is most relevant where the payoff is closely matched to the cost. Most IT projects have massive asymmetric payoffs. It is better to manage schedule and scope and to launch early in order to realize the opportunity "costs" of delay. Recognizing greater benefit early.

    What this article does well is demonstrate that current government procurement procedures and governance are unsuitable for managing IT projects on behalf of tax payers.

    It would be better to advocate for this change. It is this advocacy that serves the public, the taxpayers and the country best. Simply advocating for the status quo and creating conservative inertia around a known failed model by stating "the alternative is also flawed" serves no one.

    Regards,
    David
    http://www.djandersonassociates.com/

  • Greetings Mr Ballard,

    "But it won't work in government IT. It won't work in the real world."

    I'm thankful you've taken the care to separate 'government' from 'the real world.'

    "But my job is the help create successful projects."

    It's tough to help create successful projects, in any case, and particularly so if you struggle the create successful sentences, and then set such flawed statements into stone. Rigid, unyielding specifications are one part of the reason why modern government (and its by-products, including software) is such a joke.

    "I've seen too many projects flounder for a lack of trust between customer and supplier to think the answer to government's ICT problems is the Agile credo of, 'Let's trust each other some more.'"

    Again, thank you Mr Ballard for pointing out something very important. Trust and government are two things that can never go together. And when you throw Corporate Lawyers deigning to be Richard Dawkins into the mix, Trust truly becomes a dirty word.

    You're right, Mr Ballard, agile software development is not for your ilk.

    Regards,
    Jeff L.

  • Of course, continuing to use old-style contracts won't work with lean & agile approaches (of course, they mostly don't result in the desired outcomes anyway).

    Hence, the move toward outcome-based agreements, predicated on output-based pricing regimes. These aren't new. They've been used for over 15 years to my knowledge. But they may be unfamiliar to specific individuals, naturally.

    An 'agile contract' does not have to be an agreement to buy a certain amount of effort at an agreed price. That's not agile. That's 'time & materials'.

    I shall be more than happy to enter into a public debate regarding how executives can derive value by applying lean thinking and agile practices. Whether you're in the private or the public sector.

    Best regards,
    Grant (PG) Rule

  • Waterfall definitely doesn't work. In fact, the original description of waterfall was misread by most people - the author's intention was to show that it couldn't work and an iterative approach is needed. For a discussion of this see http://pascal.gugenberger.net/thoughts/waterfall-accident.html (this also has a link to the original article).

    This article attacks a caricature and says it won't work. That's fine - it's a caricature. Put bread under grill, pull out when on fire, put it out, scrape to desired colour. It's a repeatable process that you could certify, but not how you make toast.

    You can estimate anything if you know what you're doing - you can create large stories with some caveats and make it work. I also know that, agile has been used very successfully in government projects by Valtech, see my blog post http://www.pharmarketeer.com/2010/05/16/agilenorth.html#agile-in-waterfall-case-studies from last year's Agile North.

    In short, the article starts from a position of ignorance, creates an Aunt Sally, and sows confusion.

  • Greetings Mr Langr

    I wouldn't want to discredit such a stimulating report as this one by giving the impression that I would distance myself from it.

    Neither would I want to take credit for writing such an insightful article where the credit is not mine to take.

    The author is nevertheless not myself but the esteemed lawyer, Alistair Maughan.

    Our rather old-fashioned CMS means Alistair gets a standfirst, while I get the byline and an unfair portion of reflected glory.

    Regards

    Mark Ballard.

  • Mark, Alistair

    Change is coming. The government has made a public statement that they will use "Agile". It means they will need to at least try to adopt Agile. Part of that process will be a realisation that they may need to change their investment and decision processes. This MAY result in failure if the government continues with its existing practices without adapting.

    I suspect that the government IT will try hard to make Agile work because a climbdown based on "We cannot change" would be a indictment of the government, especially as the public sector and American Government IT has made it work.

    On that basis, there is a golden opportunity for experienced Lawyers like yourself to establish themselves in new forms of Agile Contract. We can introduce you to the group of Lawyers in the US who have a few years head start on structuring Agile contracts.

    If you are interested, you may wish to join the London Agile Community on 17th May when we gather to discuss how we can best help the Government achieve its goals. ( Details of the event are here. --> http://xpday-london.editme.com/XTC20110517 )

    I hope to see you there.

    Chris

  • Greetings Mr Ballard,

    My sincere apologies. I should take care to read both top and bottom attributions.

    Regards,
    Jeff

  • "I wouldn't want to discredit such a stimulating report as this one by giving the impression that I would distance myself from it.

    "Neither would I want to take credit for writing such an insightful article where the credit is not mine to take."

    The depth of misunderstanding demonstrated by those comments defies imagination. Therefore, it must not be imaginary.

    Given that ignorance has a simple and inexpensive cure, it never fails to amaze me when people take pride in it.

    You will doubtless get what you wish for in government IT procurement. No whinging, please, when you discover what it really means for the quality and cost of government services.

  • "the final system only emerges gradually"

    This is true of ALL IT projects. The difference with iterative delivery is that you have the opportunity to assess and steer the out come early rather that waiting until the end to discover its all gone horribly wrong.

    "Agile makes it hard to apportion blame because the customer is intimately involved in the work. Since Agile contracts lack clear contractual delivery obligations or remedies, how do you enforce properly? How do you recover loss or damage if there's a problem?"

    Yes its true that agile focuses on heading off problems early when they are still small problems rather than waiting until the end when its too late and you need to find someoneelse to sue and hold accountable for your disaster.

    "I wouldn't want to be the first Permanent Secretary to admit before the PAC that his or her department has no real right of legal recovery from a failure."

    Being able to sue in the event of a failure wont turn that failure into success (except success for the lawyers maybe).

    "But Agile simply won't work in the real world [of government ICT]"

    Indeed you only have to look at the likes of google and microsoft ... if only they had people to sue instead wildly successful products and systems, I'm sure they would be much happier.

    "We need a Richard Dawkins to bust the myth of the Agile gospel"

    Right so you think that the worlds foremost thinker on evolution, someone who believes that viable ultra complex systems can only come about by gradual refinement, would be a proponent of upfront design and specification of hugely complex systems ?.

  • When I first started reading this, I wondered if it was some form of subtle irony. Then as I continued, I had the horrible growing realisation that you are serious.

    First: your use of the phrase "in the real world" is arrogant. We all live in the real world. You have no special access to reality that is denied to the rest of us.

    Second: What do most people think of when they consider government IT projects? Do they think of a project presciently planned out in minute detail, executed with vital precision and delivered to the delight and astonishment of the customer on time, to budget, with all of the original specification implemented exactly as documented?

    While the first of those steps might come to mind (minus the prescience), the rest, I suspect, will not. And by what method are all of these projects managed? I'll leave that piece of research as an exercise for the reader.

    So, while you can come up with two well known failures attributable to Agile Methods, I can come up with orders of magnitude more government IT project failures, each of which is attributable to whatever methods are currently used (including procurement, management, implementation, operations, etc.). The weight of evidence seems to be against you.

    Third: It is true that incremental, iterative and evolutionary methods are at the core of Agile Methods. Indeed, those methods have been successful in all sorts of engineering disciplines for a very long time, and are actually at last the DoD's preferred way (see Craig Larman's work in this area). But also at the core is working with the customer to come up with an effective way of working in the specific context. Let's forget about 'Agile Project Management' (which is significant mis-characterization of what Agile Methods are and which you assert is a 'fad') for the moment and focus on that core, shall we?

    Would you truly prefer not to see incremental growth (of the actual working system) towards the final solution?

    Would you truly prefer not to give the vast team of people working on the project every chance to adapt their approach based on experience they gain on this very project, by iterating over their process.

    And with respect to evolution, customers are not required to change their minds after each increment. If a customer *can* fully specify a massive initiative up front in microscopic detail, is certain that none of that detail will change over the course of a 10,000+ person year effort, and does not want to see incremental progress of actual working systems and adapt to the feedback they can get from this approach, then fine; let them stick with the original specification.

    Personally, I wouldn't trust the current methods used to be able to specify, cost up and go out and buy a pair of shoes for me without it resulting in massive costs to the tax payer, litigation that at least would keep you happy, and the subsequent need to have at least one of my feet amputated in order to make the ill-fitting delivery 'usable' without too many people losing face.

  • Okay. Breaking my silence on this temporarily.

    First of all, there's no such method as "waterfall software development". Seriously. When Winston Royce first wrote about the model in the early 1970's, he meant it as a cautionary tale of how NOT to develop software. Check the software engineering literature going back 40 years. We've been telling teams to iterate for as long as we've had development methods. And we've been telling teams to prioritise and to adapt for decades, too (because that's what "iterate" means).

    So "Agile" is a red herring here.

    The problem is one of trust, openness and willingness to work in real, honest productive partnerships. Once lwayers get involved, the trust is already gone and all is lost. So one wonders of this article's maybe written from the perspective of a sort of IT divorce lawyer who believes all IT partnerships should start with watertight prenuptial agreements setting out the rigid boundaries for the relationship, rather than that marriages should be built on trust, honesty and openness and that partners should adapt to changing circumstances and share both the risks and the rewards.

    What the article illustrates beautifully is why government is not really good marriage material.

  • I support agile development, but concede some of what is said here. Working in a company where people don't like to take responsibility and love to place blame, I can see how the gov't sector might have a problem with agile...

    The thing is, waterfall (mostly) doesn't work. To get agile to work, gov't will have to change its approach on IT project management.

  • I worked on a system that was downstream from the one EDS built for Sky and I can assure you, whatever the publicity, that it didn't look Agile. From what I remember, the court case turned on the untrustworthiness of the lead salesman. No Agile project I've worked on could run to completion without that sort of issue being raised and addressed earlier.

  • There is a lot here to discuss.. and this small margin does not even begin to handle. However, first I applaud the use of the word "outcome" as a measure of project success. This emphasizes the difference between (prioritized) requirements and the overall outcome of the project. And, of course, there are many ways to achieve a desired outcome, reflecting the flexibility in interpretation of requirements and in general the variation in project outputs which may lead to the same outcomes. Thus the project model that we start, implying totally fixed requirements leading to a defined outcome is generally false.
    Secondly, Agile suffers from its fair share of fundamentalists. Like PRINCE2, which has recently discovered that the Principles are more important than the details, Agile needs to be broken down into principles and applied to projects (tailoring) as needed. This is not much more than the application of commonsense. If parts of common Agile processes are inappropriate, then perhaps we should consider not using them. It took PRINCE2 a long time to mature into a tailorable system and I suspect that Agile needs to do the same. I agree with the correspondent who identified the black / white view of Agile as being in error. This is the one-size fits all approach and clearly this is incorrect.
    Thirdly, the benefits of Agile, particularly from the productivity aspect as well as project control are enormous. In fact given the benefits we should be actively seeking methods of making Agile work in all our projects as standard.
    Lastly, there are some types of project for which Agile is not particularly well suited. There is nothing to prevent us from using a traditional approach on those project portions (architecture for example) which need it and an Agile approach for the more loosely coupled sections. A previous correspondent has commented favorably on the gradual refinement brought about by evolutionary development. I don't quite buy this as an example. It is of course remarkable how much has been achieved, but from the point of view of maintenance, accessibility and enhancement, evolutionary development has not done so brilliantly. Speak to any surgeon.

  • Agile needs to be broken down into principles

    If only someone had done this ten years ago, they could have saved us a whole lot of grief!

  • Well then. No surprises in the original article or are there, especially coming from such an adversarial viewpoint? Was this an Aunt Sally? It had to happen at some point that the thorny issue of procurement law would be raised in total isolation of commonsense practice and behaviour, and in the spirit of always doing what always has been done thus nurturing a self perpetuating oligarchy where only the lawyers will see any benefit. Is it just me or are the two cited cases private sector and not public? I would have thought that if we were to be swayed by such evidence it ought to be high profile public sector disputes that we would be pointed to?
    To take a stance on the basis of mistrust is flawed and indicates a stereotypical view of how Government business should be undertaken. It is proper and long overdue that we had agile methods recognised as a way of doing business with the public sector. I have been both a customer and a supplier
    I am an ex-public servant who has worked in teams that have delivered highly successful agile projects using DSDM coupled with PRINCE2, and in the interests of being balanced, worked on a really bad ‘agile’ project that is currently stalled owing to procurement rules – note the ‘a’, but it still delivered a working product. In fact I learned my agile trade as a civil servant.
    In the past, for agile projects to work effectively in the public sector, it has required either a very brave or desperate project owner to recognise the only effective way of delivering some benefit for the public purse is to work collaboratively with suppliers and customers to broker a reasonable package of functionality/solution to meet the business need and no more.
    I moved from SSADM into RAD and DSDM. I still use some products from SSADM but nothing beats the satisfaction of seeing users with working products delivered on time and in some cases under budget that they helped engineer rather than yards of ‘shelfware’ with no working products. Yes we still need some traditional roles such as business analysts, technical architects etc. but above all we need trust and delegated authority to make decisions – good or bad, and the ability to take risks and learn from mistakes. Just how many departments are self-proficient in delivering information systems these days? Very few I think owing to successive administrations selling off those services so let’s step back and think differently and hey, break a few rules and see if it works but let’s not start from a viewpoint of who will be to blame if we get our trials wrong.
    Educate the procurement and legal teams to draft new services contracts (as opposed to the goods type contracts) and we might just start to break ground.
    It had to be an Aunt Sally.

  • Hi Rob,

    thanks for the bit about Agile Principles. My problem with all of this is that when someone argues about Agile I am never sure which particular flavor of Agile is intended. Also, with respect, the principles as listed are not the most meaningful... there are many ways to approach Agile... and is it still Agile if one or more of the principles are dropped? PRINCE is explicit about this, Agile less so. The Agile principles are an extract of common Best Practice and many of course can be used in Waterfall (If you must use Waterfall). Waterfall avoidance would be a good extra principle.
    I think the article, coming from a lawyer, is written from the perspective of "could I sue successfully". I suspect that Agile, with its more dynamic environment would make it harder to define a clear case. Regarding Agile definition, I feel that the content as set out in http://www.pmi.org/~/media/Files/PDF/Agile/PMI000-GainInsightsAIGLE418.ashx reading list is pretty good.. but is that what is meant in this discussion on Agile?

    In the real world, lip service is paid to much of the Agile principles. In 2009 Scott Ambler published a survey of adoption of Agile Practices at http://www.ambysoft.com/surveys/practices2009.html
    It agrees with intuitive gut-feel on real-world projects and I think brings more light and less heat to the discussion on Agile

  • As you say, the scope of the work is variable. The author's arguments fit well with that; the customer wants given functionality for a given price. If a developer needs to agree a restriction in scope in order to meet timetables then they're not getting what they wanted. The way for them to get what they want under those circumstances is to extend the project and increase the cost but to a relatively unknown extent. Over the last 6 years of my 24 year career in software development I've been involved in trying out agile processes in customer funded development and, so far, I'm of pretty much the same opinion as the author. In those 6 years I've seen no evidence that agile processes and customer funded development are compatible.

  • Another black and white view of a complex subject; some valid points, some not. Neither waterfall/Gateway nor agile procesess are all good or all bad. The trick will be to take the best of all worlds. Consider this. Central Government has huge purchasing power for IT systems. It ought to be getting the best VFM in the market – just like Tesco drives down the prices it pays to it suppliers. Government employs talented lawyers to draw up tight contracts. The result? (I don’t need to elaborate, surely) Government is continuously taken to the cleaners. Lawyers are part of the problem; they need as much education as anyone to become part of the solution.

    Charles Symons

  • You say: Under Agile projects, you pay a given amount of money for a set amount of effort. But you can't guarantee a specified outcome for a specific price.

    However, it is abundantly clear that this a fact regardless of the methodology that you choose. There are numerous government cost overruns that we could choose to mention that demonstrate this very easily. HMRC has enough IT disasters under its belt that I'm sure you are aware of.

    With a typical fixed scope fixed price contract there is a lot of "discussion" between government purchaser and IT vendor to come to an arrangement of agreement that the delivery meets the initial scope requirements. Nobody in government wants to have backed a loser, so its best if the system is agreed to have met its scope. Once this has happened, then a number of expensive change requests are put through to change the system into one that is deployable. These change requests are often budgeted separately, so its harder to see the true cost of the system. (as they can be made to fit under the OJEU mandatory disclosure limits)

    An agile approach makes it explicit that the scope at the start of the project is really more of an expression of intent, and it makes those "change requests" part of the system, so that at any point you can change your mind about features and their priority.

    Additionally, as one of the main principles of an agile development process is that you have a production ready system at all times (although, clearly with limited scope), it is possible to stop the programme at any time with working software, or indeed to simply change your mind about the entire piece of work and call a halt.

    The OJEU procurement process is a major part of the problem here, as it expects scope and price and time all locked down up front - which we know from experience is problematic.

  • Mr Maughan makes a point, but not the one he thinks he is making.

    The real point IS that the way Government is organised to work to deliver public services is not conducive to an agile approach.

    Agile will never work in the current way UK Govt projects are considered, proposed, funded and implemented. That is a lot of stuff that needs to adapt also.

    From the lack of vision for projects (how can you have sustained long term vision when politicians are looking for short term popular wins).

    Nevermind the backroom deals that happen between Lord This of Department A and Lord That of Big 5 Consultancy, that continue to find shoulders to bear blame rather than partners to realise value.

    Agile is the least of your worries.

  • I love these provocative blogposts! Nice job!
    The only thing I wish to add to the discussion is this:
    "Is it fair to label Agile projects as failed when all they did was surface issues much more quicker than in a traditional approach? And thereby save tons of money that would otherwise be wasted?"

  • Dang. Not buying it.

  • "Agile makes it hard to apportion blame"
    I believe this is the core of your argument. In a fear-based culture such as you describe (perhaps even promote) Agile won't work. Yours is a self-fulfilling prophecy.

  • Nick Oostvogels raises an excellent point. That's really what this is all about: failure. And the UK government has seen more than it's fair share of that where IT is concerned. Whatever they're currently doing, it demonstrably isn't working.

    Creating systems iteratively and incrementally, with short feedback cycles, just uncovers the problems much earlier. There is never a situation where not seeking that feedback makes the problems magically disappear.

    This blog post isn't about succeeding at delivering useful working systems. It's about limiting the impact of inevitable failure.

    I worked with a developer once who devoted most of his time to making sure when we failed he wouldn't get any of the blame. He was absolutely horrified when he realised we were actually setting out to succeed. He now works in the public sector, and is thriving.

  • Maybe this snippet is at the heart of the issue here:

    "You can have an ICT project with a watertight contract, clear deliverables, openly and legally procured, with a fixed price and appropriate remedies if you don't get what you want".

    No contract that I've seen works like this. There may be remedies of you don't get what you ask for, but that's rarely what you want.

    If the system can be adequately defined up front, (eg in requirements), then a traditional delivery is probably the lowest cost and risk approach. However, IT systems are rarely like this. New builds are mostly an exploration and R&D exercise, rather than a manufacturing to a well defined engineering specification.

    The assumption that the requirements are known, complete and accurate upfront was the weakness that EDS exploited so well: bidding low and then winding up the costs on change control. That's not a sensible approach to managing the risks.

    Even on what ought to be very simple IT projects: running existing systems, the contracts ensure that there is a zero sum game leading to huge wastage, which is rarely confirmed after the event.

    Most govt. IT projects should look more like service contracts with simple, low cost switching, and the IT service contracts should be more project like with clear deliverables and acceptance criteria based on value for money.

  • So, "Agile development is an evangelical fad ill-suited to government IT" is it? Well, as a director of the DSDM Consortium I am delighted to say that for DSDM at least this 'fad' has now lasted well over 15 years and, during that time, has even been used successfully in government IT.

    I support the many sentiments expressed by others seemingly stunned by the magnitude of the ignorance presented in the leading article. It is simply riddled with false statements and assertions that would not stand up to even the most cursory research.

    It is true to say that I have seen some very poorly controlled Agile projects in my time. I have also seen the ill-discipline of those projects being fraudulently passed of as ‘the way it is with Agile’. I can only assume that Messrs Maughan and/or Ballard have experienced this ‘cowboy’ agility and been suckered by the ‘that’s the way it is’ fob off.

    DSDM Atern includes a clearly defined Foundations phase which considers, but avoids the detail of, business need and process, technical architecture and delivery approach, timelines and the precise way the project will be configured for success.

    It has a set of 10 core roles each with clearly defined responsibilities. It is more complex than the role sets of other Agile approaches and for some smaller organisations running simpler projects it might be seen as over-kill but for large projects in complex environments such as those often a reality in government it is ideal.

    It has a set of 5 core practices with MoSCoW Prioritisation and Timeboxing heading the charge in making a fixed time, fixed cost, fixed quality expectation for a project a reality. Iterative Development supported where appropriate by Modelling and Facilitated Workshops ensure that the right solution with the optimum value is delivered within these constraints.

    There will certainly be challenges associated with making Agility in government a reality and I think the concept of appropriate empowerment will be the first of many but even here the DSDM Atern roles and practices are designed to help smooth the path.

    I am certain that if you use DSDM Atern as the basis for it, you can indeed have an ICT project with a watertight contract, clear deliverables, openly and legally procured, with a fixed price and appropriate remedies if agreed deliverables are not delivered. AND you can have an Agile project. Yes you CAN have both.

    Andrew Craddock
    Technical Director
    DSDM Consortium

  • I don’t actually think Waterfall is the best idea since sliced bread, nor that Agile is the worst idea since the Sinclair C5.

    But I really do believe the public sector environment leaves Agile little chance of being adopted properly, let alone applied widely.

    Most of the comments here address my description of Agile "in 50 words or less". But they mostly sidestep the main thrust of my argument.

    I'm not the first to point out the issues that proponents of Agile in Government will face. The System Error report from the Institute of Government recognized some of the same issues.

    Let me turn what I said on its head and see if that makes people happier. Here goes: Agile will make Government ICT projects generally more successful:

    • If someone can work out how to make Agile work within the scope of the EU-mandated procurement regime. The EU and courts are tightening up the procurement regime. It’s now easier than ever for losing bidders to challenge procurement awards – and they are doing so. I hope we never get to the level of pervasive bid protests like in the U.S. But departments are consequently seeking more up-front certainty and less flexibility. Marrying current procurement requirements with Agile is like trying to swim 100m with both hands tied together.

    • If government ICT projects are exempted from the Freedom of Information Act. Knowing that every written document could be disclosed makes project teams cautious. They will be wary of saying or doing anything that might look bad, so they’re wary to “get involved” in the way Agile requires.

    • If government conducts a massive training exercise (and probably recruitment as well) to ensure that project teams can make Agile work with suppliers. That’s tricky because departments are facing pressure to reduce head-counts. They will have to make do with smaller retained project management teams.

    • If departments are empowered to be flexible and iterative. As opposed to being less empowered by the further centralization of ICT governance within government.

    • If every penny a department proposes to spend over the next year isn’t scrutinized to death; and required to be accounted up-front.

    • If project teams are freed from the fear of failure. Try telling departments not to worry about reserving a right to claim if something goes wrong. Lawyers aren't the problem here. Departments don't doubt they'll be in even more trouble without them. Don't forget the baying media, the hyper-critical Parliamentary Accounts Committee, and the National Audit Office.

    My next article should consider how ICT projects could run a damn sight better outside of procurement rules, the media, Ministerial and Parliamentary scrutiny and without HM Treasury or Cabinet Office approval. (I joke, but not much.)

    Project staff should be allowed to work without fear of procurement challenge, public humiliation and the blame culture that seems to come with major public sector projects. If that changes, Agile in Government may blossom. Sadly, there’s no chance of that happening, but it's a nice thought.

  • Waterfall was never a valid development methodology. The paper that introduced it, Winston Royce's "Managing the Development of Large Software Systems" (1970) only did so to decry it in favour of iterative development.

    Software development costs cannot be predicted accurately. The practice of bidding for contracts is entirely separate from costs in such a case. The development firm is gambling that it can develop such a system and profit.

    Agile bidding for contracts? You made that up. Agile is a software development process (More correctly a property of some software development processes.) To put in other places is ill advised and ad-hoc.

    Government then needs to accept what software development is. Software projects are never delivered. Maintenance will always cost, and changes will always be needed. Agile processes accept this from day one, Waterfall never faces this reality.


  • Given the author's assumptions, I don't disagree. The way contracting in Government IT happens today, it would be a poor fit.

    I think things could change there - and that Government IT should first experiment with their non-contracting staff that is successful at delivering USEFUL IT first, and see the benefits as well as the downfalls.

  • Mr Maughan, I rather wish you'd have written this

    "I really do believe the public sector environment leaves Agile little chance of being adopted properly, let alone applied widely."

    rather than this

    "The Cabinet Office expects Agile will reduce the risk of ICT project failure. It's a nice idea in theory. But it won't work in government IT. It won't work in the real world."

    in the opening of your article. The former evokes a much fairer, more objective view of the situation. I imagine the obstacles to cost-effective, results-oriented software delivery in the Canadian government match quite well with those in the British government, and compatibility with the broadly agile approach would more likely mean that we had something closer to the government we generally wish we had.

  • Hybrid Agile models can work and has worked very successfully for us with a large government project.
    It worked liked this:

    First the project was broken down to two phases, Business analysis and development. There was a fixed price for both BA and development. In BA we did upfront use case analysis to create an accurate spec and quote for the development phase, but this could have been tendered for and performed by another party.

    For development we used a version of SCRUM. It was clear what was getting created but as others have pointed out it wasn't determined upfront how the functionality would be developed and when, just what the final cost was, and the number and length of the iterations. Progress payments were tied to the delivering each iteration however the success criteria for the progress payments was only determined when the contents of the iteration was determined at the beginning of that iteration, ie it was semi-dynamic user acceptance criteria.
    In the end the scope of the project didn't change that much and when it did it was dealt with how it would in a normal fixed price contract, as a variation to the contract. The real advantage however was those variations were discovered much earlier and in many cases didn't result in increased cost to the customer as almost as many stories were discarded as were added. Fixed price waterfall models have equal chance of changing scope and all changes to scope will require contract variations and those variations result in more money being paid. The agile model above gave us the flexibility remove functionality the customer didn't need and replace it with functionality they did need.

    There is a presentation on some aspects of this job but most of the focus of this presentation was on the way we combined usecase analysis with functional test driven development

    http://www.slideshare.net/djay/test-browser-driven-development
    http://www.ustream.tv/recorded/2445994

  • Stick to being a lawyer. A methodologist you are not. Also, for future reference, agile is a verb, not a noun. Nor does it have a capital 'a'. Think I'm being picky? That mistake is behind most perceived failures of agile methods.

  • Like J. B. Rainsberger, I wish your lead article had focussed on the obstacles to proper adoption of Agile, which are formidable, instead of saying it's Agile that will fail. I also think it's a little disingenuous to suggest the credo of Agile is "let's all trust each other some more" or that Richard Dawkins should be summoned to slay the beast. Actually I think Richard Dawkins, author of the Blind Watchmaker, might have had some sympathy with Agile credo but that's another debate.

    To put the glove firmly on the other foot would be to point the finger and the "traditional contract". You can find out more by taking a look at Traditional contracts are doomed.

    First, the watertight contract of which you speak is not the solution to GovIT's problem if GovIT's problem is that it cannot reasonably be expected to possess the 20/20 foresight required to see exactly what it is that it wants, over the protracted time-scale, and in the changing political-economic climate of public sector procurement. When it goes wrong the expectation to deliver anything evaporates and this serves no one very well. It's not that the opportunity to decide what you want is too much to ask, or the right to be upset if you don't get it too much to expect but why does all of this have to be decided up front?

    Secondly, to return to the matter of trust for a moment: trust is not an arrangement that can be prescribed in a contract and equated to remedies. It has to be earned, generally by behaving reasonably, demonstrating competence and fulfilling commitments. The aims of Agile delivery are amongst other things to discuss openly, agree reasonably and deliver consistently; on time and with quality. A contract that recognises these principles, focussed on capability to deliver not the product to be delivered would surely lead to a better solution when it succeeds and more satisfactory remedy if it fails.

  • Can you elaborate on how one can deliver fixed budget project using Agile.

    Thanks

  • Have you ever run an agile project? or just read the books and heard about how it can be done badly?

    There is a fundamental that you avoid completely in your argument.

    There is no reason why an agile project can't give a fixed price up front - the wording of the contract just needs to be altered to account for the different approach.

    The main reason why government projects (and similar sized private sector projects) fail is because they take so long to deliver that they need to change to meet changing policies and strategies that are a natural part of life during the project lifetime.

    Agile fixes this in 2 ways

    - it seeks to deliver requirements in priority order rather than all at once thus ensuring that value and therefore ROI is realised before the end of the project - this tends to help financial controllers to offset the ongoing project costs.

    - as requirements are prioritised they are delivered just in time and therefore are less subject to changing policy

  • The fact that agile does not give a guarantee of delivering the scope required is not an artifact or limitation of the methodology, but the recognition that given three parameters - time, money and scope - you can't fix all three. If you want to fix time and scope, you are quite probably sure to blow your money estimate by a large margin. Is this really better for a government agency?

  • In most (all?) IT projects, the requirements can be prioritized. Whereas there are requirements which it is imperative to meet, there are also 'nice-to-haves' and less core requirements. Furthermore, in the real world these priorities can change under our feet during the development process – whether we like it or not.

    With most entirely fixed-price, conventional procurements, the vendor is obliged to meet all requirements - and therefore builds-in some contingency to cover (for example) unexpected complications and change management. Often, this contingency is not fully used - so the customer has essentially paid a risk premium (essentially for both parties being unduly constrained).

    It is entirely possible to use an agile approach where the vendor/customer collaborate in the on-going decision-making process regarding priorities and risk throughout the project – not just at the outset. Properly managed, the imperative business requirements WILL be met - and (probably) a subset of the 'nice-to-haves' also. The vendor doesn't need to build-in contingency - the hourly-rate per unit effort can therefore be lower.

    This of course requires reasonably intense on-going collaboration, a good working relationship between the customer and vendor, and a mutual understanding of the sensitivities on both sides.

    I believe that all too often, 'Agile' is misunderstood as 'Random'. This is not the case - a successful agile engagement still requires rigor to ensure a favourable outcome. But done right, I have seen it work well.

  • Speaking as a developer that's spent a successful 20 years of her career in the Private Sector developing over 40 systems, and a painful 18 months in the Public Sector driving through a single national IT system for the Police, I can say with some degree of confidence that the problem with Public Sector IT projects is how badly they are managed, not what particular methodology they happen to use. Effective software development is about people, not processes. Even the 'cowboy coding' approach (code monkeys talking to end users, then designing systems based on what they netally perceive the needs of those users are without ever documenting the proposed design in advance) works better in some circumstances than does either Agile or Waterfall, provided you have the right developers driving the keyboards and the right expert users providing guidance.

    However, if you insist, as the Public Sector uniformly do, on managing your projects with people whose only qualification for the job is a Prince 2 certificate that they got by going on a two week course, or if you select your middle technical management by whichever colour badge the ITIL foundation are handing out this week for their version of that same two-week course, don't be surprised when two very obviously and foreseeable things happen in quick succession:

    1) You don't get the work done that you had expected, because of all the mind-boggling bad decisions your grossly-unqualified Rainbow-Badged Prince 2 Managers make.

    2) All of the IT professionals and niche domain experts in whichever task you've managed into failure wont work with you again in the future, leaving you with bloated, under-skilled, overly-expensive suppliers like Capita (whom Private Eye with good reason calls "Crapita") as your only option for getting work done in future.

    In the case of the national IT system I worked up, 80% of the developers left at the end of the project, and the vast majority of expert police officers that had been seconded from front line police work onto the project team couldn’t get back to doing their day jobs quick enough. They had no trouble retaining the project managers that both of those parties had been forced to work with for those painful 18 months.

    There's a reason that projects like the national identity card scheme, the Scope 2 intelligence system, and the national NHS database fail, and that reason can be summed up in two short sentences: "Prince 2" and "ITIL".

  • Speaking as a developer that's spent a successful 20 years of their career in the Private Sector developing over 40 systems, and a painful 18 months in the Public Sector driving through a single national IT system for the Police, I can say with some degree of confidence that the problem with Public Sector IT projects is how badly they are managed, not what particular methodology they happen to use. Effective software development is about people, not processes. Even the 'cowboy coding' approach (code monkeys talking to end users, then designing systems based on what they mentally perceive as the needs of those users without ever documenting the proposed design in advance) works better in some circumstances than does either Agile or Waterfall, provided you have the right developers driving the keyboards and the right expert users providing input and guidance.

    However, if you insist, as the Public Sector uniformly does, on managing your projects with people whose only qualification for the job is a Prince 2 certificate that they got by going on a two week course, or if you select your technical management by whichever colour badge the ITIL foundation are handing out this week for their version of that same two-week course, don't be surprised when two very obviously and foreseeable things happen in quick succession:

    1) You don't get the work done that you had expected, because of all the mind-boggling bad decisions that your grossly-unqualified Rainbow-Badged Prince 2 Managers make.

    2) All of the IT professionals and niche domain experts in whichever task you've managed into failure wont work with you again in the future, leaving you with bloated, under-skilled, overly-expensive suppliers like Capita (whom Private Eye with good reason calls "Crapita") as your only option for getting IT projects done in the future.

    In the case of the national IT system I worked on, 80-90% of the developers, DBAs and technical staff left at the end of the project, never to return. The vast majority of expert police officers that had been seconded from front line police work onto the project team also couldn’t get back to doing their day jobs quick enough. The organisation concerned had no trouble retaining the project managers and business analysts who knew nothing about either coding or being a police officer, whom the technical staff and police officers had been forced to work with for those painful 18 months.

    There's a reason that projects like the national identity card scheme, the Scope 2 intelligence-sharing system, and the NHS national patient database fail, and that reason can be summed up in very two short sentences: "Prince 2" and "ITIL".

  • Agile methodology is a stable approach while project is being developed and simultaneously testing is in process of each newly deployed build. Using Agile Methodology, all the members involved with the project would get appropriate fruitful result in terms of project deadline, quality and cost. This is more beneficial for in house projects where developer and tester are working together to save cost and time.

  • Leave a comment

    Subscribe to blog feed

    Archives

    -- Advertisement --