Tag Archives: agile

How many organisations are failing to deliver on their Agile developments?

Posted on 23/04/2012 | 1 comment

By David Bicknell

How many organisations are struggling to see real value and business benefits from their Agile IT projects?

This blog, looking back at some of the predictions for Agile in 2012, argues that a number of organisations that have adopted Agile have an inability to understand its why and how, while others are inadaquately prepared for adoption, resulting in a failure to address management impact across teams and engineering practices in teams.

The piece cites the Cutter Consortium blog which, in looking ahead to 2012, argued that “many organisations worldwide will continue to adopt Agile. Most of them will do so with no expert guidance, with ho-hum results, and with little understanding of why they got those results.

It suggestted that, “People will continue to get their Agile skills certified while others rail against the value and implication of those certificates. Companies will still rely on head hunters to hire Agile coaches, and wonder why those coaches can’t seem to straighten out their Agile implementation.

“Organisations will continue to agonise over micro-estimation of detailed backlogs. They will continue to spend a pretty penny on “adding bodies” to projects riddled with technical debt, while not investing in the skills and habits their developers need to reduce or avoid increasing such debt. Managers will continue to use language like, “We just hired a resource in development” without investing proper attention in the hired person. And downsizings will continue until morale improves.”

Another blog predicted that, “Everyone will claim they are Agile, but that 50% of them will be wrong, and half of the rest won’t get any value from it. There are too many bad development practices at organisations that have too few people, with too little coaching, and hardly any tooling.”

Meanwhile, this survey suggests that Agile development has a higher priority in the private sector (in the US) than in the public sector.

So what is the true picture for Agile? Is it delivering project success, as JP Morgan and John Deere, have found? Or are some organisations adopting Agile almost as a fashion accessory, without really understanding where they’re going?

Related reading

Agile skills gain ground

JP Morgan adopts Agile in Australia

As Agile as a John Deere tractor

1 Comment

Posted in Agile, change management, Government IT, IT and the Business, IT projects, managing change, project management

Tagged , , , , ,

How do you create successful software development teams? (Part 2: Outsourcing)

Posted on 20/04/2012 | 3 comments

By David Bicknell

I recently reported on a roundtable organised by the Dutch software specialist Software Improvement Group (SIG) which set out to determine what makes successful teams in software development.

The roundtable featured two specialists in creating specialist teams: Andrew de la Haye, chief operating officer, at RIPE Network Co-ordination Centre (RIPE NCC), one of five Regional Internet Registries (RIRs) providing Internet resource allocations, registration services and coordination activities that support the operation of the Internet globally; and author and management expert Kevan Hall, chief executive of Global Integration.

In Part One of the discussion, which focused on creating excellent teams in software development, we examined teamwork, Agile empowerment, a commitment to quality, remote working and getting the right level of teamwork.

In this part of the discussion, we focused on managing multi-disciplinary teams, structure, reducing waste, and outsourcing.

Managing multi-disciplinary teams

Kevan Hall pointed out that when you’re working in a multi-disciplinary environment – for example, if you’re building a very complex piece of kit with tens of thousands of bits – there is a point at which you need to have some co-ordination.

But he added, “There is also a big part of the work where I’m an engineer off doing actual work or I’m somewhere writing code. And that’s not teamwork.  If we have this mentality that everything we do is a team, then we can’t make a decision until the next meeting. I distinguish between a team, which is kind of truly interdependent i.e. if you’ve got multi-disciplinary skills, R&D etc,  you really need to work collaboratively, tightly, and you can’t do it on your own, you need teamwork. But most work isn’t like that: most work is me doing my stuff.

“And therefore a simple hub and spoke group of organisations might be much simpler to do that. When you’re working globally, or virtually, that’s much, much easier because in a hub and spoke structure, if I want to talk to you, I just pick up the phone.  If I’m in a team, I have to go into all your Outlook diaries and hope that in the next month, you’ve got some time where we can at least all get on the phone.

“So hub and spoke is much simpler for virtual teams and for remoteness and those kind of things. So when we are  working collaboratively that’s when we really need to focus because it’s really expensive and quite hard to do.”

Waste reduction and communication

Andrew de la Haye from RIPE explained the need for what he describes as ‘waste reduction.’

“One of the things we do as standard culture in our software teams is every three to four months we do waste reduction sessions. So in the old methodology, you do retrospectives. You start a sprint – a sprint is two weeks – you deliver to the business, and after that, the team sits together and then they discuss what went well and what should be improved in the next sprint. And as a larger group in the whole department, we get them together once every four months for an hour or two at the most and we say, ‘OK. Where is waste? Where do we see waste?”

“And most of the time it is not coding or the real work they do, most of the time it is in the communications area.  And we try to get rid of it. So we changed the team from 2 x 6 to 3 x 4 people. It’s just part of our being to look at the waste we created after the last period and where can we improve. And they became  much more efficient and effective.”

According to Kevan Hall, one of the things you often see with teams is the ‘community decay curve’.

“When you have a team, virtual or not, you have a kick off and everyone’s very enthusiastic. And then you start doing the work, and it’s quite hard. And then you come to the end of something and you’ve succeeded and you have a celebration. Successful virtual teams create a rhythm. For our teams, it’s a year. You have a long old slog and there is a ‘periodicity’ of communication. A software team is perfect because you have a closure, a learning opportunity, a celebration and then you go and do it again. If it’s longer than that, then you have to think about other things that are going to have an impact, like a conference call or a coaching call.

“Even worse, if you’re managing a remote organisation or a remote supplier, the risk is that you only call them when you need something or you’ve got a problem. So they don’t really look forward to your next call. ‘Oh, no. Look who’s on the phone.’ You demotivate people just by your number coming up. It’s about keeping that rhythm. It’s a bit like an ECG. You’ve got to create those peaks to keep motivation high.

“Social media has a very powerful role to play in virtual teams, because it’s much easier to share the other things that I’m doing rather than just project updates. I also like Instant Messenger because if you have people in Asia you can see that they’re ‘on’ and to me it’s just like passing someone in the corridor. It’s the virtual coffee machine. Occasionally, people will see say, ‘If you’re there, can we have a quick call?’ And it’s another part of the rhythm for me – like keeping the heartbeat going.”

Outsourcing

“I used to sell a lot of outsourcing,” said Andrew de la Haye. “But I haven’t seen it really working (teamwise). One of the issues with outsourcing is the commitment bit, which is very important in my teams. My people are committed to me because they know me, and they know what the company stands for. If you outsource to somebody, who are they committed to? You hope that they are committed to the organisation they’re working for, but they’re certainly not committed to you. And they are probably more committed to themselves, especially in India because people move around like crazy.

“So one of the issues with outsourcing is the lack of commitment, I think. I don’t see a solution to that. There are two ways of outsourcing: outsourcing commodity items, where there is a new version of SAP and people need to upgrade. That kind of stuff. That’s good enough – it will work fine. But if you truly need to build applications and you need to work together with a company to create business value, and that’s what a lot of outsourcing is about as well, I haven’t seen it working.

“I tried it again last year, and I gave a company a chance. I had a really good relationship with this consulting firm and they told me that they had an excellent team in India, and ‘Let’s try this project just for a three-month trial.’ And it was more or less the only project in the last five years that went belly-up.”

As Kevan Hall pointed out, when you’re managing across distance, culture, time zones, working through technology, and commercial considerations, outsourcing is so much more complex.

“One of the things we see a lot with clients who have outsourced is what I call the balance of trust and control. Because I don’t know you and I don’t trust you, I tend to control you. And so we go out to India and we have these incredibly heavy processes which we beat you up to make sure you follow without any sense of initiative or change, and then you start complaining that the Indians don’t have any initiative and don’t innovate.

“Well, you’ve told them not to and they’ve very smart people, albeit with higher turnover, and then you’re finding that problem of ‘how do we build trust?’ So many organisations outsource processes and spend an enormous amount of time on process, but they don’t have the travel budget to even go and meet the people who are doing a service for them.

“So how are you ever going to build a relationship? You wouldn’t do it in your own business. So doing it in an even more complex environment…how’s that going to work?”

“You have to look at the type of activity being outsourced,” said Dr Joost Visser, SIG’s Head of Research . “There is a lot of success in outsourcing in all sort of activities. In software application development where you are trying to create business value and where people are being creative, like in the automotive industry, thinking of the next engine or concept car, I think that by basically taking the team you need and pulling it out over locations and over time zones, you’re creating a challenge for the teamwork you need for that activity.”

There is another factor: the customer, suggested Kevan Hall.

“If you decided that you’re going to bring your development team into one place and therefore take away one barrier to complexity, which is distance, which makes a lot of sense, then aren’t you just exporting that level of complexity to the customer? Because they still have to manage with the fact that they still have stakeholders spread around the world in different time zones and different cultures. And they’ve got complex needs. It’s OK for you now. But is that the right thing to do for the customer?

“Human Resources has done that. They’ve gone to specialist centres and business partners. And all that’s done is that the business partner has to manage all the complexity rather than the organisation.”

How do you create successful software development teams? (Part 1)

3 Comments

Posted in Agile, Campaign4Change, change management, India, managing outsourced services, outsourcing, software development, software quality

Tagged , , , , , , , , , , , , , ,

Time for truth on Universal Credit IT

Posted on 03/04/2012 | 5 comments

By Tony Collins

A normally-reliable contact says that the IT project for Universal Credit is in trouble.

A deadline this month to lock-down features in the scheme will not be met, says the contact. This failure will jeopardise the go-live date of October next year for the start of Universal Credit.

The contact also says that the Government will make an announcement on the scheme in September which may refer to a write-off of at least £150m on the IT project. The suggestion is that although the scheme is in trouble officials may be reluctant to impart the whole truth to ministers.

We wonder about the difficulties of agreeing system features when there are so many parties involved in the IT project: HMRC, DWP, local authorities, banks and private sector employers. The contact also says Oracle is having trouble handling functionality.

Officially all is well. The Secretary of State for Work and Pensions, Iain Duncan-Smith, spoke with confidence about the future of the scheme in the House of Commons last week.

That said, he told Parliament on 5 March about the “issues and problems” related to HMRC’s Real-Time Information project which is an essential part of the Universal Credit IT project. He said: 

“HMRC, which is now responsible for this measure, meets me and others in the Department regularly. We have embedded some DWP employees in the HMRC programme; they are locked together. They are, as I understand it, on time, and they are having constant discussions with large and small employers about the issues and the problems, and assessing what needs to be done to make this happen and to make all the changes.

“We must remember that all those firms collect those data anyway; the only question is how they report it back within the monthly cycle. We are on top of that but, obviously, we want to keep our eye on the matter.”

Problems with the IT for Universal Credit – the Government’s leading “agile” software project – may bring a smirk to the faces of those who believe that departments cannot manage agile-based schemes. But agile proponents have long said that Universal Credit is only partially agile – and they have argued that agile should not be mixed with traditional software-writing approaches.

Suppliers on Universal Credit, which include HP, Accenture, IBM,Capgemini and Oracle, are not particularly well known for their love of agile on Government IT projects.

Time for the truth  

The Department for Work and Pensions is refusing to publish any of its reports and assessments on the IT for Universal Credit. The secret reports include:

–   A Project Assessment Review in November 2011

– Universal Credit Delivery Model Assessment Two (McKinsey and Partners)

– Universal Credit end-to-end Technical Review (IBM).

Comment

Officials and ministers speak publicly about the solid progress on Universal Credit IT while refusing to publish their internal reports on progress or otherwise of the scheme.

Past NAO reports have shown that ministers and sometimes senior officials are sometimes kept in the dark when major IT-related projects go wrong. Project steering groups are told what they want to hear. The Programme Board on the NPfIT discussed successes with enthusiasm and hardly mentioned serious problems, judging by minutes of its meetings.

We hope that all is well with Universal Credit IT. The project is, after all,  an advert for innovation in the public sector. If it’s in trouble the truth should come out. Keeping it quiet until September means that suppliers will continue to be paid for several months unnecessarily – perhaps to keep them supportive?

Labour was overly defensive and secretive about its many IT-related failures whereas “openness” is the coalition’s much-favoured word. It’s a pity it has yet to be applied to the Universal Credit IT project.

Secret DWP reports.

Who’ll be responsible if Universal Credit goes wrong?

Banks “unlikely to deliver” Universal Credit

Universal Credit IT plans too optimistic warn MPs.

Universal Credit latest

5 Comments

Posted in excessive secrecy, Freedom of Information, Government IT, innovation, managing change, managing outsourced services, npfit, openness and transparency, operational issues, Real-Time Information, software development, Universal Credit

Tagged ,

How do you create successful software development teams? (Part 1)

Posted on 29/03/2012 | 1 comment

By David Bicknell

Campaign4Change recently took part in a software development roundtable organised by the Dutch software specialist Software Improvement Group (SIG) to find what makes successful teams in software development.

The roundtable featured two specialists in creating specialist teams: Andrew de la Haye, chief operating officer, at RIPE Network Co-ordination Centre (RIPE NCC), one of five Regional Internet Registries (RIRs) providing Internet resource allocations, registration services and coordination activities that support the operation of the Internet globally; and author and management expert Kevan Hall, chief executive of Global Integration.

The event discussed the process in the creation of excellent teams in software development, the qualities shared by successful teams, the role that management plays in their creation, while highighting some of the factors that help create productive teams, and the issues faced by the people managing them. 

Teamwork

Arguably, great development teams typically demonstrate a lot of very tight teamwork, with small groups that all know and understand each other working intensively together.

According to Andrew de la Haye, what makes effective teams  is a mix of  strategy, team dynamics, communication, and multifunctional commitment.

“Clarity on the company’s strategy is extremely important in creating an effective team. Very high level strrategies are very difficult to comprehend in regards to the work. Communication is very important: it is the alignment between what we say and what we do. We have to reinforce and embody the goals we have,” says de la Haye.

“Where I used to work, people might say ‘We were going to the factory today. And that meant the developers sitting in a big room. But the word factory is a bit misleading. These guys are not blue-collar workers. They are highly educated and they are much more intelligent than I am. They are intelligent individuals with lots of ideas, which I want to nourish.

Agile Empowerment

“With communication in mind, what we are also doing is lots of measurement and making it very visible,” says de la Haye. “For example in our room, I have a chart showing the quality of our software  to the team, showing how they’re doing. That contributes to the notion of quality and effectiveness in the team.

“Then there are the dynamics of the group. We use Agile development, which means that we deliver every second week to the business side. The business side may say, ‘We don’t like the feature. We don’t like the colour.’ I don’t care what they say as long as what we produce fits their needs. And because the iterations are very short, it’s very easy to change it.

“Another key factor is empowerment of the team with Scrum. We have a huge board with sticky notes and colours. It might say that a particular feature is required, at a very high level. And then they decide who’s doing what. I’m not even part of that discussion. These guys are very bright and know what they’re good at. I do have some control mechanisms in place. We measure quality and I measure the amount of what they deliver. I don’t ask my developers, ‘Can you tell me how many hours you were working?’ because they are not very good at predicting the amount of hours. But what they are very good at is predicting the complexity based on complexity points. And the complexity points tell me how much time something will take.

“I had this phrase, ‘Quality is cheap,’ and I had some arguments with people over its meaning. What is says that ‘If you do really really good work, the rework that you have to do, which is really more than doing it properly in the first instance, you will be able to reduce that rework.’ And that has to be reinforced. If we hire people, we hire people who like quality and are quality driven and that’s very important as well.

Commitment to quality

“We have multidisciplinary teams. And we have expertise areas, but we don’t have experts. An expert is someone you put on a pedestal and nurture. Someone with an expertise area is willing to broaden that knowledge but also is able to pick up other knowledge. In the Scrum team, we have developers and senior developers. That’s it – no architects, senior architects, enterprise architects. And a healthy turnover is very important as well. For us, it’s about 10-15%. You need new blood in your team once in a while. We are not consultants, so we are not doing cutting edge stuff. But we’re not lagging behind either. So you need to replenish your team with the knowledge that’s available, and that’s very important to the team.

“The final area is the commitment. If you have all these areas well in place, you have a team that is very committed. Committed to quality; committed to our overall goals as a company. They all understand why our company is there. And it’s not to make money. They are empowered and result-oriented. And one of the things that gets me lots of credit is that I give them lots of learning opportunities. We have a budget for our developers  and what we used to do was send them away to the US, to California to a conference, that kind of stuff. And the value that came back was not that much. They may have had a great time, but that’s not the commitment I’m looking for.

“So now I say, ‘Take two weeks in the office. Come in whenever you like. Leave whenever you like and do something you think is interesting for yourself. And after those two weeks, show the team what you have been doing. Hopefully it’s innovative and hopefully people learn from it. It’s not something we need to apply. We might; we might not. But it should be a learning experience for you.’

“At RIPE NCC, we’re not top heavy on mobile applications. And it’s not an area that we need to go into. But we had this guy whose ambition is to work for a mobile operator in a couple of years’ time. And so he created a mobile app for us. I’m not scared of losing him because I expect that turnover anyway. The guy is very committed to his job because I take him very seriously. I help him get to the next level. So he might stay for the next six months and if I really need him he will come back. It’s all about collaboration with my teams.

“My strategy director said ‘I keep going to these strategy conferences and I’ll see the same people the same time over and over again. And they tell me stuff that I already know about because of publications etc, and there’s not much value.’ So then he went to a conference for surgeons which he admitted was way beyond his league. And he said it was so interesting to see this different world, that he actually took away more from a conference with surgeons than those strategy meetings he went to for years and years. And that gave me the idea of just letting these people do what they want to do. It’s not a done deal that they have to spend their two weeks in-house. But most of them do. It’s not that we don’t send them to conferences. I might send them anyway.

“There is a correlation between value delivered and the commitment to what they do and feeling part of what they deliver in Agile development. They have these regular check-ups with the busines and it’s very nice if you build something for two weeks and ou present it to a business person and they are sitting there with a big smile on their face, because he has exactly what he wanted and he never had that before. There is a correlation between happiness, commitment and Agile development.”

SIG pointed that three of its clients which all delivered four or five star software quality had followed a Scrum-like approach or had adopted Agile principles. Scrum teams tend to be more cohesive because they are empowered: they have to do it themselves. They decide amongst themselves what to do to deliver the right product.

Remote working or co-location

In contrast to other IT working environments, there is little or no remote working in RIPE NCC’s software development, says Haye.

“We have everyone here in one environment, which helps create some trust, and understand who in the team does what. Then once they understood each other, then perhaps there’s some leeway for remote working.But first they had to establish the trust.”

“I think it depends what type of work you do,” says Kevan Hall. “I’m a big corporate person.  The only area where I see the big global multinationals moving back to co-location is in very intensive R&D groups, such as the auto industry, because they seem to be unable to manage distributed R&D. One of the big challenges in distributed research teams is serendipity. It’s the bouncing off and the ideas and those kinds of things.  You can do that when you get people together and you can to a certain extent do it through a conference call, and videoconferencing and WebEx and things like that.

“But even in an open-plan office, if you look at how far apart people’s desks are, that affects how often they just spontaneously talk. Anything up to ten metres, you talk. Anything beyond ten metres, forget it.”

Too much teamwork

“It may be shocking, but I actually spend quite a bit of my time trying to discourage teamwork, because one of the things in the kind of organisation that is distributed or  global is that teamwork is really expensive.  It requires people to be accessible in the same time, if not the same place. and for global teams, there isn’t a right time to do that. It’s also very expensive.

“So when the cost of something goes up, the demand for it should come down. But because we’ve got this almost unthinking attachment to teams for everything, it hasn’t. And when we ask people how they’re spending their time, they tell us they’re spending two days a week in meetings, and they get 60 emails a day, 85% of which is irrelevant. We’re just sharing too much stuff.

“I used to be in manufacturing and if somebody told me we were producing 50% scrap, we’d have had a really sharp discussion about the future of that factory.  But we routinely accept 50% waste in collaboration. We have to be much more selective about when we use teams.”

1 Comment

Posted in Campaign4Change, software development, software quality

Tagged , , , , , , , , , ,

Coalition responds to Administration committee’s “Recipe for rip-offs” criticism of Government IT

Posted on 28/03/2012 | 2 comments

By David Bicknell 

The Coalition has responded to the Public Administration Committee’s January follow up to its report  “Government and IT – “A recipe for rip-offs: time for a new approach” which was published in July 2011. 

In a Memorandum to the Committee, the Government said it welcomed its interest in and support for government Information and Communication Technology (ICT). It insisted that “ICT is vital for the delivery of efficient, cost-effective public services which are responsive to the needs of citizens and businesses.

“The Government’s ICT Strategy set out how the Government ICT landscape would change over the current spending review period, and included 30 actions which form the foundation activities for achieving the Strategy’s core objectives of: reducing waste and project failure, and stimulating economic growth; creating a common ICT infrastructure; using ICT to enable and deliver change; and strengthening governance.”

It its responses to the Committee’s recommendations, the Government said the following:

Oligopoly of large suppliers and benchmarking

Committee Recommendation:

The Cabinet Office’s commitment to benchmarking through transparent data, as outlined in the Government’s response, will help to quantify the gap between high and low cost products and services, but without the independent external advice which we recommended to identify reliable cost comparisons, the overall outcome will not change, and the Government will not achieve its cost reduction agenda.

Government Response:

Government is committed to creating a fairer, more competitive and open marketplace from which it buys its ICT services and solutions. Government is in the process of breaking the contractual lock-in which places the majority of government ICT business with a small group of major systems integrators.

This process will remove exclusivity from the contracts, and rigorously record every contractual breach. It will also gather data centrally on the performance and pricing of all suppliers to provide a consolidated view of their competitiveness and performance.

In parallel, Government is consulting on new frameworks that will enable more agile procurement, and open the market to more Small to Medium Enterprises (SMEs). Some existing frameworks are not in alignment with government policy, and are limited to existing large suppliers.

These frameworks will be deprecated in favour of new frameworks that support re-introducing greater competition into the provision of ICT goods and services. Doing so will remove the current advantage enjoyed by the existing large supplier base in order to re-establish a truly level playing field.

The recent work to restructure the current ASPIRE contract demonstrates how government is working to ensure better value for taxpayers, break up large contracts and create opportunities for new, smaller companies to enter the market.

HM Revenue and Customs (HMRC) and the Cabinet Office negotiated with the IT supplier, Capgemini, to deliver a significant restructure of the current ASPIRE contract and savings for HMRC. The new deal reached will lead to a diverse supply chain with transparent pricing (removal of the current exclusivity agreement), open choice for HMRC and significantly enhanced value for money. By 2017 the new deal will help deliver:

  • Cost savings: £200 million saved by paying less per unit of IT services provided and potential for further savings by open competition, volume reductions and direct relationships between HMRC and subcontractors;
  • More freedom: HMRC will now have more control to run open competitions for its IT needs, enabling more opportunities for innovative SME suppliers and greater control over the volume of work going through the contract;
  • Greater transparency: transparency in pricing is enhanced further to assist with value for money comparisons; and
  • Future Model – a future model that breaks lock-ins and gives HMRC the flexibility and control to drive its own savings and innovation.

Government is working to improve the quality of its ICT management information. One example of substantive progress is the recent G-Cloud framework which requires all suppliers to openly publish full details of their pricing (see http://www.govstore.net/).

In addition to this transparency, the pricing levels achieved for provision of these services are being used as benchmarks against which incumbent suppliers are being measured. Government expects all supplier costs to be reduced to match or better these benchmarks, producing substantial cost reductions.

A project is also beginning to gather information on contracts data for all current ICT suppliers and departmental benchmarking of ICT unit price data. The unit price benchmarking will build on a tool established within HMRC which, following a year of use, provided HMRC with a detailed breakdown of costs relating to IT and helped the department realise many benefits including £24m savings and a 30% reduction in the number of confidential desktops.

The National Audit Office has recommended that the tool be rolled out further across government. This project will provide the opportunity to benchmark across government, and also enable external independent reviews to measure comparability with private sector peers.

The Government’s intention is also to publish as much of this data for public scrutiny as possible. It is looking to embed this approach in its handling of all its large suppliers, including software developers.

The Government will also shortly be announcing a new memorandum of understanding with Oracle that will show how its new, commercially aware, intelligent customer approach will deliver financial and significant operational benefits.

Legacy systems

Committee Recommendation:

We are not convinced that the Government‘s approach to legacy systems properly addresses the underlying issues. At the very least, the Government should produce a long term risk-register identifying where and when investment will be needed to migrate and replace existing legacy systems.

Government Response:

The Government has recognised the challenge it faces in delivering services with both new and older systems. It is right to ensure that departments have a range of credible options regarding the choices they make about their legacy systems. Different circumstances will require different options.

Departments, which understand in detail both the business functions provided by their systems and the technical constraints that act upon them, are best placed to determine the appropriate option. All departments will be producing plans to show how their systems will conform over time to the Government’s ICT Strategy principles, objectives and standards. These will be subject to challenge and co-ordination to ensure that they result in a viable plan for Government as a whole.

All major commitments to expenditure, whether in “wrapping” legacy systems to enable their continued use or in implementing new systems to provide the necessary business functions, will be subject to appropriate spending controls and approvals.

Assessments at this stage will take account of relevant factors including value, cost, budgetary constraints and risk.

Capability within Government

Committee Recommendation:

We welcome and endorse the Government’s acknowledgement of the need to grow its capacity in commercial skills of procuring and managing contracts, not just technical IT skills, in order to become an ‘intelligent customer’. Specific training for the Senior Civil Service in technology policy will also be welcome, as will the growth of a network of ‘champions’ of agile development. However, it is not clear from the Government’s response to our report that its actions will be adequate to cope with the scale of behavioural and process change required across the whole of Government, nor that the agile ‘champions’ will have sufficient seniority, expertise or support.

Government Response:

The Government recognises that raising commissioning and procurement skills is vitally important to get better outcomes for the taxpayer and to stimulate growth through public procurements, including greater use of SMEs.

It has already developed new LEAN standard operating procedures for central government underpinned by training available for all civil servants. It is now working on similar improvements for contract and supplier management and commissioning.

The Cabinet Office has also been piloting a two-way commercial interchange programme with industry to bring private sector expertise into Government. Civil Service Learning (CSL) is currently developing a suite of training on commercial awareness which will be available to all Civil Servants via the CSL portal in spring/summer 2012.

In parallel, the Government is determined to return world-class Project Leadership capability to Whitehall to improve the delivery of the Government’s £400 billion portfolio of Major Projects, which includes ICT projects.

In order to achieve this, the Major Projects Authority has established the UK Major Projects Leadership Academy (MPLA), in partnership with Oxford Saïd Business School, to target the SROs and Project Directors leading the Government’s Portfolio. The key focus of the MPLA will be on leadership, business acumen and commercial expertise from both an academic and practical angle and will include lessons learned from previous major projects including ICT projects.

Part of the Academy programme will involve an assessment of capability and previous experience of Project Leaders, with a tailored development plan designed for each individual. This will ensure that there is a clear picture of the capability within the Civil Service and inform decisions of where to best deploy their expertise.

The Government fully recognises the point that Agile “champions” may not have sufficient seniority, expertise or support and are working on identifying and putting in place senior Agile Leads within departments to drive and embed the behavioural and process change required to make this a success.

2 Comments

Posted in Campaign4Change, government, Government IT

Tagged , , , , , , ,

CIO behind FBI’s Agile-developed Sentinel IT project to leave his post

Posted on 28/03/2012 | Leave a comment

By David Bicknell

The US CIO behind one of the world’s highest profile public sector Agile IT projects is to leave his post and return to the private sector.

Chad Fulgham, CIO at the FBI will leave next month having overseen the creation of the FBI’s Sentinel case management system. Sentinel replaces the FBI’s outdated Automated Case Support system, with the hope that it will transform the way the FBI does business by moving it from a primarily paper-based case management system to an electronic work flow-based management system of record with enhanced data sharing capabilities.

“When I was hired as the CIO, it was understood Sentinel was going to be one of my top priorities,” said Fulgham. “Today, I can tell you the software coding is done, the new hardware is in place, and it has been quite impressive during initial performance testing. We have trained hundreds of FBI special agents and employees, and it will have a lasting impact on this organisation.”

In a press release announcing Fulgham’s departure, the FBI said that “using a progressive Agile software development methodology, partnering with industry, and employing an aggressive deployment schedule, Sentinel is scheduled to be implemented in summer of 2012.”

The US Inspector General recently issued a report into the use of Agile in the Sentinel project. You can read the report here

The US magazine Information Week has also covered the story

Lifting the lid on Agile within a public sector IT project

Leave a comment

Posted in Agile, Campaign4Change, CIO, Gateway reviews, Government IT, IT projects

Tagged , , , ,

Bridging the divide: an engineered approach to IT projects

Posted on 06/02/2012 | Leave a comment

The State Auditor in California recently criticised a planned high speed rail system between San Francisco and Los Angeles because the project suffered from critical, on-going oversight problems. In this guest blog, Bob Evans, founder and Managing Director of TestIT Software Assurance, explains why it is critical to have a ‘single source of truth’ for any IT development, to provide the required level of cohesion, discipline, control and transparency that should be expected from any engineering project.

The risks associated with developing or changing IT systems are well documented. IT failures always bring despair and reputational damage to all involved.

Do you remember the scene in Blackadder where General Melchett suggested that walking slowly (again) towards the German machine guns would be “the last thing they’d expect” – and so “that’s what we’re going to do”? This seems to be the attitude found in many IT procurements. What’s needed is a fresh, radical and innovative approach, especially in these changed times where senior management focus is on delivery and cost.

Keeping Control

Establishing and maintaining control of an outsourced project is the single, most important part of IT development; it is imperative for the purchaser to remain in full control at all times. In all of the failure scenarios that we have researched, it is obvious in every case that control has been lost, with always calamitous consequences.

The nature of the procurement process and inevitable time pressure means that the requirements of a new software system aren’t always well-defined at project inception. Typically, specifications are incomplete or ambiguous and put together from a range of disparate sources, with non-existent internal process and control. The “silo” attitude that is often encountered across departmental organisations is usually a key factor here.  Requirements that are not made clear at the start of the project will inevitably lead to confusion, delays, additional cost and even to dispute.

And if a contract is awarded on the basis of a flawed specification, the chosen vendor is in a strong position to justify delays and ramp up the costs. When planned schedules are missed and costs spiral out of control, well intended remedial actions can then create new, unforeseen problems, leading to even more rework.

The culture of care and diligence found in many traditional engineering environments is sometimes lacking in the IT industry and in our experience, engineering discipline is usually the first casualty when pressure is applied. Very quickly, the focus shifts to fire-fighting and a project loses sight of its objectives. It’s like building a bridge – but when halfway across, only fitting every other bolt.

 Contrived Tests

It’s no surprise that applications that have seemingly passed an Acceptance Test, when deployed on a live system, prove to be problematic. Validating the effectiveness of an IT system is typically a contrived process – put simply, tests are designed to pass! They would be – they are usually designed, controlled and often even run by the software vendor.

If you were buying a used car from a local garage, you’d get the RAC to come along and check out the mechanics. You wouldn’t even think of asking the mechanic who worked at that garage to do the inspection would you? But invariably this is the case in IT.

As discussed above, it is imperative that full control of the project remains with the purchaser. But without, continual up to date feedback and independent metrics, it’s hard to know what’s really going on. And the critical decision – when to go live – cannot be made with confidence.

Agile Development

The concept of Agile Development has been round for many years. However, it is still to be seen whether this approach can really work on a large, complex project. A properly managed set of sprints – with precise objectives, proper controls and diligent, independent validation at appropriate times may indeed lead to a more rapid and successful conclusion. However, it should be noted that as development continues, the needs of the business will necessarily change. If controls are not adequately maintained, no process – not even “Agile” ones – can keep up. What is delivered is what the vendor believes is required, rather than what is actually required by the business. And no matter what methodology is used for developing software, at the end of the development cycle it is essential to verify, independently and thoroughly, that the product meets the needs of the business.

The Agile Manifesto focuses on “working software over comprehensive documentation”. Documentation is of course often cumbersome. However, minimising the amount of information while maximising the value of the information is what’s really needed.

When it’s too late – and organisations end up mired in a legal dispute, we’ve been called in to play the part of the pathologist. It is soon apparent that the project was doomed from the start – no spec, no metrics, no control, no hope. Suppliers who didn’t listen, purchasers who didn’t actually know what they needed in the first place.

But there is another way. The Maritime and Coastguard Agency recently used independent software assurance to ensure success of its high-profile CERS/SVD project. There was an acknowledgement right from the start that requirements were bound to change and controls put in place to manage this. There were efficient, timely tests – not at the project end, but continuous tests, right from project inception. There was an approach that asked:  “What can we do given the available time and budget?”, rather than the popular “one-shot, whistle and bells” approach. And there was pro-active searching for and identifying issues early on – when the supplier was still on site – which meant that remedial actions were fixed by the supplier, at no additional cost to the project. Independent, constantly updated metrics also meant that the Maritime and Coastguard Agency stayed in complete control.

It isn’t rocket science. But for IT projects, the discipline driven by an engineering-based approach is generally more likely to lead to success. That’s why bridges get built – and IT projects often don’t. 

TestIT Software Assurance

Leave a comment

Posted in Agile, Campaign4Change, change management, Government IT, IT projects, managing change, managing outsourced services

Tagged , , , , , ,

As Agile as a John Deere tractor

Posted on 27/01/2012 | 2 comments

By David Bicknell

Thanks to Rally Software’s Agile Blog for a pointer to a Computerworld post about the use of Agile development at the tractor maker John Deere & Co.

It seems that John Deere has moved 800 software developers into an Agile development process  in around a year.

This involved recreating the company’s software development effort around new teams that included developers, systems engineers, customer support and marketing personnel, testers, all working closely together.

It is ironic that although  John Deere’s software development work is incremental through an Agile approach that is designed to deliver speed, innovation, quality, customer focus and teamwork,  the company’s actual move to adopt Agile as a development philosophy was more of a Big Bang approach than an incremental one, and was partly designed to overcome any resistance.

2 Comments

Posted in Agile, Campaign4Change, change, change management

Tagged , , , , , , ,

Some good IT project news from America

Posted on 26/01/2012 | Leave a comment

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.

Leave a comment

Posted in Agile, Campaign4Change, government, Government IT, managing change, public sector, US Government

Tagged , , , , , ,

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

Posted on 11/01/2012 | 2 comments

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

2 Comments

Posted in Agile, Campaign4Change, change management, IT projects, managing change, project management

Tagged , , , , , ,