FBI's Troubled Sentinel Project Delayed Again 96
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."
Re:They probably wrote it in Java (Score:5, Funny)
Re: (Score:2)
the glass is half... (Score:4, Funny)
Re: (Score:2)
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.
Re:the glass is half... (Score:5, 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.
I can't see that changing (Score:5, Informative)
Re: (Score:2)
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.
Re: (Score:2)
Ah, you probably have not had a member of your family murdered and had to rely on the FBI to catch the perp.
Re: (Score:1)
Since most murders go unsolved, I think you've picked a fantastically poor rationalization.
Re: (Score:2)
Re: (Score:3)
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.
Re: (Score:2)
It probably would be celebrated, if it weren't the FBI.
Re: (Score:2)
After 4 years of doing nothing more than contract management, did any competent developers stick it out for 4 years at the FBI?
Agile strikes again! (Score:4, 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.
Re:Agile strikes again! (Score:5, 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.
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:3)
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
Re: (Score:2)
Re:Agile strikes again! (Score:5, Insightful)
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.
Re: (Score:2)
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.
Re:Agile strikes again! (Score:5, 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.
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
"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.
Re: (Score:2)
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.
Re: (Score:2)
Although I should qualify that: I do agree that "inheriting" an existing project can sometimes be much worse than just building one from scratch.
Re: (Score:2)
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
Re: (Score:2)
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!
Re:Agile strikes again! (Score:5, 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.
Re: (Score:2)
Absolutely. But you can do any process wrong, and waterfall is in many respects much easier to screw up.
Re: (Score:2)
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
Re: (Score:2)
I would definitely not think of size or complexity as barriers to agile.
The design issue you're describing is usually thought of as a spike:
http://agile101.net/2009/09/29/using-%E2%80%98spikes%E2%80%99-in-agile-software-development/ [agile101.net]
Re: (Score:2)
Re: (Score:3)
The only place I see the "2 week sprint" agile working is for trivial enhancements to an already well written piece of s
Re: (Score:2)
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.
Re: (Score:3)
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.
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:3)
"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
Re: (Score:2)
Re: (Score:3)
"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.
Re: (Score:2)
It seems to work pretty well for Linux development.
Re: (Score:2)
Linux development is agile but not Agile.
Re: (Score:2)
Then it's not agile:
Waterfall = sacrifice delivery date to maintain features.
Agile = sacrifice features to maintain delivery date.
Re: (Score:2)
Agile = sacrifice delivery to maintain delivery date.
FTFY
Re: (Score:2)
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)
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
Apart from anything else (Score:3)
Re: (Score:2)
I have a hard time deciding if that website is satire or not. If it's a fake ... it's an impressively detailed one.
Re: (Score:2)
Re: (Score:2)
Consider how many government offices have gotten an F in network security....
Re: (Score:2)
All true, but all you need is one single agency to fail to secure their web server (one of the ones that did get an F) and you now have a joke .gov site.
Agile technics... (Score:1)
The senior developers are permitted to have only one warning, no more.....
Re: (Score:2)
I'm just sayin'
Re: (Score:2)
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
$305 million? (Score:1)
Seriously, does this thing have some amazing AI or other sci-fi requirements? Infinite zoom?
Re: (Score:2)
Seriously, does this thing have some amazing AI or other sci-fi requirements? Infinite zoom?
AND enhance!!
Re: (Score:2)
Don't worry that money didn't come out of their budget for looking at child porn. Er, for child porn, for.
Re: (Score:2)
The problem with that is that things like the FBI, DoD and other agencies that are particularly useless never seem to be affected by GOP cost cutting the way that useful things like the FAA, FDA and DSHS are.
Re: (Score:2)
Re: (Score:2)
Hi, I don't know a damn thing about the FBI, DoD and the other agencies either, can I subscribe to your newsletter?
Agile at this late phase of project (Score:1)
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.
Time for a new chapter in methodology (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 c
Re: (Score:2)
umm.. that is what we started with in the beginning..
Re: (Score:2)
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.
Re: (Score:2)
But going
Give a chainsaw to a platypus... (Score:3)
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.)
News (Score:1)
The primary problem is they didn't use... (Score:2)
...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
Wast of Money (Score:2)
too many suits (Score:1)
Yet another Big Company / cheap labor disaster (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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
Obligatory Dilbert (Score:1)
Big government run computer projects always fail (Score:1)
2nd Failure to replace old system (Score:2)
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
Re: (Score:1)
Re: (Score:2)
This is where the project failed the first time....
http://www.washingtonpost.com/wp-dyn/content/article/2006/08/17/AR2006081701485.html [washingtonpost.com]