Forgot your password?
typodupeerror
United States IT

FBI's Troubled Sentinel Project Delayed Again 96

Posted by Unknown Lamer
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."
This discussion has been archived. No new comments can be posted.

FBI's Troubled Sentinel Project Delayed Again

Comments Filter:
  • by alphatel (1450715) * on Monday January 09, 2012 @08:19PM (#38644870)
    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?
    • by AHuxley (892839)
      4 years protected a lot of consulting and private sector "retirement" moves.
      You and your family are security cleared, ready to explore the private sector.
      Nobody wants to be the agent or listed as working under the agent who upset with the private sector contractor.
    • by Jah-Wren Ryel (80510) on Monday January 09, 2012 @09:11PM (#38645482)

      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.

      • by dbIII (701233) on Monday January 09, 2012 @10:12PM (#38646214)
        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.
      • by rastilin (752802)

        Maybe not. If they were the kind of people who were sharp enough to manage a project successfully then they wouldn't think that controlling everyone's information is a good idea. Both are manifestations of incompetence, so we're pretty safe.

      • by gtall (79522)

        Ah, you probably have not had a member of your family murdered and had to rely on the FBI to catch the perp.

        • Since most murders go unsolved, I think you've picked a fantastically poor rationalization.

        • by physburn (1095481)
          Very true. Seen thousands of TV shows about it though. There are three bad sides to being socialised into a climate of fearing the law. One is the paranoir of being a criminal the other is the paranoia of the being a victim, the third is a mind full of worse case scienios. Over all, it probably makes us safer, if more miserable. Perhaps Life is batman not the x-files.
    • 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.

      • It *IS* a convincing validation of Agile software development.

        It probably would be celebrated, if it weren't the FBI.
    • by PPH (736903)

      After 4 years of doing nothing more than contract management, did any competent developers stick it out for 4 years at the FBI?

  • by viperidaenz (2515578) on Monday January 09, 2012 @08:30PM (#38644976)

    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.

    • by Surt (22457) on Monday January 09, 2012 @08:37PM (#38645052) Homepage Journal

      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.

      • by Synerg1y (2169962)

        I think...

        But now performance issues have arisen in testing and deployment has been pushed out to May

        Sum its up real nicely, it might seem infinitely complex, but there's actually several common reasons for this, and I'm sure I don't know all of them either...

        1. third party libraries that suck to begin w (ex. nhibernate)
        2. Dev time requirement changes: yep code on top of code has performance issues a lot, suits will NEVER figure this one out.
        3. No QC / under funded QC / bad QC process: some ppl nowadays expect the coder to QC their own work, please reference quote for typical result (only applies

      • They have been following 2 week sprints developing stories they've put on post-its after time wasting planning sessions. When I say haven't delivered I mean to production. They have delivered many builds to test but its full of defects.
        • Dude,

          This is how it's supposed to work. You can fix defects... You can't fix a system that isn't even working a little bit.

          This is how open source works. Get something working, anything.. and then define the changes to get to where you want to be.

          • by hedwards (940851)

            Or you could do it like they did back in olden days where you figured out what the code should do in basic terms then went about writing the code. If you're not going to bother to follow a plan up until the point where you've covered the things that you need, then I'm not sure why you'd expect to ever finish.

            I'm not really sure I understand why one would expect to program without a game plan and then wonder why later on it's taking so long to optimize and generally fix.

            • 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 delive

              • The team is most likely too large. This will exacerbate any communication and QC issues. I can just imagine the poor programmers working on this turd. Please hit thedailywtf.com guys; we want to hear your stories.

          • by viperidaenz (2515578) on Monday January 09, 2012 @10:18PM (#38646282)
            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.

            • by plopez (54068)

              Agile has some good ideas, but what I see is that it became the latest flavor of the month and has been implemented by many who don't have a clue as to what it is.

              • by sjames (1099) on Tuesday January 10, 2012 @01:51AM (#38647796) Homepage

                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.

            • I think similar things every time I see people raving about the latest programming language or framework. Some of these things are good, but I tend to wait to see how things stand the test of time before wasting time on them myself.

              With project management and development practices you can read and learn a lot of interesting things, but often they don't really click until you've experienced them for yourself. And even if you know something to be true, good luck trying to convince your clients or management h

            • by Surt (22457)

              We use agile on our large projects at Guidewire. We have over 100 successful enterprise customers, some of the largest insurers in the world. We've been doing it for multiple software generations now.

        • "They have been following 2 week sprints developing stories they've put on post-its after time wasting planning sessions. When I say haven't delivered I mean to production. They have delivered many builds to test but its full of defects."

          Delivering to production IS "delivery". Putting it on a staging or testing server isn't.

          It's pretty safe to say that 15 months ain't Agile. On certain really huge projects, maybe. But rare.

          • It's pretty safe to say that 15 months ain't Agile

            The project that TFA is about was "made agile" in September 2010, 17 months ago.

            • Even worse.

              Although I should qualify that: I do agree that "inheriting" an existing project can sometimes be much worse than just building one from scratch.
            • The project that TFA is about was "made agile" in September 2010, 17 months ago.

              That part of the article really bothered me. They talk about Agile and two week sprints, then go on to tell about the system test in October that failed. From the article it sounds like no one is using the system because it isn't deployed. What are they doing at the end of their 'two week sprints', because they obviously aren't rolling any code to production.

              Admittedly they are taking over an existing project, so release sche

        • by Surt (22457)

          So your claim is that your team delivers two weeks worth of work to test, it's packed with defects, and agile is the problem?
          Your problem is that your team can't deliver even two weeks worth of work without defects. Imagine how many defects they'd have if you waited a whole year to find out!

      • by Darinbob (1142669) on Monday January 09, 2012 @09:26PM (#38645676)

        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.

        • by Surt (22457)

          Absolutely. But you can do any process wrong, and waterfall is in many respects much easier to screw up.

          • by Darinbob (1142669)

            Agile seems oriented to work best with projects that are already done and need maintenance and new features, or variations of existing designs, or smaller projects. Those things can be split up into tiny sprints. But very large projects that need extensive design don't easily get done this way. I've been on several projects where for two weeks solid I have written zero lines of code, and in Agile that's considered blasphemy. This FBI project just sounds like something so big and complex that you can't s

    • by timeOday (582209)
      I appreciate your experience, but let's not forget that no other methodology has a great record of delivering massive projects on-time and on-budget, either. Nobody executes flawlessly; the winner is whoever executes best.
      • 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 s

        • If a piece of functionality takes longer than 2 weeks to finish (maybe not QA'd finished code, but developer finished) then break it down to smaller pieces that can be finished in two weeks. It's not that hard, but lots of developers make it much harder than it has to be.

          • by sjames (1099)

            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.

            • I'm really not sure what you mean by "taking a break because that's what some methodology says you have to do" means. Agile does not say you have to take breaks..

              I think you are confused by what agile is. It doesn't mean "Only do the work allocated to you for this sprint", Sprints can and should be adjusted if you have more work than can be done or not enough. And it's ok if you don't finish your work within the sprint, you just continue working on it in the next.. but if this happens too much you really

              • by sjames (1099)

                If there's no way to notice when one 'sprint' ends and the next begins, then it isn't anything at all and shouldn't have a name. If you can tell then it is a break in the flow of programming and shouldn't happen when you're in the middle of something. If it should be as long or short as you want, then what was wrong with 3 months? If you're building the framework, there may not be a natural breakpoint until it's done. Try as you might, if you treat the Boston Marathon as a series of sprints you will come in

                • Sprints can be as long as you want. However, the shorter the better. Sprints are all about course correction. At the end of a sprint, you review where you're at and what you're doing next. You try to plan enough work for a sprint, but you don't HAVE to make it only one sprint. It's best practice though.

                  Like anything, if it had absolutes, it wouldn't be feasible. It's never possible to do everything in a strict methodology, it has to have some wiggle room.

                  • by sjames (1099)

                    At that point, you're actually doing 'the right thing' and back justifying it to management by casting (or coercing) it in terms of 'flavor of the month'. That's the next best thing to the ideal do 'the right thing' I mentioned previously.

                    Ideally, if it feels like things are off track when you're talking at the coffee pot, it doesn't matter if you're in the middle of a sprint, three legged race or piling into the clown car, you should re-evaluate and correct course no matter what the chart says is on the ag

        • "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 on

          • 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. Wouldn't it have been easier if instead of adding two controls to a screen and mess around connecting everything up, removing old stubs, fixing shortcomings of related code because the person writing it didn'
            • "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.

    • by stms (1132653)

      It seems to work pretty well for Linux development.

    • by rwven (663186)

      Then it's not agile:

      Waterfall = sacrifice delivery date to maintain features.
      Agile = sacrifice features to maintain delivery date.

      • Agile = sacrifice delivery to maintain delivery date.

        FTFY

        • by rwven (663186)

          Bollocks. I've been on agile dev teams for years now, and we have consistently hit, or beat deadlines. The reason "agile" usually fails, is the same reason that waterfall usually fails. Bad development practices, poor project management, and a failure to actually understand and properly practice the development method itself.

          Most self-proclaimed agile teams are really just practicing glorified cowboy coding. Newsflash: That's not agile. TRUE agile, like TRUE waterfall, requires lots of discipline and stric

  • Reasons for failure (Score:5, Informative)

    by Anonymous Coward on Monday January 09, 2012 @08:33PM (#38644996)

    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

  • Sentinel is not NIEM [niem.gov] compliant.
  • Meaning one developer is working while another agent is standing next to him, with a gun pointed at his head, and waiting for the compiler to produce even one error......
    The senior developers are permitted to have only one warning, no more.....
    • by hguorbray (967940)
      Oxymoronic -Government AND Agile? pick one

      I'm just sayin'
    • by Sulphur (1548251)

      Meaning one developer is working while another agent is standing next to him, with a gun pointed at his head, and waiting for the compiler to produce even one error......

      The senior developers are permitted to have only one warning, no more.....

      Shot is warning to next guy.

      Yakov Smirnov

  • by Anonymous Coward

    Seriously, does this thing have some amazing AI or other sci-fi requirements? Infinite zoom?

    • by plover (150551) *

      Seriously, does this thing have some amazing AI or other sci-fi requirements? Infinite zoom?

      AND enhance!!

    • by hedwards (940851)

      Don't worry that money didn't come out of their budget for looking at child porn. Er, for child porn, for.

  • the FBI said it would finish Sentinel within 12 months, using agile development strategies.

    IMHO, this translates to: "We are going to duct-tape whatever we already have together and deliver a project which more or less fulfills initial (or revised) requirements, meanwhile being an unmanageable piece of s***. Heck, we are going to build it from scratch one decade later, anyways." On the other hand, I do not have any clue about the nature of problems encountered in this project, so above statement might or might not be a fair conclusion.

  • by Anonymous Coward

    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 c

    • by cowdung (702933)

      umm.. that is what we started with in the beginning..

    • There's more than a little truth to what you say.

      Reading the article, I don't think it was an issue with Agile. I think what the FBI was saying was they're going to try to go ahead on their own, using Agile.

      Not an Agile guy myself, but the top practitioners of this- Martin et al are known to be highly competent.

    • Uh, that's great, there's nothing I love more than spending a day programming, but how do you know what to work on? That's the whole point of these methodologies, making sure you program-motherfucker on the right thing. Doesn't help much to write a statistics package if your customer wants a VPN client. Doesn't help much to write a networking framework when all you need is to make one HTTP request. Doesn't matter how many new features you add if the previous ones are all so buggy they don't work.

      But going
  • by Shoten (260439) on Monday January 09, 2012 @09:07PM (#38645430)

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

  • by DnaK (1306859)
    Government agency pushes back date for project and asks for a few hundred million more. News at 11.
  • ...a software company. They went to a bunch of government hack jobs like Lockheed Martin.

    They can build an airplane, but I can tell you from personnel experience with 3 different divisions of theirs (ones doing military simulation, ones doing wide area security, and ones doing AI driven content management) they staff their people with plodders.

    I don't mean the people aren't capable of writing some software, but it is TOTALLY beyond them to write a complicated system. I would never hire any of the people I

  • Why they building Sentinels. Their aint no such thing as mutants. Those nerds need to stop reading comic books.
  • The problem with a huge bureaucratic octopus like the government, is that there are so many idiots that have to have their thumbs in the pie, that by the time everyone signs off on it, the project is 10+ years behind and the hardware & software is out of date. The FAA has been trying to replace radar systems at airport centers for a long time and when they are about to install it, they find out it's 20 years old and try to update it, starting the cycle again and again.
  • At least the FBI seems to have wised up to Agile methods, which implies they're actually going to go ahead and hire real programmers as opposed to the cheap labor places like Lockheed Martin and IBM are stuffed to the gills with.

    The rubber has to hit the road somewhere. Maybe you can contribute to your Senator's re-election campaign and get legislation that gives you visas for ten million programmers who will all work for 25 bucks an hour 12 hours a day 6 days a week, live 6 to an apartment and when th

    • Bet you anything the FBI is hiring programmers right now after having seen the advantages of developing and maintaining their own supply of stable, competent craftsman -programmers.

      You're much more confident than I am. The Federal government is the leader in NIH. (Not Invented Here) 'Smaller Government' is all about out sourcing everything possible to private businesses.

      • How right you are about smaller government and it's proponent's desire to outsource everything (to their buddies companies..).

        But the FBI and CIA and especially the armed forces are serious people who actually work in government because they believe in government of a specific kind- good government.

        Among serious adults, not about big government or small government, it's about GOOD government and towards that end, I'll wager, they're rethinking the in house craftsman / vs cheap ?? outsourcing debate i

  • Most big computer project run by the governments fail. Looking at my home in the UK, the government had this big idea about computerizing the air traffic control system and it all went wrong. They did the same with an attempt to computerize everyones health records and then repeated similar errors with an identity card system. I think the problem is maybe to do with people in government not really understanding the projects they are running. Another thing though, I read a declassified report by the CIA for
  • This isn't the first time that the FBI has had a project to replace it's old software fail. Back in 2002 - 2004 they wasted approximately $160 million on a failed project. It even went through some congressional oversight afterward and the FBI was heavily scrutinized, as was the company (SAIC I think) that was performing the work.

    I have had direct experience as a team member on a government project, and I can tell you it is the Government's own fault for failure to see their contracted out projects fail.

    H

    • by Mn3m0nic (234085)
      I am currently working in the 'project management' office at the FBI on a similar project. Internally its referred to in the usual 4-5 letter acronym format. While I tend to agree with most of your reasons listed for failure, the FBI has recently (past year and a half) finally started listening to professionals in the project/program management field. They are forcing projects to be managed by a central department that is held accountable for all issues and risks. Almost nothing is green level in meetin
    • by realsilly (186931)

      This is where the project failed the first time....

      http://www.washingtonpost.com/wp-dyn/content/article/2006/08/17/AR2006081701485.html [washingtonpost.com]

RADIO SHACK LEVEL II BASIC READY >_

Working...