Category Archives: Musing

Reflections, observations or just musing on something that sparked my interest

What is Agile Governance?

Posted on by

Personally I think good governance is essential for successful delivery, either within a programme or project, or part of on-going product development.

The recent publication of Governance for Agile delivery: Examples from the private sector July 2012 by the British National Audit Office suggests the UK government is also very interested in Agile and how it can be used to deliver value. But within the constraints of good governance.

However the term “governance” is rarely used along side “Agile”. As a agile programme manager I thought I’d try to answer the question “What is Agile Governance?”
Continue reading →

What do I do When Tasks in the Sprint Plan are not Finished?

Posted on by

This is what having a large number of tasks unfinished at end of Sprint looks like:
Over commitment burndown

Not pretty.

It is best to avoid over commitment so the answer to “What do I do When Tasks in the Sprint Plan are not Finished?” is to lower your expectations next time you go into planning. Using Scrum language you should ensure the team only commit to what is achievable, and that is obviously less than they thought was possible the last time around.

You’ve also got to tidy the up the mess left by the previous Sprint. Have a look at the unfinished tasks and decide if they are necessary for your high priority user stories. If so, then schedule them into the next Sprint. If not, then forget about them.

Finally, you have to decide what credit you can give yourself, i.e. what velocity you earned in the previous Sprint. Personally I start hard line about this. You can only claim a user story if it is completed, so you can only add the story points for that user story if all the tasks have been completed. No partial credit.

Having said that:

  • If you find that the unfinished tasks are actually unnecessary then you can claim credit for the whole user story.
  • It is sometimes possible to split a user story into meaningful sub-parts. If one of the sub-parts has been completed then you can claim the story points of the sub-part for velocity

This post is part of my What do I do When … ? series. Please drop me a line or add a comment if you’ve got a question you’d like answered.

Rugby is a Better Analogy for Agile Delivery than the Scrum

Posted on by

This post is partly about the game of rugby and partly about the agile method called Scrum. Although I’ve a lot of experience with Agile approaches to software development, including Scrum, I must confess that my experience of rugby is limited to watching the All Blacks during the Rugby World Cup. Despite that caveat the theme of this post is that rugby is a better analogy for agility than Scrum is.
Continue reading →

Use a WIP Limit During a Sprint to Avoid the Cataract of Stealth

Posted on by

Mike Lowery – a fantastic Scrum coach – has written a post called It might look like rapids, but it’s still a waterfall. This is part of Mike’s series on Scrum coaching patterns (or team anti-patterns) and in this post he concentrates on the “The Cataract of Stealth”.

Mike starts by outlining how a sprint should look: “you should see a sort of tag team effect where 1 or 2 stories are in flight, as they get close to being finished the next stories are kicked off”. In contrast “The Cataract of Stealth” means the team start too many user stories at the same time thus risking finishing any of the user stories at the end of the sprint. Often this is caused by team imbalance, e.g.. too many developers for the number of testers.

The cataract of stealth is a real problem and I recommend people have a look at Mike’s post for more detail including his very sensible solutions. (It also has shades of the Overcommitment Bear Trap.)

I just want to add one thing. What Mike’s post highlighted for me was a (small) convergence of Scrum and Lean/Kanban thinking. The constraint on having “1 or 2 stories” in flight during a sprint is work in progress (WIP) constraint – a concept straight from Lean/Kanban.

Is Software Craftsmanship a Type of Martial Arts?

Posted on by

Code Kata, Coding Dojos, and White Belt Programmers. What is it all about?

In part seven of my series on software craftsmanship I have a look at how software craftsmanship is sometimes wrapped in the language of martial arts.

I confess from the outset that the use of martial arts language really put my off software craftsmanship. But behind the kung-fu I found fairly uncontroversial practices.

I’ll have a quick look at the three software craftsmanship practices I found with a strong martial arts flavour: Code Kata, Coding Dojos, and White Belt Programmers. Then go into a more general discussion of what it is about.
Continue reading →