Slashdot Mirror

← Back to Stories (view on slashdot.org)

FBI's Troubled Sentinel Project Delayed Again

Posted by Unknown on from the project-delays-cost-american-lives dept.

gManZboy writes "The FBI's Sentinel project, a digital case-management system meant to replace outdated, paper-based processes, has been delayed again. The FBI's CIO and CTO bet big on using agile development to hasten the project's completion. But now performance issues have arisen in testing and deployment has been pushed out to May. It's the latest in a series of delays to build a replacement for the FBI's 17-year-old Automated Case Support system. In 2006, the FBI awarded Lockheed Martin a $305 million contract to lead development of Sentinel, but it took back control of the project in September 2010 amid delays and cost overruns. At the time, the FBI said it would finish Sentinel within 12 months, using agile development strategies."

19 of 96 comments (clear)

  1. the glass is half... by alphatel · · Score: 3, Funny

    Which is worse, that the FBI waited 4 years to kick Lockheed off the project or that the FBI has regained control of unfinished software?

    --
    When the foot seeks the place of the head, the line is crossed. Know your place. Keep your place. Be a shoe.
    1. Re:the glass is half... by Jah-Wren+Ryel · · Score: 4, Funny

      Which is worse, that the FBI waited 4 years to kick Lockheed off the project or that the FBI has regained control of unfinished software?

      The worst is the realisation that the only thing saving us from law-enforcement totalitarian nirvana is institutional incompetence.
      If they ever really get their shit together we are so screwed.

      --
      When information is power, privacy is freedom.
    2. Re:the glass is half... by man_of_mr_e · · Score: 2

      I think it's pretty damn impressive that they were able to finish the main functionality, and only need performance tuning in only a year.

      This should be celebrated, not mocked.

      --
      If you need web hosting, you could do worse than here
  2. Re:They probably wrote it in Java by alphatel · · Score: 4, Funny

    Okay I turned it off. Chrome is working much bet.,,>.,>>

    --
    When the foot seeks the place of the head, the line is crossed. Know your place. Keep your place. Be a shoe.
  3. Agile strikes again! by viperidaenz · · Score: 3, Insightful

    Funny that, building software in small pieces and slapping them together doesn't while trying to shoe-horn in new functionality doesn't help you create a scalable system and meet all the non functional requirements.

    Disclaimer: Working along side an agile project with a 7 month "build phase" that is currently 15 months in and still hasn't delivered anything.

    1. Re:Agile strikes again! by Surt · · Score: 4, Informative

      Kind of missing the point of agile if you're 15 months in and haven't delivered anything. I mean, you can call it agile (you could also call it waterfall), but if you're not following agile practices, don't blame agile for the failure.

      --
      "Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
    2. Re:Agile strikes again! by Darinbob · · Score: 4, Insightful

      I think most Agile projects don't really do it the right way, if there is such a thing. People use it as a magic bullet. They're never "behind" in a project as long as the sprints are done on time. There's a whole cottage industry of Agile consultants who go out and get paid to screw up your company for you.

    3. Re:Agile strikes again! by viperidaenz · · Score: 2
      The project I ran on the side was on time and only slightly over budget. It was a smaller project but it was developed as 3 separate "water-fall" releases of around 3 months each. 2 week sprints is not enough time to build the large parts or a complex piece of software. The second 3 month development was mostly taken up re-writing the core of the first release to make it easier to enhance.

      The only place I see the "2 week sprint" agile working is for trivial enhancements to an already well written piece of software.

    4. Re:Agile strikes again! by viperidaenz · · Score: 4, Insightful
      What they've build is a hodge podge of pieces that have been built against half finished other pieces since they dropped everything at the end of 2 weeks and started the next sprint with their waste-of-time planning sessions where they spend half a day pulling numbers out their ass to estimate the build length of a story of less than 10 words. Every time they fix a bug in one place they uncover/create another one somewhere else. This isn't how open source works.

      I've failed to find any Agile success story for a large project. All I find is marketing hype and buzzwords from vendors selling Agile training and mentoring services.

      Agile is no silver bullet or golden hammer. It all seems a bit more like the Emperors New Clothes to me.

    5. Re:Agile strikes again! by Jane+Q.+Public · · Score: 2

      "2 week sprints is not enough time to build the large parts or a complex piece of software. The second 3 month development was mostly taken up re-writing the core of the first release to make it easier to enhance. The only place I see the "2 week sprint" agile working is for trivial enhancements to an already well written piece of software."

      Then you don't understand how Agile is supposed to work.

      Admittedly, there should be some amount of basic architecture roughly hashed out before a project starts. (No, I'm not talking waterfall, just a basic grasp of the big picture.)

      Then management (if they know what they are doing), come up with "stories". So far, so good. But it appears that your stories were not conceived at the proper scale.

      If a story is too large, then it needs to be broken down into smaller stories that CAN be performed in one iteration ("sprint" if you're doing Scrum). If they weren't, then your stories were not created properly.

      Part of the purpose for your once-per-iteration meetings (or "standups", or whatever you call them), is to determine your velocity (stories the team completes in one iteration). If your velocity is too low, or even -- Grid forbid -- less than 1, then your stories are too big. It is as simple as that. It is then up to management to refactor their stories. Period.

      Different groups do it different ways, but one good rule of thumb is to shoot for a velocity of at least one story per person per iteration.

      It is ALWAYS possible to break a story into sub-stories if necessary, all the way down to individual lines of code. It doesn't matter whether your iteration is 2 weeks long or 2 days. If stories don't get completed, the stories are too big.

      What you are telling us is not that there is anything wrong with Agile practices, but that somebody there did not know how to do it right.

    6. Re:Agile strikes again! by sjames · · Score: 4, Insightful

      Like most such management fads, it is an attempt to capture the success of existing teams. The problem is, the successful teams were employing a great deal of experience and common sense in a flexible manner. That is, their one rule was "do the right thing". When you have an experienced and conscientious team that knows what "the right thing" is, and a management that's smart enough to stay out of their way, magic happens.

      Alas, at the same time it gets a marketing name stamped on it, it is cast into a series of inflexible rules and chopped into sound bites for managers to spew back later. Rather than staying out of the way, management pesters incessantly to make sure everyone is doing exactly 'flavor of the week' exactly as they (mis-)interpret it. Nobody is even thinking about doing 'the right thing', they're too busy playing language lawyer with the magic juju manual that defines 'flavor of the week'. Meanwhile, the whole team forgets that 'flavor of the week' isn't actually the deliverable, it is supposedly just a means to get to the deliverable.

      In it's most extreme form, a team infected with 'flavor of the week'-ism begins to eerily resemble a creepy cult complete with special meanings loaded onto common words and phrases and reverence to the leader (author of the book/consultant) and a group blindness for the whole herd of elephants in the room.

    7. Re:Agile strikes again! by Serious+Callers+Only · · Score: 2

      I'm not really sure I understand why one would expect to program without a game plan

      It's quite possible to mess up both agile and more traditional styles of development - obviously neither approach is a magic bullet which will transform a bad team/product into a good one.

      To address your specific concern above, agile is a response to some obvious failures of the top-down model - sometimes it's very hard to pin down requirements in advance, or they simply change because of external factors, or the wrong people are asked for requirements, which doesn't become clear till the software is delivered after a long period of work isolated from use, broken as designed. That means trying to plan everything in advance doesn't always work, and *sometimes*, with the right team, it's easier to start with a basic app which works well in a very simple way, and then build up layers of features as you decide which things are actually important to your users.

      Now in some cases it's easy to define all requirements in advance, the use-cases are very simple, the users few and clear on what they want, and an agile approach is not really required, in others with lots of potential users/use-cases sometimes it's better to start small and work up to something bigger, or there's a danger you'll never finish.

      Of course this can go horribly wrong if you use it as an excuse to never properly define requirements, never solicit proper feedback from users, or to just hack up any old thing and call it finished. There is no system which can deal with bad attitude, lack of effort or incompetence, and there are many ways to mess up every project - if you have the wrong team and leadership they'll find every possible way to make things go wrong, no matter which approach you take. No idea what went wrong here, but it's unlikely to be development methodology and far more likely to be the result of politics and infighting between different departments and users.

    8. Re:Agile strikes again! by sjames · · Score: 2

      Sure, you can (and should) break it into smaller chunks, but if they're part of a greater whole, the right thing to do after finishing one is to move right on to the next with nothing more than a celebratory cup of coffee in between. All the smaller chunks are going to do is run their minimal self tests at that point anyway, so there's not much to show anyway.

      If you're taking a break because that's what some methodology says you have to do, you're doing it wrong.

    9. Re:Agile strikes again! by Jane+Q.+Public · · Score: 2

      "can you tell me how long a story will take to code before you code it? add in to the mix it has to work seamlessly with the other stories that make up the same UI element that other people wrote and fit in to the same work-flows. Re-factoring the work done in the other stories as well so yours can fit."

      That's why it's called an iterative process. Each time you have a standup or scrum, you make adjustments, until it works the way you want it to.

      I don't know what to tell you, man. Other people make it work. It worked for us just fine, when I was in an agile shop. And I don't think we would have gotten nearly as much done using more "conventional" methods.

  4. Reasons for failure by Anonymous Coward · · Score: 5, Informative

    From Wikipedia on software development projects.

    analysis of software project management failures has shown that the following are the most common causes:
            Unrealistic or unarticulated project goals
            Inaccurate estimates of needed resources
            Badly defined system requirements
            Poor reporting of the project's status
            Unmanaged risks
            Poor communication among customers, developers, and users
            Use of immature technology
            Inability to handle the project's complexity
            Sloppy development practices
            Poor project management
            Stakeholder politics
            Commercial pressures

  5. Apart from anything else by Presto+Vivace · · Score: 2

    Sentinel is not NIEM compliant.

  6. Time for a new chapter in methodology by Anonymous Coward · · Score: 2, Interesting

    http://programming-motherfucker.com/

    We are a community of motherfucking programmers who have been humiliated by software development methodologies for years.

    We are tired of XP, Scrum, Kanban, Waterfall, Software Craftsmanship (aka XP-Lite) and anything else getting in the way of...Programming, Motherfucker.

    We are tired of being told we're autistic idiots who need to be manipulated to work in a Forced Pair Programming chain gang without any time to be creative because none of the 10 managers on the project can do... Programming, Motherfucker.

    We must destroy these methodologies that get in the way of...Programming, Motherfucker.

  7. Give a chainsaw to a platypus... by Shoten · · Score: 2

    One of the problems here is that government contracting works best when it uses swarm theory. You have to think of the workers as ants...individually unintelligent, intended for single- or few-purpose roles at best. When you set goals using techniques and methods that require a more versatile kind of individual...well, you will fail, because recruiting aims for people who are less expensive. And the recruiting is driven by the procurement, which also drives costs down. Get bottom dollar for a project, and you have to give bottom dollar for the people, and get bottom dollar for performance. Agile development requires a bit more mental agility than most contractors I've seen possess. (Full disclosure: I work for a company that does a lot of contracting for the Federal government.)

    --

    For your security, this post has been encrypted with ROT-13, twice.
  8. I can't see that changing by dbIII · · Score: 4, Informative

    They still use a magic lasso lie detector machine invented by the writer of Wonder Woman and adopted by the FBI when their notoriusly corrupt leader J. Edgar Hoover was busy accepting kickbacks. Incompetence like that (unwillingness to fix obvious mistakes) is at the very core of their organisation and has made them an International laughing stock.