I recently had the pleasure of meeting with Casimir Artmann and feature as a guest on his “Architecture Corner”. We talked about agile and why it is necessary. Read more here on the blog or watch the video:
Continue reading
Tag: agile
4 myths about software development productivity
Guest appearance on Architecture Corner
Sometimes #noestimates can’t help you predict the future
Should you distrust agile?
Software Development Success
[bibshow] Software development success is organization dependent. Which organizations are successful in developing and delivering software? Which projects will be successful? That is a crucial question in an industry with an annual turnover of over 400 billion USD and only a 50% success rate. [bibcite key=”citeulike:4540645″] Is it enough to…
Agile projects requirements breakdown structure
In Agile projects, when a set of requirements are received from Clients, it may consist of (a mix of) A few needs, objectives, goals and some partial stories (even though it would have come in a structured document). Re-organizing (re-arranging) those into a requirements breakdown structure (RBS) helps ask right questions to…
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…
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.
4 myths about software development productivity
Guest appearance on Architecture Corner
Sometimes #noestimates can’t help you predict the future
Should you distrust agile?
Software Development Success
[bibshow] Software development success is organization dependent. Which organizations are successful in developing and delivering software? Which projects will be successful? That is a crucial question in an industry with an annual turnover of over 400 billion USD and only a 50% success rate. [bibcite key=”citeulike:4540645″] Is it enough to…
Agile projects requirements breakdown structure
In Agile projects, when a set of requirements are received from Clients, it may consist of (a mix of) A few needs, objectives, goals and some partial stories (even though it would have come in a structured document). Re-organizing (re-arranging) those into a requirements breakdown structure (RBS) helps ask right questions to…
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…
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.