Tag Archives: agile

A data repository is not a community of practice

Agile Community of Practice

I’m a strong believer in learning by doing. I also believe that learning will be better when supported by an agile community of practice (CoP). Communities of practice allow self-selected members to develop their “capabilities, build and exchange knowledge”. In my professional life, I am involved in several communities including larger associations such as IEEE and ACM but also more focused communities at work including on Enterprise Architecture, E-health and Agile.

Continue reading

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.

What is the proper size and time for an Agile Retrospective?

I often hear the same complaint about Agile Retrospectives: They are not held at the right level in the organization! Or, at least, that is the conclusion that people draw from one fact: Many issues brought up in the Retrospective need resolution at a much higher level in the organization. There is no one in the room who can address or resolve them. Continue reading

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?

Agile software development methodology.

Agile is NOT new and not enough

So people keep talking about the Agile – Waterfall dichotomy. About agile and un-agile practices. I decided to have an unscientific look at what Agile isn’t. If there is a true dichotomy between Agile and Waterfall, then things opposite of Agile should be either entirely out of scope for projects and software development or they should be characteristic of Waterfall methods. And since anyone would bother to mention them in the context of Agile, one would assume that this would be because they are distinguishing between Agile and Waterfall. Continue reading

Agile Training, Best Enjoyed Fresh

When I perform Agile Training I do it as a part of a larger Agile Coaching engagement with a customer. I do it as a directed intervention based on my ongoing diagnostic of how things are actually working at this point in time, with this client. I am a huge believer in just-in-time training or even, just-a-little-to-late training. Continue reading

My Journey towards Becoming an Agile Driver

What’s an Agile Driver? I have always been driving kind of ad hoc. Getting from A to B with no particular plan. If I were a programmer you would call it “cowboy coding” but I’m not, so we can call it “cowboy driving”. People, everyone it seemed — my boss, my wife, my children, the odd passengers — were all complaining that I needed to use sound engineering principles and state of the art equipment to improve my driving skills. “It will help you get from level 1 to level 2 or even 3 as a driver”, they said. Continue reading