Tag Archives: project management

Planning poker is a first step towards improved agile estimates.

Improved Agile Estimates

Do you need improved agile estimates? If your agile process is heavily reliant on effort estimates, then chances are that you need to have the best possible estimates. Are your estimates already as good as they can be or do you need improved agile estimates?

Continue reading

Agile is not About Laissez-Faire

Many people and companies think of Agile as some kind of Laissez-Faire approach to project management and software development. Agile is in fact a very rigid structure on how to do things so that there may be flexibility in what to do.

Agile project management is based on advanced project management concepts such as earned-value management (EVM) and phased rolling planning.

Agile software development is based on continuous quality control, other practices that are known to generate quality and a tight feedback loop with stakeholders.

An ant hill
Newton wood has some huge ant hills - this is one of them. © Copyright Brian Henley and licensed for reuse under a Creative Commons Licence, click image for details.

There is no grand master plan or architect for an ant hill. Ants simply follow simple behavioural rules. The ant hill emerges as a result of millions of ants mindlessly following these rules.

Benefits of Kanban

In a recent, well written but smallish study, a team of researchers from Finland have tried to find where KanBan has benefits. In their setup, teams of master students were instructed to use KanBan in their software development projects and then interviewed about their subjective perception of the benefits of KanBan. For a full description of their research methods, please read the original article.

The Findings

What the researchers did find was at least some support for the following effects of KanBan:
Continue reading

Waterfall, Agile and the Construction Industry

When people ask me to explain the difference between agile and waterfall methodology I usually give an analogy based on the construction industry:

The Construction Industry as “Waterfall Heaven”

  • When you are building a home it is often quite possible to know in advance exactly which steps to take and in which order. You simply cannot start with the roof, continue with the walls and finish with the basement. You cannot apply the wall paper before the walls. Furthermore, you can easily predict how much time is required for applying X square meters of wall paper, or Y roof tiles etc. There are manuals available for project managers containing a wealth of data on standard work and its cost etc. In effect, it is possible for a competent construction project manager to create a plan for a project like this and to follow it with no small chance of success.
  • In software engineering on the other hand, things are a lot more difficult to predict. You cannot know in advance how long it will take to implement requirement X. This is because you are not assembling house number 1000 in a long line of identical houses. The whole idea of software engineering is to take something which is more or less unknown and transform it into something well known. So while designing the software is not really a predictable process impressing it on a CD and shipping it is.

Risks Levels Have Increased

Well, it turns out that the construction industry is not all that predictable anymore either. According to Everts et al. a lot has happened in the construction industry in recent decades. Where there used to be 70% of construction taking place on virgin land at the edge of the city with relatively predictable conditions there is now 70% of construction taking place in already built-up areas with of course a much higher level of unpredictability. Also, at least 50% of construction work is not new buildings but repairs, remodelling and the like. Working with old buildings is naturally much more prone to surprises, just like working with old software…

Tightening the Waterfall or …

So far, the response of the construction industry have been to increase bureaucracy by generating more paper work for incident reports, change requests etc. If you are in the software industry, you will recognize this instantly…

… Move to Agile

Everts et al. takes things one step in another direction by surveying which skills would be needed and/or are lacking among construction project managers and building project managers in order to be able to work in a more agile way. They lists skills such as:

  • Negotiation skills
  • Cultural awareness
  • Conflict management

Conclusion – Not a Waterfall any Longer

Skills which are equally useful for a software engineer or manager! And that’s not all. With smart buildings the software component of the construction work is increasing. Intelligent building of intelligent buildings will be a new and major challenge for the construction industry. I guess I will soon have to switch to another example when I want to explain under which circumstances a non-agile project management style is most appropriate.


Project Failures

In my inbox today I found a link to an article about what constitutes success and failure in software development projects from a supplier perspective. While the authors were able to find three project success criteria from their systematic literature review they were unable to find failure criteria… The three success criteria were:

  • Customer satisfaction
  • Short and long-term business benefits

Their final conclusion – that knowledge of what constitutes success or failure from a supplier perspective is limited – is very interesting. Perhaps the suppliers themselves are unclear about what constitutes a success or failure, especially in the eyes of their customers?


There are many types of backlog items.

Agile Requirements and the Agile Backlog

In agile projects we are supposed to keep everything we will do in our backlogs. The things we keep in there we call backlog items. With the help of releases, iterations, epics and stories we structure them into a work breakdown structure (WBS). Are backlogs enough to cover the complexity of building a major piece of software? In this essay I take a look at backlog items versus agile requirements. Continue reading

How to Fail as an IT Purchaser

Yesterday Computer Sweden revealed how a consultant company had managed to win a bidding competition for providing IT consultants the Swedish social security agency (Försäkringskassan). Their idea was simple, lower the price for many types of consultants to SEK 1 (sic!) / hour while maintaining normal prices for other types so that the average price was far lower than their competitors.

Unfortuneately for the client this does not mean that they will be able to benefit from the low prices promised by the company. According to critics there is a number of ways that the supplier can fail to deliver at the promised price without breaking any contract. For instance, they can say that consultants of type X in category Y are not available (at SEK 1/hour) but that they can provide a type X consultant in category Y+1 (at SEK 800/hour). In all fairness it should be pointed out that hhe supplier in question promises that they will play fair. Only the future will tell.

Researchers at the Simula Research Laboratory in Norway have recently published a study which is highly relevant to Försäkringskassan’s situation. In “How to Avoid Selecting Providers with Bids Based on Over-Optimistic Cost EstimatesMagne Jørgensen gives seven “anti-guidelines” for purchasers of IT systems.

  1. Invite many bidders
  2. Focus on price
  3. Do not have enough resources to evaluate provider competence
  4. Do not perform a reality check between the received bids and that from an independent expert
  5. Do not provide support to bidders to understand the full complexity of the project
  6. Give information about price expectations, describe the project as small and talk about future oportunities
  7. Asking the supplier for a new bid based on a reduced scope

Let us see how many of these guidelines were “followed” by Försäkringskassan:

  1. Yes, by law the customer in this case is required to advertise a request for proposals.
  2. Yes, according to the article the primary focus was on price. “Försäkringskassan utformade upphandlingen så att de bolag som lämnat de lägsta snittpriserna inom varje tjänstekategori fick ramavtal.”
  3. Maybe, according to the article Försäkringskassan used a consultant to support them in the process. That they used a consultant suggests that they did not have enough internal competence. Probably the consultant could provide the required competence.
  4. Obviously no reality check can have been performed when prices which were off by two to three orders of magnitude were accepted.
  5. Hard to say anything about this guideline as this was not a request for a specific project.
  6. At least the last third of the guideline seems to have been met, according to the winning supplier they are investing in an important customer. “Vi har då valt att investera oss in i en kund som vi ser som mycket viktig.”
  7. I would say that this guideline is not applicable here.

Out of Jørgensen’s seven guidelines for failing, two were not applicable, four were followed and one might have been followed. This gives a total score for following the guidelines of 90-100%.

Did agile ruin your life? These pair programmers do no seem that concerned.

Did Agile Ruin your Life?

Daniel Markham has written a rant about how many people feel that Agile has “ruined their lives”. Basically, he is saying that to these people Agile is just a new name for snake oil. Agile coaches are nothing but scamsters. The books they write are nothing but positively biased stories about their own “success”. Continue reading

Is there any real difference between Burn Down Charts and EVM?

In the September/October 2010 issue of IEEE Software Hakan Erdogmus discusses the differences between Earned Value Management and current agile practices such as burn down charts. His conclusion is that while similar these two concepts are not the same. I do not agree, I think burn down charts and all that is merely a special case of EVM.

I do agree with one thing though, calling the budgeted cost of a work item its “value” is a misnomer.

Do I have a healthy test suite?


With TDD etc we are all assuming that we have a healthy test suite. Now some researchers from the Netherlands and Belgium have published a way to actaully measure this. Their idea is to plot

  • on one axis the percentage of the total code base that is test rather than production code and
  • on the other axis the test coverage.

In a healthy project, they argue, the coverage should increase or at least not decrease while the test code percentage grows or does not decrease.