The FBI’s Sentinel project is a recently completed case study of the potential of Lean/Agile methodologies for managing government projects.
“so fraught with miscommunication, incompetence and failed oversight that the entire debacle would have been a shoo-in for the most flagrant waste of taxpayer dollars since, well, ever”
They were over-running and close to killing the project when they got radical.
They dropped the number of project staff from 125 to 55 and brought in private-sector consultants to implement scrum using 2-week sprints.
21 sprints and 670 user stories later, this likely failure has been declared a success.
In two of five lessons learned, Agile both gets things done and costs less.
What are your thoughts, and are you using Agile methodologies in your workplace?
Well, I read the article by Foley and I wonder how much of the success was due to agile considering that the project abandoned building software from scratch and used commercial software and upgraded the technical infrastructure for the new application. I also thought there was some funny accounting when the FBI staff costs were not factored in.
I was confused by this from “FBI Sentinel Programme Saved by Agile?”:
“Only those stories that passed those tests were claimed to have been completed.
Delivery has been hampered by a suspension of all system changes around the tenth anniversary of 9/11 last year, and there are still concerns about its performance and availability until the standard five-year refresh of computer hardware is completed.”
Does this mean that there is still uncertainty if the project was fully successful? And I wonder if there was an accounting for having to modernize the hardware to run the application?
Again, this points to the major complaints I have against agile: how do you measure success and how do you prove it really saves money and time? I haunt the boards here at GovLoop and on LinkedIn and I never seem to receive a definitive answer.
Thanks for the comment Bill.
It’s a hard thing to quantify directly, there are many different variables at work. I’ve had personal experience where based on the traditional waterfall approach and assumptions, a Lean approach delivered a release 2 months early (9 months to 7 months). But then if your baseline is set with a lean/agile paradigm then there’s no reason it might not take an extra sprint or two than you originally thought.
The only systemmatic way to go about it I think would be to take large enough samples of project data where you can both compare lean/agile to waterfall for similar projects and have a big enough sample size to account for the myriad of variables involved. Size, complexity, team performance, leadership differences, customer differences, sponsor differences, etc.
As far as I know this hasn’t been done. Nor do I expect it to, you’d have to have a ton of companies willing to be very open with their project information and have enough rigor to report accurately too.
I like this article by Martin Bauer on the topic. What do you think?
That’s great case study. I’d like to hear about some more.
@Josh – Great article by Bauer! I fully agree that you have to pick the best approach for your project based on the needs of the project. That is why I constantly refer to Wysocki’s matrix of project management methods.