Consultants don’t get Beach Time
[bibshow] As a consultant and contractor I should be able to spend a lot of time on the beach. But I don’t. I work long days. I spend a lot of time on work related travel. I often have late night conference calls with colleagues, partners and customers in other…
Change is the only constant in agile
[bibshow] How much change can a project withstand before it is too much? A requirements change rate of above 20% is probably too much [bibcite key=”citeulike:13415962″]. Typical rules of thumb figures for software development requirements change rate is cited as 1-3% [bibcite key=”citeulike:321639″]. But the rate of change is accelerating.…
Can you trust agile software development?
[bibshow] As a consultant [bibcite key=”citeulike:13415391″] and as an agilist [bibcite key=”citeulike:9846510″] I have a vested interest in trust. Trust might be seen as one of the top two factors for success in software development projects [bibcite key=”citeulike:2824986″]. Most of us have a vague idea of what is needed to…
Software Effort Estimation Problems
Software effort estimation is an important part of the daily lives of many software professionals. I have joined the #noestimates debate on Twitter because there is a lot to learn from a discussion on estimates. I’m not ready to fully abandon estimates but I am interested in discussing where, when…
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.
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…
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:
- Start with your user stories + other backlog items then FOR EACH
- 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
- Now that your item is sufficiently small, think about the worst case and estimate it again
- Now think about the best case, estimate again
- 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.…
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.