We’ve talked about it here before; Agile Software is not the same thing as Agile Software Development. Of course, one of the hottest topics possible these days in Agile Software Development. Recently we even learned that Agile Software Development has become the mainstream development method. But this is not why we develop. It’s just the means to an end.

When looking at Business Agility, or to be more precise Business Software Agility it has nothing to do with scrum or other development methods. It’s about the ability to change, during production and on the long run. This is where new insights (like SOA, BPM, the Cloud, etcetera) come into place.

Looking at the principles of Lean and Agile, it learns us that we should look at value and worth instead of costs. Single processes instead of bulk. Flexibility and change are key words in every lean environment. When we take a look at the principles of Service Oriented Architecture, it has the exact same goals. Software built on those principles offer organizations a framework that can change, easily.

But software build with SOA-tooling and –related technologies is not per se Agile. This is a misunderstanding. And something methodologies like Scrum will not automatically create Agile Business Software. The software has to be designed in a way that it still offers flexibility and therefore is able to change. In other words: when an Service Oriented Architecture is lousy build, despite of the amount of new technology in it, it will not be Agile. Even when the process of coming there is agile.

This does not mean that Agile Software Development is a bad thing. On the contrary, it is one of the most important parts of delivering software that the business actually needs. But we still have to focus on the outcome, not the process coming there.

Agile. Within the Software Development business we look at the principle mostly as a way to deliver functional solutions to the business. Agile Software Development. But rarely we look at the solution itself to be agile. Is this the right way to look at our business? Isn’t the solution itself the highest goal? (Which, in my opinion, is the most important principle of the agile manifesto).

When we look at the solution itself offering agility to the business, we can say that it’s a focus that only arrived to us a few months ago. Sure, in the past we have seen IT solution offering agility to the business, but that was just a coincidence, not a goal. New technologies like Business Process Modeling and, especially, Service-Oriented Architecture, not give us the opportunity to model an IT environment where the business can truly adapt change. Hence, the Business Agility emerges.

Like all IT strategies, Business Agility can be reached when looking at three elements. The first is technology (yes, this is a tech blog) which has to be chosen for the ability to support change with few changes in the technology itself. When technology isn’t able to rapidly adapt new business rules, new business processes or business users, agility within the business will never be achieved.

The second element we need to focus on is policy. Without a clear focus on delivering changes to the organization the business will not achieve agility. This is the part where Agile Software Development comes into play. But it’s not the only policy we need in order to make our business itself agile. We also need to incorporate Agile principles into the entire Enterprise Architecture stack. Not a simple and quick transition, but something that needs to ‘grow’ and ‘mature’ within the organization for a long period of time. The adaptation of Agile within the business processes (using methods like Lean Six Sigma) is one of the essential parts. As references show us, this is mostly a change of mind.

The third element is design. Even if an organization has the ‘state of mind’ to adopt agility within and the technology offers the possibilities to actually implement it in the organization, if the design isn’t focused on Agility, it will never happen. “Agility by Design”. Definitely something to think about and I will write about it soon.

Although we have traveled far since the old waterfall methods of software development, an agile approach to software barely stops at the way we organize our projects. True Business Agility isn’t gained if we don’t look at the outcome and possibilities a solution offers us when implemented.

Last week I wrote an article for one of the large Dutch newspapers following the news about a 12 million euro project gotten killed . Unfortunately the article was too specialistic to be actually placed in the paper. But that also means that I now have the opportunity to publish it here on Ome-B.nl. I will publish the original, Dutch, text and the translated, English, version below. The English version is translated using Google Translate and might not be that good.

An Opinion.

Dutch:

ICT verspilling bij de overheid.
Hoe kunnen ICT projecten bij de overheid wél succesvol?

ICT projecten bij de overheid gaan geregeld mis en verschijnen steeds vaker in het nieuws. Zo was er afgelopen week de bekendmaking dat de stekker uit een 12 miljoen euro kostend project is getrokken bij het Ministerie van Justitie. Dit is niet een losstaand incident. Het komt veel vaker voor.

De geschiedenis wijst uit dat meer dan zeventig procent van de ICT projecten meer kosten dan begroot. Een niet misstaand getal. Dit zijn echter nog steeds succesvolle projecten. Ze zijn namelijk in productie genomen. Maar wat kost dat nu eigenlijk?

Exacte cijfers zijn niet bekend. Schattingen geven aan dat er per jaar zo’n 4 á 5 miljard euro over de balk wordt gesmeten door mislukte overheidsprojecten op ICT gebied. Hierdoor wordt er flink gespeculeerd over de mogelijkheden om dit te voorkomen. Op een verkeerde manier.

De vinger wijst naar de wijzigende politiek en nieuwe inzichten. Deze zorgen ervoor dat complexiteit en omvang van de te ontwikkelen systemen toeneemt. Wet- en regelgeving veranderd gedurende het project, het systeem groeit en de complexiteit neemt toe. Maar moeten we nu deze veranderingen accepteren of tegengaan?

Tegengaan, stelt Jan Friso Groote. In de uitzending van het televisieprogramma 1Vandaag vertelt de hoogleraar informatica aan de Technische Universiteit Eindhoven dat veranderingen in inzichten de reden zijn voor de uit de hand lopende kosten van automatiseringssystemen. We schijnen te moeten voorspellen en de risico’s dekken.

Voorspellen houdt het tot in de puntjes beschrijven van de functionaliteit in. Dit ontwerp zal dan getoetst worden door een commissie die gedurende het project in de gaten houdt of het project zich aan het plan houdt. De risico’s dekken. Het project blijft groot en complex. Door controle en risico dekking zelfs complexer. Veranderingen in inzicht zijn niet langer mogelijk. Ook niet als het iets toevoegt.

Veranderlijkheid in de omgeving, zeker in een politieke, is echter een vaststaand feit. We hebben dus twee mogelijkheden. Veranderingen niet toestaan om risico’s te vermijden, of budget vastleggen om veranderingen te faciliteren. Om uiteindelijk waarde te creëren.

Doordat de totale kosten van ICT projecten hoog uitvallen zijn de eisen die aan het op te leveren product worden gesteld erg hoog. Er is de wens om alle gewenste functionaliteiten in het systeem te plaatsen. We willen, als het ware, de wereld automatiseren. Alles doen wat we willen. Hierdoor streven we vaak tijdens projecten naar een onrealistische perfectie.

Om deze perfectie te benaderen rijzen de kosten, die moeilijk zijn te voorspellen, uit de pan.

Bij de meeste ICT projecten is het merendeel van het budget gereserveerd voor voorspellen en risico’s dekken. Deze activiteiten, hoe belangrijk ook, zorgen echter niet voor enige waarde aan het uiteindelijk op te leveren product. Alleen het product voegt waarde toe aan een organisatie, documentatie en sturing niet.

Hoe zorgen we ervoor dat we wel de meeste kosten kwijt zijn aan het automatiseringssysteem zelf? Het antwoord hierin zit in twee elementen. Snel opleveren en sturen op budget. We gaan niet de risico’s dekken, maar voorkomen.

Het snel in productie nemen van een systeem houdt in dat we meerdere malen kleine stukjes functionaliteit beschikbaar maken. Niet veel in een keer, maar vaak weinig functionaliteit. Hierdoor kunnen we snel binnen de organisatie toetsen welke elementen nog moeten worden toegevoegd.

De organisatie kan daarnaast direct profiteren van de waarde, hoe summier ook, die het systeem toevoegt. Doordat de betrokkenen direct in aanraking komen met de functionaliteit is het ook mogelijk om voortschrijdend inzicht te faciliteren.

Sturen op budget houdt simpelweg in dat we sturen op de vraag wat het waard is. In plaats van wat de kosten zijn. Deze benadering zorgt ervoor dat we niet langer alles in een willen doen, maar gaan sturen op wat echt van belang is. We hebben, tijdens het ontwikkelen, altijd te maken met lastige wensen die weinig tot niets toevoegen en veel tijd en geld kosten. Deze kunnen nu makkelijker worden geïdentificeerd.

De uitingen die de laatste dagen in de media zijn gedaan over het vastleggen van functionaliteit voor het eigenlijke ontwikkelen is dus een achterhaalde materie. Het voorstel van hoogleraar Groote zal dan ook zorgen voor toenemende kosten en uitlopende doorlooptijd van ICT projecten. Daarnaast zal dit beslissingen in de politiek stilleggen.

Dit kan er alleen voor zorgen dat projecten nog meer uit de hand lopen en kosten hoger worden. De veranderlijkheid van een politieke omgeving is van essentie in ICT projecten bij de overheid en dienen juist omarmt te worden in plaats van tegengehouden. Anders leveren we alleen maar producten op met niet langer gewenste functionaliteit.

English (using Google Translate):

ICT waste in government.
How can ICT projects in government are successful?

ICT projects in government go wrong regularly and appear increasingly in the news. So there was the announcement last week that the plug from a 12 million euro project is costing drawn at the Ministry of Justice. This is not an isolated incident. It is much more common.

History shows that more than seventy percent of IT projects cost more than budgeted. A non misstaand number. These are still successful projects. Because they are in production. But what does it cost actually?

Exact figures are unknown. Estimates indicate that each year about 4 to 5 billion euros over the bar is thrown by failed government projects in the ICT field. This is significant speculation about the possibilities to prevent this. In a wrong way.

The finger points to the changing politics and new insights. These ensure that the complexity and scale of development systems is increasing. Legislative and regulatory changes over the project, the system grows and the complexity increases. But should we accept these changes or to go?

Inhibiting, Jan Friso Groote. The broadcast of the television tells 1Vandaag science professor at the Technical University Eindhoven, changes in understanding the reason for the runaway costs of automation. We seem to have to predict the risks.

Prediction takes it to the last detail describing the functionality. This draft will be reviewed by a committee during the project monitors issues or the project is to keep the plan. The risks. The project remains large and complex. Through control and risk cover even more complex. Changes in knowledge are no longer possible. Even if it adds.

Variability in the environment, especially in a political, is an established fact. So we have two possibilities. Not allow changes to avoid risk, or budget to capture changes to facilitate. Ultimately create value.

Because the total cost of IT projects fail, the high demands on the product set to deliver very high. There is the desire for all the desired functionality into the system to place. We want, as it were, the world automate. Do whatever we want. We aim at projects to an often unrealistic perfection.

For this perfection to approach raises the costs that are difficult to predict, from the pan.

For most IT projects, most of the budget reserved for predicting and risks. These activities, while important, does not provide for any value to the final product to be delivered. Only the product adds value to an organization, documentation and guidance not.

How do we ensure that we have lost most of the costs to the automation system itself? The answer lies in this two elements. Fast forward and deliver on budget. We do not cover these risks, but avoid.

The speed of production of a system means that we repeatedly make small pieces of functionality available. Not much at once, but often little functionality. This enables us to quickly review what elements within the organization must be added.

The organization may also directly benefit from the value, even briefly, the system adds. Because those involved in direct contact with the functionality it is also possible to facilitate progressive insight.

Focus on budget means that we simply send the question of what it’s worth. Instead of what the cost. This approach ensures that we no longer want to do everything in one, but going forward on what really matters. We have, during development, always difficult to deal with demands that have little or nothing to add, and much time and money. These can now be easily identified.

The statements in recent days in the media are made on the recording functionality for the actual development is an outdated material. Great professor’s proposal will also provide for increasing costs and turnaround time leading ICT projects. In addition, the decisions in politics halt.

This can only make more projects out of hand and cost increase. The volatility of a political environment is essential in ICT projects in government and should be properly embraces rather than stopped. Otherwise, we only supply products with functionality no longer required.

Although most of us realize that projects need to get smaller. Actual small IT projects barely exist. When we look at integration and migration projects. Designing new Business processes and aligning technological solutions to mach those, we open a large number of organizational challenges.

Especially integration projects can contain a lot of misconceptions in the organization. In what domain do we actually work, is it IT of Business? The main focus should be on the Business Case for the entire organization, not on the benefits for the single actors within the project. So, here comes the question: what’s in it for me?

When we don’t share the knowledge of the Business Case with the different actors we will create an unsustainable environment within the project. Resulting in a situation where all parts of the organization (in large integration project, we always touch more than one part of the organization) only bother with the impact on their own domain. Ambiguity kicks in.

When decisions in the project aren’t gathered and shared throughout the entire group of involved actors and parts of the organization, these decisions will not be understood properly. Therefore the entire project will create a conception of top-down forced scope. Nobody will be your partner when this is the general feeling within the project. And we need those people.

Therefore it’s absolutely necessary that we all share within the project. Large integration projects have their impact within the organization and change is scary. Even though we do it with the right intentions, it will not be felt this way.

Then. What is the solution to this? Simply create an open en interactive environment within the project. Share knowledge and perception. When all actors get their focus right (which only works of they have the feeling it’s their own focus) the goal of the project comes in sight. For all involved.

In most Enterprise Architecture frameworks the Business Architecture drives the Information Architecture.

But is this completely accurate? Didn’t we gain some new insights over the past few years. Information, and especially technology (or IT) Architecture can drive the Business Architecture, creating new and previously unimagined possibilities for organizations.

Modern IT isn’t anymore about offering the structure businesses can build upon, but more and more about offering insights in the way new technologies can create opportunities and thrive business. We talked about this principle before, it’s the ‘new CTO’ versus the ‘old CIO’. Both approaches are necessary in the modern organization. IT is helpful, but it also can actually push business.

This is exactly why IT and Business Alignment is a necessary, but outdated thought. It is time we start thinking with one, common goal in mind: the values set in the Business Architecture, the why, what, who and how of the organization.

Yesterday evening, my new Whitebook about Agile Enterprise Architecture (see here, in Dutch) got published. In this Whitebook I pointed out that developing Enterprise Architecture is a Two Way process. And that it should be build Agile.

First of all, a Business Case should be leading in the choices that are made in the architecture. This is, simply, because we look at architecture from a project point of view. A project start architecture needs to be the beginning of a project, but measured against the organization. This is exactly the problem I encounter on a near daily basis: Enterprise Architecture made too big and becoming an ideal picture instead of an realistic and facilitating process.

Enterprise Architecture basically needs to describe the Business processes, the information demand, the applications overview and the technical grounds. This is the blueprint on which we can build our system. But how can we make sure we don’t overdo it? Simple: make it Agile.

Agile Enterprise Architecture works on the same principles as Agile Software Development: the Agile Manifesto. When we understand these principles, building an architecture for our project and organization is made a lot simpler: look at the stuff we actually need right now, don’t over document the process and let people be the basis of knowledge.

In other words: Agile Enterprise Architecture is a Two Way process in which the entire group of stakeholders is leading. Therefore it starts with the basics: why do we need it. (and what don’t we need, eliminating waste.) In Agile Enterprise Architecture there is room to learn and adjust, because we don’t do everything at once, but listen to what all stakeholders have to say: what can IT learn from Business, and the other way around.

The principles of Agile Software Development are known to most of us, but how we put them into action can be the tough challenge. At the second session I had on CreativITy at the Fontys school for Software Engineering in Venlo we discussed the possibilities to make Value the steering point within the project.

After a short recap on the previous session we started off with the dilemma we encounter in IT these days, talking about the classic Cost versus Risk model on which we use to steer our projects and where the money goes doesn’t work, value isn’t measured. Using the new insights in Agile development and Enterprise Architecture, value is one of the key points: where will the business benefit most.

During the last part of the session we discussed the new possibilities technology can offer to business values these days. How can we switch from servicing to innovation? Agile thinking sure helps here.

“Fear and Complexity within a project, can be an explosive mixture that makes sure any project can fail.” According to the experienced agile project manager Martin van Borselaer Fear and Complexity are the main project killers. “Fear restrains us from doing or saying the things we know are right”, Martin says during a great session he gave the company last week. “It is, in combination with complexity, the main reason projects fail.”

Fear, from the different actors within the project, can have different sources. The customer can be afraid that the project will cost too much, the quality will be bad or that he works with the wrong requirements. The supplier has it’s own fears. Under budgeting the project, dissatisfied clients, damage to his reputation or unsatisfied co-workers. A project manager can have fears like a bad functioning customer organization, team or technology he has to work with. And the team member is possibly afraid that the balance between his private live and job comes into question.

“There are also deeper fears to consider within a project” Martin tells, “you can think about things like the livelihood of the employee, loosing his job, not making promotion”. ”Or more emotionally based fears like the ego or status of actors in the project” Martin explains. “Fear is a very bad advisor in a project situation. It can offer a excessive reaction by making problems larger than they really are, or no reaction at all by denying the existence of a problem.”

In projects this can mean that we work with fixed date, price unknown scope projects, excessive analysis and design or not being able to grasp reality and therefore sticking to the original plans without necessary adjustments. Martin explains that most of these examples are based upon actors being afraid, offering false hope. Working together, not looking at the team in terms of heroes and losers, is an essential part of the solution. Transparency in the project team will facilitate mutual trust and therefore a real team where fears can be tackled.

Another project killer is complexity. “Simple is Stupid and Smart Sells are main criteria these days in IT projects. Or, at least, it seems to look that way” Martin says. “The assumption lives that we can control and predict this complexity, but the reality is that we can’t.” Martin explains that, during the start of a project we don’t know what we want and that we don’t know how to get there. Working together and steering on new insights is the only way of getting on a point where we want to be.

Working together, small steps and learning and improving are essentials to tackle both fear and complexity within a project. Organizations that know that change is to be expected and understand that steering constantly is normal will have the competitive edge. It’s essential that scope is put together on functionality, not by expertise. Bringing together expertises will reduce fear and complexity. Or at least make them more understandable. In this way we can actually manage them.

Martin van Borselaers blog is a very interesting place of knowledge on Agile project management, you should read it.

UPDATE: Martin now offers a once in a lifetime opportunity: you can get his advise, for one day, for free! So if you want to have a fresh look at this project of yours or more information on how you can do things different or even better, look on the (Dutch) Whitehorses website for more information.

At this very moment I’m waiting to give one of my lectures at Fontys Hogeschool on Venlo. A long drive, so I got here early. One of the things I’m going to talk about are the missteps in Software Development, and project especially. One of these missteps is that we tend to think that we need to Predict, Guard and Control our projects in order to make them successful, while this is exactly why things go wrong.

In the classic approach to software development, we like to think that there’s unforeseeable risk involved. That we need to predict the outcome of the project and guard that change is not an issue. In this approach, using extensive Architecture, Analysis & Design and Processes like Request for Change using boards and advisories. Why is this? Do we have so little fate in our own skills?

When we take a look at what we actually are doing in a project, predicting, guarding and controlling is very strange. Because we are trying to make ideas, thoughts and vision concrete. We build stuff that on forehand only exists in the mind of some.

Thoughts and vision change during time. We gain new insights and other people share their knowledge. This is exactly why software development projects need to be based on a change facilitating manner, not trying to avoid change, or make it more difficult.

Software Projects don’t have a great success factor. According to some, this is because projects are too big, not measured right or simply didn’t have the right steer on it. These factors can all be true. But there’s more to it. Maybe even simpler. Most successful projects have been seen like a success from the moment they started. It was predefined, they where steered with one thing, vision.

But what is this thing we call vision? And more specific: what is it in a software project? A vision isn’t just one thing, it’s two: the Why ad How of your project, shared throughout the entire project team.

The six basic questions: We’ve mentioned them before. The six basic questions in analysis are essential to know where the vision may be found. The answers to those questions can, however, be different for all the actors (and therefor factors) in the project, it can only become a vision when the answer are, somehow, aligned to each other, when the entire team and all actors share the same motivation on the project.

SIx degrees of Why: This motivation of the project can be specified by simply asking ‘why?’ six times after. This sounds more simple than it is. Simply start by asking why a project is necessary, why we are doing the project. If the answer is unsatisfactory, keep asking it. If a project has a clear vision, six degrees aren’t hard. But if the project has it’s soul ‘Why’ on ‘Because’, it’s a clear sign that there it no emotional attachment to the project.

The essence of How: in the end, Software Projects need to address the Why. It’s that simple. If the technology, design or any other aspect of the ‘How’ are not clear, the success rate will be at least as bunkers as when the ‘Why’ isn’t clear.

Emotional Attachment: both the Why and How need to be emotionally attached to all actors in the project. For the Why it means that we need to search for something that all parts of our team can feel in their guts, something that makes us tick, shake and rumble. This can be something that needs to be addressed because it affects us all or something so wild, we simply want it. In the How part it’s simpler: make it cool, awesome, jaw dropping. In software development we all like to be part of something amazing.

All the above have a certain ‘vagueness’ over it. This is because it is. It’s as simple as that.

Do you have an example of a project that became a great success because both the Why and the How where shared throughout the entire team?