Category Archives: Agile

Some good IT project news from America

By David Bicknell

It’s always good to be able to write about IT project success. So I’m following up on Steve Kelman’s report in Federal Computer Week in the US about an October 2011 GAO report called Critical Factors Underlying Successful Major Acquisitions, which details seven recent government IT systems acquisitions – costing from $35 million to $2 billion – that have met their targets in terms of schedule, cost, and performance.

Aside from its conclusions on the critical success factors, the report says this about Agile software development: 

“….the use of Agile software development was critical to the success of the program. Among other things, Agile enhanced the participation of the end users in the development process and provided for capabilities to be deployed in shorter periods of time.”

As Steve suggests, the report should get wider circulation to show us what we might learn from success instead of from failure.

We’d be interested in your views.

Lifting the lid on Agile development within a public sector IT project

By David Bicknell

It’s not often that you get an insight into the workings of Agile development within a public sector  IT project.

So the Inspector General’s report into the Sentinel IT project at the FBI that I mentioned a couple of days ago offers a rare and unique picture into how the sprints, story points etc are progressing. This will not be new to Agile exponents – but the detail below may be of interest to those unfamiliar with Agile’s processes.

Transition to an Agile Development Approach

The report’s discussion of Agile within the Sentinel project says this:

“Agile software development is not a set of tools or a single methodology, but an approach that leverages close collaboration between representatives of system users, system developers, and testers to deliver functionality in a compressed timeframe and on a continuous basis. The delivery of working software is the primary measure of progress, and satisfying customers through the delivery of valuable software is treated as the highest priority during development.

“While an Agile methodology can be implemented in a variety of ways, the FBI is implementing a variation called Scrum, an iterative methodology which breaks the development effort into increments called sprints, each of which the FBI decided would last 2 weeks.

“At the conclusion of each sprint, User Stories – functions that a system user would typically perform – along with Architecture Stories – qualities that define the system software architecture and configuration – are planned and completed, and it is the successful completion of these stories that is measured as progress for the project.”

Development Progress

“As of August 26, 2011, the FBI had completed 22 of 24 planned sprints. Under the Scrum approach, a project’s progress and amount of work remaining is measured using a burndown chart, which depicts how factors such as the rate at which a development team completes work (a team’s velocity) and changes in a project’s scope affect its likelihood of staying on schedule and within budget over time.

“This information can be used by project management and project stakeholders to estimate the duration of the project or the amount of work that can be completed within an identified amount of time.

“During the first 22 sprints (Sprint 0 through Sprint 21), the FBI had completed 1,545 of the 3,093 story points (1,548 remaining) that it identified at the beginning of the project, or about 50 percent.  As of December 2, 2011, the FBI reported that it had completed 28 of 33 planned sprints ….It had also completed 2,345 story points  – 748 remained to be completed.”

Velocity

The Report says this of the Agile team’s velocity:

“According to FBI officials, after five sprints have been completed, the velocity, or rate at which an Agile team completes story points, can be used to project the completion rate of future work. During Sprints 5 through 21, the Sentinel team’s average velocity was 80 story points per sprint.

“During our review, we estimated that if the team’s velocity remained at 80 story points per sprint, the FBI would complete about 55 percent of the intended functionality by the end of the project’s originally planned 24 sprints on September 23, 2011. At that rate of development we estimated that Sentinel will be completed in June 2012.

“On September 6, 2011, the FBI CIO stated that the FBI had added six development sprints to Sentinel’s development schedule and that the FBI then planned to end development on December 16, 2011, after 30 sprints. After development ended, the FBI planned to test Sentinel for about 6 weeks and then deploy the system to all users in January 2012. During the additional development sprints, the FBI planned to finish the functionality work that it previously planned to complete by September 23, 2011.

“Based on the average velocity of 80 story points per sprint, and the number of remaining story points to be completed (1,548) we estimated that the FBI would complete about 71 percent of the intended functionality by the end of the project’s 30 development sprints on December 16, 2011.

“On December 1, 2011, the FBI again extended the schedule for the completion of Sentinel. The CTO stated that the FBI had added four development sprints to Sentinel’s development schedule and that the FBI now plans to end development in February 2012, after 34 sprints. After development, the FBI plans to test Sentinel for about 12 weeks and then deploy the system to all users in May 2012. During this testing period, the FBI plans to test Sentinel’s hardware and execute a test of all major Sentinel functionality that will involve personnel from across the FBI.

“Also in December 2011, after the FBI received a copy of our draft report, the FBI reported to us that during Sprints 5 through 28 it had completed 2,167 story points, an average of 90 story points per sprint – 10 more story points than its average rate as of September 2011.

“Based on this average velocity and the number of remaining story points to be completed (748) during the final 5 sprints under this plan, the Sentinel team must increase its average velocity to approximately 150 story points per sprint.

“However, the six sprints between the end of development and deployment – during which the FBI will test Sentinel – could also have story points assigned to them that the FBI is not accounting for at this time, and as a result the total number of story points to complete the project could increase. Without including such an increase, the FBI would need to average about 68 story points per sprint over the total 11 sprints remaining before the planned May 2012 deployment.”

Sentinel Agile Development Approach

The report’s Appendix says this about the FBI’s approach to its Agile development for Sentinel:

“In October 2010 the FBI identified a total of 670 stories for the Sentinel Product Backlog, or the compilation of all of the project’s stories. The FBI has mapped the Product Backlog to each of the requirements in Sentinel’s Systems Requirements Specification (SRS), which serves as an important control to ensure that the backlog, and the stories it contains, cover all of Sentinel’s requirements. The FBI also assigned weighted amounts, or “story points,” to each story in the Product Backlog based on the difficulty of the work associated with each story. The FBI assigned a total of 3,093 story points to its 670 stories in the Sentinel Product Backlog.”

The Report’s Conclusion

Although it appears that the FBI has made good progress with its Agile development, adopting Agile may not be enough to get the project exactly on track, with some testing issues and hardware problems discussed in the report.

“It is too early to judge whether the FBI’s Agile development of Sentinel will meet its newly revised budget and completion goals and the needs of FBI agents and analysts.

“While the Sentinel Advisory Group responded positively to the version of Sentinel it tested, results from wider testing were not as positive. Also, none of the Agile-developed Sentinel has been deployed to all users to give them the ability to enter actual case data and assist FBI agents and analysts in more efficiently performing their jobs.

“Despite the FBI’s self-reported progress in developing Sentinel, we are concerned that the FBI is not documenting that the functionality developed during each sprint has met the FBI’s acceptance criteria. Our concerns about the lack of transparency of Sentinel’s progress are magnified by the apparent lack of comprehensive and timely system testing.

“Our concerns about the lack of transparency also extend to Sentinel’s cooperation with internal and external oversight entities, to which Sentinel did not provide the necessary system documentation for them to perform their critical oversight and reporting functions.

“We believe that this issue could be resolved, at least in part, with a revision to the FBI’s Life Cycle Management Directive to include standards for Agile development methodologies.

“….Sentinel experienced significant performance problems during the Sentinel Functional Exercise. The FBI attributed these performance problems to either the system architecture or the computer hardware.

“According to the FBI, subsequent operational testing confirmed the inadequacy of the legacy hardware and the requirement to significantly expand the infrastructure before the system could be deployed to all users. In November 2011, the FBI requested that Lockheed Martin provide a cost proposal for this additional hardware.”

The FBI’s Response

In its response to the report, the FBI says:

 “….we are mindful of the short delay we have recently encountered under our new” Agile” approach. The Sentinel development schedule has recently been extended by two months (from December 2011 to February 2012), and the FBI-wide deployment is now scheduled for May 2012, as described in this Report.

“This modest extension is due primarily to the need to implement a standard  five-year “refresh” of computer hardware, so the Sentinel software will provide the required functionality as intended. Indeed, you have determined that, given the pace at which the program has proceeded under the Agile approach over the time period you reviewed, your estimate for completion is essentially the same – June 2012.

“We have one concern with the current draft of the Report. We request that you note that the hardware we are acquiring for the refresh, which is being purchased using fiscal year 2012 operations and maintenance funds, is separate from the development activities being carried out by the Agile team under the development budget.

“The refresh is part of the normal and expected operations and maintenance activities of the FBI, and such a refresh is a common maintenance activity where hardware has reached its expected replacement threshold. We do not agree that the FBI is using operations and maintenance funds for the development of Sentinel…and we ask that you make this revision.”

FBI chooses Accenture for IT project to modernise its HR systems

By David Bicknell

Yesterday I mentioned the challenges that the FBI is having in bringing a case management IT project in on time.

It’s good to know then that the FBI will now be assisted in its ongoing delivery of IT by Accenture.  Not for the case management project, but for an enterprise resource planning (ERP) system  to support the FBI’s Human Resources Information System (HRIS).

The award, under a  General Services Administration IT schedule that provides technology support services to the FBI through a ‘Blanket Purchase Agreement’ (BPA) plus four task orders’ will enable Accenture Federal Services to oversee selection, installation, testing and support to the agency’s HR systems.  Accenture also will complete a fit gap analysis to determine possible future costs to replace the FBI’s current HRIS systems.

Accenture said that by modernising its Human Resources information System, the FBI ‘will be able to increase effectiveness and streamline processes. These improvements will help the FBI develop a modern, on-demand system for accessing personnel information.’

The contract, which includes one base year with four option periods, also requires Accenture to submit a report with recommendations the FBI can use to determine whether to customise software, re-engineer business processes or combine both options to support future needs.   
 
Accenture, as its press release puts it, will also be ‘eligible to receive additional task orders under the BPA.’
 

Agile approach ‘reduces risk’ but offers no delivery guarantee for FBI as Sentinel project slips again

By David Bicknell

A recent story by the US magazine InformationWeek Government has cast some doubt over whether a move to Agile development will necessarily bring IT projects in on time and to budget, despite the best intentions. Sometimes other technology factors, such as legacy hardware, come into play.

The report says an FBI project to develop a digital case-management system to replace outdated, paper-based processes has been further delayed, despite a move to use Agile development to hasten the project’s completion.

The system, dubbed Sentinel, is now due to go live in May, eight months later than the FBI planned when it embarked on the Agile development plan.

It follows a number of delays going back to 2006 in the plans to build a replacement for the FBI’s 17-year-old Automated Case Support system, which is used by agents and analysts to manage their cases.

 In 2006, Information Week Government reports, the FBI awarded Lockheed Martin a $305 million contract to lead development of Sentinel, but took back control of the project in September 2010 amid delays and cost overruns.

Then, the FBI said it planned to finish Sentinel within 12 months using Agile development. But that worked has slipped (the FBI had earlier pushed Sentinel’s deployment from September 2011 to January 2012), and a four-hour test of the system in October resulted in two outages, according to a report by  the Inspector General released in December which contains details of the Agile development’s sprints’ progress.

The FBI said the glitches  were down to overburdened legacy computer hardware and said the hardware will need to be upgraded to support Sentinel’s use across the agency, according to the Inspector General.

The report’s conclusion says:

The FBI’s transition to an Agile development approach has reduced the risk that Sentinel will either exceed its budget or fail to deliver the expected functionality by reducing the rate at which the FBI is spending money on Sentinel and by instituting a more direct approach to the FBI’s monitoring of the development of Sentinel.

!When we provided our initial draft of this report to the FBI in October 2011, we expressed concern that the rate at which the FBI was developing Sentinel’s functionality indicated the project was at risk of falling behind the FBI’s then planned January 2012 deployment date.

“In December 2011, after we completed our fieldwork for this report and after we provided the FBI with a revised draft report, FBI officials told us that the FBI extended the Sentinel deployment date to May 2012. While we have not had the opportunity to fully review the FBI’s plan to meet these revised completion dates, we continue to believe it will be challenging for the FBI to meet this latest goal for deploying Sentinel to all FBI users in this timeframe.

“It is too early to judge whether the FBI’s Agile development of Sentinel will meet its newly revised budget and completion goals and the needs of FBI agents and analysts. While the Sentinel Advisory Group responded positively to the version of Sentinel it tested, results from wider testing were not as positive. Also, none of the Agile-developed Sentinel has been deployed to all users to give them the ability to enter actual case data and assist FBI agents and analysts in more efficiently performing their jobs.

“Despite the FBI’s self-reported progress in developing Sentinel, we are concerned that the FBI is not documenting that the functionality developed during each sprint has met the FBI’s acceptance criteria.

“Our concerns about the lack of transparency of Sentinel’s progress are magnified by the apparent lack of comprehensive and timely system testing. Our concerns about the lack of transparency also extend to Sentinel’s cooperation with internal and external oversight entities, to which Sentinel did not provide the necessary system documentation for them to perform their critical oversight and reporting functions. We believe that this issue could be resolved, at least in part, with a revision to the FBI’s Life Cycle Management Directive to include standards for Agile development methodologies.”

Responding to the report the FBI said:

“The Federal Bureau of Investigation (FBI) appreciates the opportunity to review and respond to your draft report entitled, “Status of the Federal Bureau of Investigation’s Implementation of the Sentinel Project.”

“We are pleased with your conclusion that, by adopting an Agile development approach, the FBI bas “reduced its rate of spending on Sentinel” and instituted a more “direct approach to monitoring the development of the system’s functionality.”

“Indeed, as the FBI’s figures included in this Report demonstrate, while we have expended only 52% oftbe Agile development budget of$32.6 million. as of December 6 we had completed 88% of the required system functionality. The percentage of functionality completed has further increased during the time that has passed since your report was last updated.

“This accomplishment is significant. In mid-2010, the FBI charted a new course for completing the remaining two phases oftbe Sentinel program using an Agile development approach, which represented a substantial departure from its prior development activities. As a result, you concluded in this Report that the FBI is “expending significantly fewer dollars per month than it had in Phases 1 and 2 for the project.”

“In sum, we agree with your conclusion that the FBI’s transition to an Agile development approach has “reduced the risk that Sentinel will either exceed its budget or fail to deliver the expected functionality.” As you note, “at this point in time, the FBI does not foresee exceeding the $451 million budget to complete the Sentinel project.”

“With that in mind, we are mindful of the short delay we have recently encountered under our new” Agile” approach. The Sentinel development schedule has recently been extended by two months (from December 2011 to February 2012), and the FBI-wide deployment is now scheduled for May 2012, as described in this Report.

“This modest extension is due primarily to the need to implement a standard five-year “refresh” of computer hardware, so the Sentinel software will provide the required functionality as intended. Indeed, you have determined that, given the pace at which the program has proceeded under the Agile approach over the time period you reviewed, your estimate for completion is essentially the same – June 2012.”

Inspectorate General report

Agile for Universal Credit a good choice

Happy New Year from Campaign4Change

By David Bicknell

A Happy New Year to all our readers from both Tony Collins and me. Let’s hope that 2012 brings success in the development of IT projects – and satisfactory resolution for those that weren’t quite so successful – as well as continued progress for Pathfinder mutuals.

I’d like to see the London Borough of Hammersmith & Fulham’s Schools IT mutual successfully get off the ground early this year, and for another  mutual, Central Surrey Health that I spoke with in 2011 to make the continued business progress its efforts deserve. I hope that all growing, developing and prospective mutuals get all the political and economic support they need to thrive.

I came across a few stories at the end of 2011 from other blogs that made for interesting reading, plus a few Campaign4Change favourites. Here’s a selection:

Taking Stock

Lessons from the GoDaddy Customer Revolt

Top Harvard Business Review Blog posts of 2011

Top 10 Green Business stories

The unavoidable truths about GovIT

Government’s new ICT Plan – the good, the bad, and what’s needed

Agile can fix failed GovIT

G-Cloud and agile briefings

By Tony Collins

On 22 November the Government Digital Service is giving a briefing for potential G-Cloud suppliers. It’ll be streamed live.

Officials say the briefing will be particularly useful to suppliers whose employees have never participated in a government tender.

At the ApplyCamp, officials will explain G-Cloud, steps in the OJEU procurement process, what information potential G-Cloud suppliers need to give, and what happens next.

The event is particularly aimed at Infrastructure as a Service, Platform as a Service, Software as a Service and other specialist cloud service suppliers. It will be held at Google, 76 Buckingham Palace Road, London SW1W 9TQ – 3pm – 5pm.

Agile TeaCamp – 24 November

Between 4pm and 6pm at the Cafe Zest, House of Fraser, Victoria St, London, there will be talks on agile. Derrick Cameron, MD of software consultancy Eximium and COO of agile software house Procession will speak on “Becoming the Intelligent Buyer”.  Chris Parsons, a “freelance thinker, coder and trainer” will talk about the e-petitions project and the aims of the Agile Delivery Network.

Teacamps in November and December – Government Digital Service

UK GovIT often a barrier not enabler says Cabinet Office official

By Tony Collins

In an interview for UKauthority.com Chris Chant, Executive Director at the Cabinet Office and head of the G-Cloud programme,  debunks the claims of some that GovIT doing a great job and should remain largely untouched.

Chant says: “IT is supposed to be an enabler. Quite often in my experience in government IT it is actually a barrier to getting things done. That’s no way to use IT. It is supposed to support what we do.”

His criticism puts into context claims by some in the civil service that GovIT is an unpublicised success because of the ease and success of online re-taxing of vehicles, the payment of benefits to millions of people and the collection of taxes.

Chant has made clear his concern that some departments are locked into major IT suppliers through costly, inflexible long-term contracts that, in some cases, are being signed anew.

“In the main we are not delivering good quality IT to government and public sector workers. We are not delivering good IT solutions to the citizen …”

He calls for internal change and describes SMEs as “front and centre to what we need”.

“It is with SMEs that agility and innovation lie, and it is that market we are really encouraging… Good IT is not developed by spending a long time trying to work out a definitive answer, and then taking ages over delivering it only to discover it is not what we needed in the first place. It is about iteration. I have said all along that we do not have all the answers. We will develop as we go and take SMEs with us.”

Asked whether the public sector is ready for the cloud Chant replies: “No we are not. We are quite a way from that… We are very well positioned to operate in a world where our IT is delivered by multinationals but now it is a different world.”

He says that the cloud has security limitations. “It is difficult to see the cloud in the short term handling some of the higher security aspects of what we do but for a lot of what government does it’s about commodity products and we need to get people in who know how to handle that.”

The focus he says must always be on the citizen – assumptions should not start from a departmental or systems standpoint. “We will need to change the way we do things; we will need some new people and I suspect a lot of retraining. I think we will need a lot fewer people working on the client side of government IT…

“We are in really tough times and the idea that we can operate with [current] cost levels is wrong…”

Government clouds take shape – UKauthority.com.

The unavoidable truths about GovIT – Chris Chant.

Vested interests will try to stop GovIT changing.

What exactly is HM Revenue and Customs paying Capgemini billions for?

DWP signs new large contracts with HP, Accenture, IBM and Capgemini.

Praise for departing Deputy government CIO

By Tony Collins

Bill McCluggage, the departing Deputy government CIO, has been praised by friends and colleagues for his strength of purpose as a change advocate, and for steering through the government ICT Strategy.

He is also admired by friends for “telling it like it is” despite the Cabinet Office’s restrictive communications policy.

Said one friend: “To get the ICT strategy out and into delivery underlines Bill’s credentials as a deliverer not just a strategist; and he regularly held his ground with those who sought to maintain the status quo.”

McCluggage announced this week he is leaving government to join storage supplier EMC. He said on Twitter that it’s “sad to leave excellent team that have delivered real change but time to move on and address new challenge”.  He said he counted himself “lucky to have been part of the vanguard of new GovtIT”.

Mike Bracken, Executive Director of Digital, Efficiency and Reform Group, Cabinet Office, said that Whitehall will be poorer in McCluggage’s absence.

McCluggage joined the Cabinet Office as Deputy Government CIO in September 2009. He has been Director of ICT Strategy & Policy and Senior Information Risk Owner with overall responsibility for the formulation, development and communication of cross-Government ICT strategies and policies.

He was IT Director at Harland & Wolff Heavy Industries in Belfast and was an engineering officer in the RAF. He is a chartered engineer and member of the Institution of Engineering and Technology.

As Deputy government CIO McCluggage has been a firm advocate of agile techniques, cloud computing, open source, cutting out waste and duplication, and bringing many more SMEs into GovIT.

Deputy Government CIO to join EMC.

Deputy government quits.

Cabinet Office loses another top ICT man.

Will the government’s ICT implementation plan finally lock on to the SME solutions it misses?

By David Bicknell

The  government has the potential to leverage its huge buying power in the ICT marketplace. However, the government’s procurement of ICT has in many cases failed to deliver economies of scale and failed to deliver value for money to the taxpayer.

So that is why the latest ICT implementation plan has an objective for the reform of government procurement by centralising common goods and services spend by funding improvements in technology, processes and government wide procurement resources to better manage total procurement spend and government wide standards. 

The government insists it is therefore committed to become a single and effective ICT customer, leveraging buying power whilst remaining flexible on how it procures.

As part of that process the  government says it will create a more open, transparent and competitive ICT marketplace embracing open standards and open source that will remove barriers to SME participation in public sector procurement to create a fairer and more competitive marketplace.

It is important that these barriers to SME participation are removed, because these smaller innovative companies have solutions that the private sector recognises and which will pay to acquire, but which the government seems to miss.

One, ChangeBASE, which specialises in automated application analysis, remediation and conversion for platforms including Windows 7 and 8, Internet Explorer 8 and 9, Terminal Server/Remote Desktop Session Host, VDI, and Application Virtualisation, has just been snapped up by Quest Software  to help Quest become a single source to help organisations take advantage of technology changes to benefit both IT and users alike.

Another UK SME, Procession, continues to try and make the government aware of its technology for the creation of business application software that is both rapidf and agile. Procession’s CEO David Chassels recently wrote to Cabinet Office minister Francis Maude to try and engage with the government in its goal of becoming a better and more intelligent buyer of ICT. It also plans to speak at a forthcoming “teacamp”, the latest of a series of informal meeting places to stimulate ideas and discussion about government work in ICT.

A third, BCS, provides a global universal library subscription service that provides monthly audit data analysis and optimisation for devices, making audit data much easier to manage and understand. It has also created a carbon footprint library that enables organisations to establish a desktop estate baseline for CO2 information so that they can establish and manage software influence on CO2 output and reduce their carbon offset purchase requirements.

There are countless other SMEs offering innovative solutions to help deliver value for money for the taxpayer that the government still probably has no knowledge about, and which have long since given government procurement up as a lost cause.  The  government says it will create a more open, transparent and competitive ICT marketplace that embraces open standards and open source and that removes barriers to SME participation in public sector procurement.

As they say, the proof of the pudding will be in the eating.

Government publishes cloud computing, end user device, Green IT and ICT Capability strategies

By David Bicknell

The government has published four strategies which it says, “provide the environment and approaches to radically transform the ICT landscape to create a more productive, flexible workforce that delivers digital public services in a much more cost effective way.”

According to Cabinet Office minister Francis Maude, the four strategies “link together to fully exploit the cost opportunities arising from technology developments; and to increase the capability and capacity of Government to manage its own ICT and reduce reliance on expensive consultants and contractors.”

The strategies include cloud computing, which Maude says, “details how we will exploit cloud computing to transform the Government ICT estate into one that is agile, cost effective and sustainable.  Government will adopt an approach of ‘public cloud first’ whilst recognising the requirement for secure private cloud provision in some areas. 

“Government will move away from expensive, long-duration bespoke solutions to a common approach – sharing resources and infrastructure to enable us to become a consumer of widely available, ever improving mass market products and solutions.  Many of these solutions will be available for reuse from the Government Application Store.”

“Through significant rationalisation of our data centre estate – moving to a commodity approach towards hosting – we will increase utilisation and efficiency, thus reducing CO2 emissions, accommodation and energy costs.”

The other strategies published include Greening Government ICT, which provides a practical approach to reducing energy costs increasing the sustainability of the ICT estate; an End-User Device strategy which the government says will redefine the way that Government departments work; and an ICT Capability strategy.

“Supporting the Civil Service Reform programme and our ability to significantly reduce our estate and associated costs, the End-user Device strategy will give  public sector workers the freedom to work from any location on any suitable government or non-government device,” says Maude.

On  the ICT Capability strategy, he argues that government will not be able to fully exploit the opportunities from all its strategies without ensuring that the people it employs have the right skills and techniques to manage and run them effectively. The ICT Capability strategy will use a professional framework to put in place structures and processes to increase the capability of ICT professionals at all levels and reduce expenditure on external expertise.

You can access the strategy documents here