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.

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?

Electrify! Not always a good thing, but in many projects, it might just be what the doctor has ordered. A lot of projects are just too long when it comes to really make people enthusiastic about it. So, what will make the project go ‘bang’, just the way we want it?

Add young people. This is, as many eighties series show us, a very simple action. ‘Young dogs’ in our project can give a lot of energy to the people already in it. Let the older and more experienced persons show off their skills and can give some fresh new insights in ways of designing and developing. It can take the tunnel-vision away.

Shorter iterations. Of course, obvious. But when faced with some dreadful deadlines, even the most dull project can regain new energies. Deadlines are there to keep, so everyone needs to step up.

The bell. Not always, in all teams a success, but sometimes ringing a bell can make people a bit more competitive. This can be achieved in more than one way. Not only ringing a centralised bell in the middle of the development room when a user story is finished, but think about other means. Like winning a dinner with your girlfriend when you’re the first to finish in a sprint cycle.

Are there any more way’s you can come up with to electrify the project-team? Any idea will do, nothing is too weird!

Within IT, and the rest of the world for that matter, we tend to think in orders of cost. How much money, effort, or any other measurable amount will something cost us. There are a few problems with that. First of all, within large companies and governments we’re not talking to the budget owner. Second, the people that might be the budget owner, don’t have to pay for it themselves (besides the very rare occasion where you’re talking to the owner of the company, or a partner). Third, money, in this context, doesn’t mean much, it’s like air. Within projects we always have a budget, but it’s not always fixed.

There’s a pretty easy way of making users, project actors or budget owners aware of money within your project. Don’t ask them how much it will cost, it’s a ‘non-question’. Instead, ask them how much it’s worth to them. You can do this over the entire project, to examine the value within the project. But also on particular features or specifications.

One of the lovely things about Scrum, is that we don’t have to ask these questions. We simply add parts of functionality on the board as user stories, and ask the project owner to make a selection from these stories for a sprint. Simple, isn’t it.

But during analysis and design of any software system there’s always this simple question: ‘What’s it Worth?’.