Blogging on “Capping IT Off”

I’ve started blogging at the Capping IT Off blog. Posts there will be about topics that are off topic for this blog. My first post is about e-health innovation and apps. My conclusion? E-health will be powered by thin, targeted applications built on a stable framework.

Combining Traditional and Agile Estimation

Can you combine traditional and agile estimation? There is nothing magical about “classical” estimation. There are a few basic concepts to keep track of:

  • Bottom up versus top down
  • Expert estimation versus parametric estimation
  • Best – worst – expected case

I think the most common method for traditional estimation is to go top-down using successive estimation which means that when something is to big or uncertain, you break it down into component tasks and estimate them recursively. If you are familiar with Planning Poker you can easily combine it with this approach:

  1. Start with your user stories + other backlog items then FOR EACH
  2. Estimate it with PP, if too big or to wide spread it is an Epic. Break it down into smaller stories (this creates your WBS) and GOTO 2
  3. Now that your item is sufficiently small, think about the worst case and estimate it again
  4. Now think about the best case, estimate again
  5. Calculate the weighted average as (best + 4* “normal” + worst) / 6

Not so different from “pure” Planning Poker, is it? There are a few improvements you can do though — instead of using three estimates for each item, you could use the spread of estimates you already have from PP as a basis for your probability distribution.

Evidence Based Software Engineering

Is it possible to do controlled process experiments in software? That was the question asked in the Kanbandev group over at Yahoo groups. We need evidence to support the practices we use in software development. After all we are talking about a serious business with an annual value of about 500 TUSD.

How detailled should a test case be?

I sort of remembered a very interesting article about one-liner test cases at testzonen.se. I have blogged about it before, but perhaps it is worth repeating myself? The idea is that detailled (manual, scripted) test cases are uninteresting, limit creativity and are expensive to maintain. The solution is to create “one liner” test cases instead. What about test documentation? If testing actions are recorded during execution then the documentation can be created afterwards.

I guess this goes to show that there is no one size fits all in testing. The right tool should be used at the right time to reach the right goal – which of course is to find bugs early rather than late.

Agile is Always Appropriate

Sometimes, people tell me that “Agile is not appropriate” in this or that context. I believe that’s plain wrong. Agile, as seen from the basic principles, is always appropriate. That doesn’t mean that all versions of agile are appropriate in all situations. And it doesn’t mean that you will be sucessful just because you use agile. And saying that you are agile doesn’t mean that you are. Are you agile? Perhaps this is the source of the confusion?

To know the price of all things, but the value of none

I keep getting annoyed by how corporations are so compartementalized that income and cost are handled by totally different departments. What is the effect? The effect is that the cost departments focus solely on cost at the expense of income.

What is a cynic? A man who knows the price of everything and the value of nothing.

Oscar Wilde
Continue reading

Agile Configuration Management

I love configuration management! “But”, you ask, “isn’t configuration management boring?” Well, configuration management can be boring and tedious if you do it manually. With modern tools it is not all that bad. Even if it is boring, that is out-weighed by the sheer importance of proper agile configuration management for a successful software development team.

Continue reading

A Waterfall is Fine – for Watching

As humans we love the majesty of nature. Who can fail to be impressed by such majestic cataracts as the Niagara falls or the Victoria falls? Someone said that falling is fine, it is hitting the ground that kills you. Same thing with the water in the waterfall. When it hits the end, enormous chaos is generated both visibly as spume and invisibly in the water.

Hydroelectric Power

We do not usually try riding a waterfall in a barrel. We can harness it for electric power. But if we do, we certainly do not want to ride it in a barrel.

Agile is also a Waterfall

Two pipes, one with laminar, one with turbulent flow as in a waterfall.Source: University of Cambridge

Laminar versus turbulent flow. Image reused from http://www.ceb.cam.ac.uk/pages/mass-transport.html .

Agile software development methodologies are about breaking the waterfall into safe, manageable steps. The impact is not saved for the end in a big bang delivery. Instead it is taken one step at a time. The water does not flow as chaotically. It is more like a laminar flow.

Waterfall got it right… almost

I am not going to write a lot on waterfall versus agile but… An interesting point that is worth reiterating. Waterfall software development processes can remind us of many of the important steps in software development. The difference is not so much in what we do as in how, when and what order.

How to do Agile Version Control

A colleague asks on Yammer about how they should handle all their many branches and thousands of CI jobs. Here are some of the links that came up: