back to article 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 …

Page:

  1. This post has been deleted by its author

    1. AMBxx Silver badge

      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.

      1. Anonymous Coward
        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"?

      2. Oh Homer
        Headmaster

        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.

    2. oldtaku Silver badge

      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.

      1. 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.

        1. breakfast Silver badge

          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.

          1. 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'

      2. 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'...).

        1. Doctor Syntax Silver badge

          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.

      3. Doctor Syntax Silver badge

        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.

      4. 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.

        1. FozzyBear
          Alien

          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.

      5. Dagg Silver badge
        Mushroom

        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!

    3. Steve Davies 3 Silver badge

      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

      1. Prst. V.Jeltz Silver badge

        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

        1. Anonymous Coward
          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!!

        2. Doctor Syntax Silver badge

          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.

        3. Anonymous Coward
          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".

    4. Prst. V.Jeltz Silver badge

      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

      1. 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.

  2. Lost In Clouds of Data
    FAIL

    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.

  3. oldtaku Silver badge
    Mushroom

    '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.

    1. 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...

    2. Dagg Silver badge
      Unhappy

      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.

      1. Anonymous Coward
        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....

        1. Dagg Silver badge
          Thumb Down

          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.

  4. 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.

  5. 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.

    1. 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.

    2. Doctor Syntax Silver badge

      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?

      1. 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.

        1. Anonymous Coward
          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.

        2. Anonymous Coward
          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.

  6. 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/

  7. Anonymous Coward
    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.

    1. 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)?

      1. Alister

        Re: If you aren't making mistakes in IT

        @BebopWeBop

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

    2. 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.

  8. 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.

    1. Anonymous Coward
      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?

      1. Anonymous Coward
        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....

    2. Dan 55 Silver badge
      FAIL

      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.

    3. 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

      1. 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.

    4. Charlie Clark Silver badge

      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.

      1. 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 ;-)

  9. Anonymous Coward
    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.

    1. 1Rafayal

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

      what, you mean just like every other methodology?

      1. Anonymous Coward
        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.

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like