When to Agile and How much to Agile – that is the question

Photo by aftab

Agile is gaining more and more popularity compared to plan-driven software development approaches. There is a strong community push in favor of agile, and truth be said agile has quite a few advantages. However, a couple of questions needs to be asked. Should all projects use agile methods? To what degree should a particular project be agile?

In the book Balancing Agility and Discipline the authors Barry Boehm and Richard Turner take a look at the opposite ends of the agility spectrum. On the one side we have plan-driven methods that prescribe detailed up front analysis, a lot of planning, engineering and detailed documentation. Prominent examples of plan driven methods are Cleanroom and Team Software Process. On the other side of the spectrum we have agile methods that prescribe less up-front analysis and formal documentation, focusing instead on the creation of business value in smaller steps (called iterations). Popular methods for agile software development are XP and Scrum.

Using risk to balance strengths and weaknesses

The authors conclude that plan driven methods and agile methods both have their strenghts and weaknesses. As these methods may have complimentory advantages it may be difficult to select the right approach for your project. In most cases they see that projects would benefit from a hybrid between agile and plan-driven, meaning that you should

incorporate both agility and discipline in proportion to your project’s needs

In the book the authors recommend using risk to guide our choice concerning how much we should lean towards agile or plan-driven methods.The key question to answer in finding the right balance is:

How much [up-front] planning and architecting is enough?

I inserted “up-front” into the quote to firmly illustrate that agile doesn’t mean no planning and no architecture. Up-front should be interpreted here as “before actual development has taken place”.

Identified risks

Identifying the risks that we should take into consideration in order to make a balanced decision between agility and discipline is the next topic of the book. The authors have identified the following risks:

Size This refers primarily to number of personnel. The number of persons that works on a project very often correlate to the amount of code written. Therefore a related measurement of size is KLOC (how many thousand lines of code). This is a very rough measurement since one line of code could perform a lot of logic or very little logic, be complex or simple. Despite this shortcoming the KLOC measurement of size have been used in a study that concludes that large projects can reduce their length by up to 25% by spending more time up-front on architecture, analysis and design.

Criticality A projects criticality is a measure of the consequences when a project fails. The more that is lost when a project fails, the more critical the project is. Loss of lives are at the top of the scale and loss of comfort at the other end. The authors claim that more critical projects require more up-front planning.

For critical projects I personally think that testing is just as important (if not more important) than up-front analysis, design and planning. The agile way of handling a critical project would be to trust the team to arrive at a good solution, but also to verify that it is correct. Creating the right tests and verifying that these tests are correct does require some time, but in my experience testing is just as important in agile as in plan-driven methods.

An aside: I have a small problem with this way to measure criticality since it is negative. Isn’t a project that makes it possible to earn a lot of money critical? Or a project that makes it possible to save a lot of lives? The risk then becomes losing the opportunity to e.g. save a lot of lives.

Personnel This factor refers to the skill of the people involved in the project. To measure skill levels the authors use Alistair Cockburn‘s Level 1-3 (based on the three levels of understanding in Aikido: Shu-Ha-Ri). The authors argue that agile development requires more skillful team members than plan-driven methods. An important note here is that skillful team members are necessary in both cases, but that agile requires a higher percentage of the team members to be skilled.

Dynamism Dynamism refers to the number of changes in a project. If the percentage of requirement changes per month is hight, agile methods should be favored. Such change can come about for several reasons, e.g. that the business persons changes their minds about things, or due to requirements that are emergent rather than specifiable. I think this is a very good way to see it, but please also consider that agile methods often practice a freezing of requirements. So, when you use agile methods you would normally not allow changes to the requirements during an iteration.

Culture The culture of the company or organization is a very important aspect to consider. In this case the scale goes from thriving on chaos to thriving on order. The order or chaos we are talking about here is weather or not people in your company prefer clear priorities and mandates as opposed to many degrees of freedom to get the job done. The more a company thrives on chaos the more suitable an agile methodology is. I do however think that there is some middle ground here. Getting some degrees of freedom within limits seems to be a popular choice. In that case you do not necessarily need a lot of up-front project-specific planning, but would benefit from understanding strategic consideration and some kind of proactive governance.

Visualizing your project’s risk profile

Balancing Agility and Discipline (click for a larger image)

The diagram above (adopted from the book) shows the five scales described above. If you map your project onto this diagram and end up dead center then an agile approach should suit you fine. If you end up only on the opposite end of the scales you would do well to consider plan-driven methods.

Other possible risks

I have been thinking about other risks that could provide important input when deciding between agile and plan-driven methods. The risks presented in the book may resonate with a wide audience and many projects, but I believe that can be said about other risks as well. Here is a short list of some other such risks.

People churn The percentage of people leaving. In some projects or companies people, and therefore knowledge, tend to stick around for ages. In other cases, we know for sure that people will not stick around. A common example of the latter is when your company hires consultants to do the job. More people churn would favor more documentation, meaning that it leans more towards the plan-driven approach. However, specification by example has become very popular in agile projects. It is an elegant way to document your system in a way that guarantees that your documentation is up to date.

Time to market Seriously, all companies want a short time to market – don’t they? Well, yes – but they want short time to market in different ways. In some cases they want the whole project to be completed ASAP, in other cases they may want a part of the project to be delivered early on and the rest at a later point in time. If you know for sure that you want to deliver a part of the project as early as possible an agile methodology may come in more handy.

Interconnectedness This refers to the number of external systems or APIs that your software must connect to. When it is connected to a lot of other systems you may have a lot of complexity to handle just in interacting with these other systems. Also, this is a sign that multiple teams may be working together in parallell or more likely on different time schedules. This requires a great deal of coordination and is in favor of a more plan-driven approach.

Innovativeness The more inventive or innovative a project is – to me this means it is very experimental – the more important it will be to be able to redo stuff. Planning a lot based on assumptions that may change altogether is not a very good idea. In this case agile development is your best friend. On the other hand, if something has been done multiple times before you may be able to plan in detail what to do – and you may also be able to stop bothering yourself and your company and just buy some COTS software instead of developing the software by yourself.

Conclusion

The kind of risk that you identify can help you determine how agile you should go. Just as important is the fact that the identified risks also can be used as guidance as to what kind of up-front architecture, analysis and planning you need to do. E.g. if you have multiple teams working together – it may be a good idéa to plan for coordinating the teams so that they can work relatively independently from one another. If you interact with several different external APIs you may need to plan for and test those interactions some more.

This way of working also supports another important principle: It is way better to build your method up than to tailor it down from a huge method monster. When you do so you can combine aspects from agile as well as from plan-driven methods. These things are also discussed in the same book.

About handling risks

Making all decisions at the time when ignorance is at it’s peak (at the start of the project) doesn’t seem like a good idea as it can add a tremendous amount of risk. On the other hand, refusing to make decisions early on when you actually do have some information to act on can also add a lot of risk. Ideally we would make all decisions with perfect timing; when we know a lot and have enough time to avoid trouble or take advantage of opportunities. We all know that this is very difficult and sometimes even impossible. A lot of the risks out there are unknown, the worst of those are called unknown unknowns – things we don’t even know that we don’t know about.

A very good risk handling technique is to reassess, that is improving your guess using whatever you have learned since you made your last guess. If you want to try this risk handling technique one key to success is to reduce the amount of work necessary in order to reassess. The more work you have done when you want to change things, the more work you have to do to actually get the change done.

When it comes to handling unknown unknowns agile shines!