“How to spread the successful way of Agile working to make more and more IT projects in the Dutch government successful?” was the title of my session on the first day of the Agile Open 2010 conference.
Everybody knows those news items about failed IT project of the Dutch government. Over budget, over time, never finished after millions of Euro's were spend, ...
What are common causes? What are possible solutions? What are the first steps we can take to reach the goal “make all government IT projects successful”? A group of Agile Open 2010 participants shared their knowledge to answer these questions. Here are my notes of this session:

Causes

• Everybody is a contractor
  • The government doesn't have enough skilled people
  • The contractors are the ones with knowledge, so they need to be kept hired
  • A lot of contractors try to earn as much money as possible, so they try to extend the project.
  • The governments says: There must be less civil servants (NL: ambtenaren) to save money.
    • But the work still needs to be done / the governments still wants the work to be done, so they hire contractors

• Biddings (NL: aanbestedingen)
  • ARVODI terms (ARVODI voorwaarden) aren't agile.
    

    The ARVODI terms bring a lot of risks to the contractor. Only with the waterfall method the contractor is able to mitigate his risk. But the waterfall method doesn't mitigate many of the governments risks, like: wrong specs, extension over extension of the project before working software is produced, only discovering that the project did not bring what was needed after a lot of money already has been spend, etc... And it doesn't offer the government the fast feedback loop and steering possibilities that Agile methods bring.

    There are new terms, the ARBIT terms. They are better, but still aren't good. Besides that, governmental organisation units still use the old ARVORI terms on IT biddings.

  • "All" requirements up front.

    In the current bidding system the buyer makes a long list of all the requirements that need to be realised. That is what the contractor should make a bidding for. That requirement list will be part of the contract.
    That list is always vague, what does the buyer exactly want for the requirement "management information"? Is it something simple that can be made in a few hours or very advanced functionality that takes weeks to realise? One thing is for sure: nobody already knows exactly what has to be made.
    During the project the requirements will evolve. The customer gets new insights, functionalities have to be adjusted, new functionalities are added, other functionalities turn out not to be so important.
    Changes to the requirements costs extra money. So it's important to get the contract (at any price) and then try to earn as much money as possible with changes on the contract. That way of working costs a lot of money and time is wasted on contract negotiation.
    It's a pity the government still works like this, while there are much better ways to do IT projects.

  • Only minimal communication between the buyer (NL: inkoper) and the supplier is allowed.

    This is to prevent fraud, but it also prevents communication. While good communication is one of the key factors that make a project successful. How can a supplier know what a customer really needs if he almost can't communicate with him? How can a supplier let the customer know that the way they are starting the project has a high risk to fail and that there are better ways to do the project?

  • The bidding system costs companies a lot of money
    

    Making a bidding costs a lot of work (money) for a company, much much more than making an offer for a normal customer. Only one out of so many biddings is successful. So when a company finally wins a bidding, they can have the mindset: "I want to earn back the investment of all the previous biddings that weren't successful and already build up a reserve for future biddings that aren't gonna be successful." "These civil workers don't know how to manage an IT project, I can easily get more money out of this project. It's like stealing candy from a baby!" "Let's try to earn as much money as possible from this government project. It's ok to do that; to compensate for the bidding system, because they are so stupid to let it happen and besides, other companies also do it."

• Only large companies can afford / do European biddings.

Large companies often have a lot of “not highly skilled employees” (juniors and mediors), so the government projects are done by “not highly skilled people”. If there are too many “not highly skilled people” on a large IT project, then the project probably won't be very successful.

• The IT projects are too large
  • Very large IT projects where they want to do a lot at once have a much higher risk of failing.
  • One reason that there are too large IT projects, is the bidding system. 
    • All the overhead of biddings aren't worth the effort for a contractor if the project isn't large enough. So to find contractors, projects need to be big.
    • The bidding laws make don't allow government projects to be split up in small projects.

• Culture
  • I don't want to take the responsibility.
  • I don't want to take the decision.
  • Not making clear agreements on who is responsible for what. Afterwards we can all say "it wasn't my responsibility!" / Afterward I can say "It was his responsibility, not mine!"
  • I don't care how much money it costs.
  • Passive. "I do what I'm told to do" instead of "I want to reach the goal and will do everything what's necessary to reach it" (self organising)
  • Before the start of the project I want the “guarantee” (NL: wassen neus zekerheid) that I will get everything I want.

• Political goals
  • Prestige projects and other political goals.

• Audit Driven Development
  • Government demands documentation up front that needs to pass auditing before you are allowed to start making working software. This leads to the typical waterfall process problems and blocks the ability to use an Agile method (an empirical process control model).

• Lack of knowledge
  • Decision makers and executers of IT projects in the government don't have enough knowledge on how to do successful IT projects.
  • NL: Regie organisatie i.p.v. kundige mensen.
  • NL: Generatie kloof (EN: Generation gap)
  • The deluxe protection (NL: ontslagbescherming) of civil servants compared to employees in companies.
    • This leads to that some employees don't leave the government and are doing jobs for which they are not the right person.
    • This makes the government reluctant to hire civil servants instead of contractors.

• Contractors earn more money in long waterfall projects that get extended time after time to try to get working software.
• Government doesn't want too many contractors.
• Government prefers large companies as a contractor.
  • Some (departments) of these large companies try to earn as much money from the government as possible and will steal candy from a baby if they can. (NL: willen de overheid uitmelken)
  • As we mentioned earlier: large companies have a lot of “not highly skilled employees”.

• It's not allowed for one company to do the whole project.
  • First a team has to think of what should be made. Then a team of another company has to build what the first team has written down. Which causes a lot of disadvantages: the knowledge of the first team is lost, “throw it over the fence”, a long time is spend in writing documents, software is build at a very late stage, which causes a long feedback loop.

• The government copy paste each others biddings. This way the non-agile biddings are used everywhere.

• The government doesn't place suppliers on their shortlist if the suppliers has one detail wrong in their bidding, even if it's a small detail in a trivial criteria. Therefore suppliers “copy paste” their previous biddings that made it to the short list and don't dare to experiment with writing agile biddings.

(Remember: writing a bidding takes a lot of effort, so by copy pasting a previous bidding that made it to the short list, you mitigate the risk that all this effort leads to nothing.

And as we mentioned before only a waterfall method bidding mitigates the risks a contractor has because of the ARVODI terms. So why would a supplier try to write an agile bid if he can copy paste a waterfall bid?)

These were the causes that came up within the timebox.
…eh, timebox? One of the open space rules is: it's over when it's over :-). Anyways, it was time to think about solutions in the time we had left! This is what we came up with:

Solutions

• The government has to make agile biddings possible, or completely replace the bidding system by something else.

• Lean

Lean change programs can change the current bidding method of the government.

• Contractor have to do Agile bids
  • Offer the result of agile, not an agile method.
  • Offer working software on date x / for budget x.
  • Offer guarantees
  • Offer good ways of inspection
  • Offer ways to control the project (NL: sturingsmogelijkheden)
  • Offer an attractive way of coming up with new, or changing existing specification during the project.
  • Offer iterations

• Audit Driven Development
  • Talk to the Audit department, explain them what the risks of Audit Driven Development is.
  • Show them which advantages agile methods have and how you can mitigates risks with it. “Seeing is believing”

But as true Agilists, we not only inspect, we act! So we asked ourselves the question “What are the first steps WE can take?”

We decided to take the following actions:

• Start an Agile Overheid community (EN: Agile Government community)
  • The goals:
    • Make all government IT projects successful
    • Eliminate waste
    • Maximize value for money
    • Create value early
  • How?
    • Share knowledge between people who work agile within the government. By meetings and online.
    • Spread the knowledge to people in the government (incl. decision makers!) who don't know a lot about agile yet.
    • Join forces.
    • Expand the community to get in contact with the people who can change the bidding system and other things that could be improved but are out of our circle of influence.

• Start an Agile Government Tribes to share knowledge with other communities around the world that have the same goals. Just like the Scala tribes (scala-tribes.org).

• Ask the Agile Consortium for help.

• Ask the Agile Alliance for help.

And so the Agile Overheid Community and the Agile Government Tribes were born!

To be continued!!!

Near future

...I just continue right now :-)

The first steps we're gonna take are:

• Come up with a good name for the community ;-)

• Find as many people as possible who work Agile within the government or who want to work agile.
  We value diversity. So we are looking for people from high in the organization till people on the work floor, from young till old, from people with many years of experience in the government till people with a fresh mind, from rijksoverheid to gemeenten, from A to Z - let's say from Belastingdienst till the police. (I can't come up with government organisations that start with an A or Z at this moment... ;-) )

• Create a community website

• Create a tribes website

• Organize a first meeting
  • Short after summer holiday period? But sooner if possible!

How can you help?

• If you attended the Agile Open session, please give me your contact details, so I can keep you up to date.
• Help to think of a good name for this new community
• Create a logo for this new community. Or get us in touch with somebody who can do that (for free).
• Help writing the text for the community website.
• Send us links to good webpages that explain clearly, for people who aren't IT specialist:
  • what the waterfall process is.
  • what agile is.
  • what the disadvantages of the waterfall process are, and what the advantages are of agile methods.
• Share your idea's, suggestions, etc on:
  • How to make the Agile Overheid Community a success?
  • Other solutions to reach our goals besides the solutions mentioned above.
  • How should the first meeting look like? What should we accomplish? How can we do that?
• Let us know if you know civil servants who work agile within the government, or want to do that. And let them know about us.
• Let us know when you know decision makers within the Dutch government that don't know a lot about Agile yet, but will start a new IT project (soon) or are responsible for a current IT project that could go better.
• Think about what you can do to help, and do it!

Community collaboration platform

I've created a LinkedIn group so we can communicate with each other and already start expanding the community! The LinkedIn group is called “Agile Overheid” and you can get there by: http://www.linkedin.com/groups?gid=3131436

Later we'll make a community website. But as true Agilist we've realized a working solution with the most important functionallity in this first itteration of one weekend by simply creating a LinkedIn group. This way we have the most important functionallity now! Instead of all the functionallity in a long long time :-).

My contact details

If you want to help, or contact me for something else: my LinkedIn profile is: http://www.linkedin.com/in/wardbergmans

Door Ward Bergmans