You should vet proposed features of a product and, at a higher level, complete projects. A quick and light weight way of doing this is with the 10 questions of the Opportunity Assessment.
Continue reading
Software Craftsmanship should be Professionalism and a Dedication to Improvement
This is the last post in my series on software craftsmanship. I thought I’d end the series with a brief summary and recommending a (new or just different) definition for software craftsmanship.
Continue reading
Three Options When the Boss Changes Priorities Mid-Sprint
So your boss comes to you mid-sprint and demands a new oscillating-email-ingest-engine. Right now. Nothing else is higher priority.
Scrum says “Say no”. I think the discussion is more nuanced.
Continue reading
Rugby is a Better Analogy for Agile Delivery than the Scrum
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
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.
A Lean-Agile Perspective at the Project Research Institute (part 2)
Last year I wrote a series of blog posts for the Project Research Institute of Athabascau University in Canada. As I mentioned before the PMI’s aim was to introduce their relatively mainstream audience to an Agile perspective. My aim was to show how the principles and practices of Lean-Agile Software Development offer creative solutions to general project challenges.
The PMI has now published all of my posts, including:
Programme Management: Build capability, Roll it out, and Deliver Business Benefit
Some people view programme management as simply the management of multiple projects (see for example Johanna Rothman: Defining Program Management and How Agile Helps).
Although programmes often comprise multiple related projects this definition, for me, misses the real point. As I see it programme management involves three things: building capability, rolling it out and, most importantly, delivering business benefit.
Is Software Craftsmanship a Type of Martial Arts?
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
Nine Common Strategies for Managing a Growing Defect Backlog
In response to my request for questions along the lines of what do I do when … ? Jo asked:
What do I do when the defect backlog keeps growing with low impact (and low priority) defects and nobody seems to pay attention to them as we have more important features (or medium/high) priority defects to deal with? Should we deal with it or just stop logging low impact defects?
Faults are an inevitable part of software delivery. I only briefing touched on managing lists of faults in Agile Project Execution so it is well worth expanding on.
In fact defects is an area where software delivery, including agile software development, can get messy. Luckily there are ways to manage this mess or to avoid it altogether. Jo’s question hints at potential answers but there are others. In fact I know of at least nine common strategies for managing a growing fault list.
Continue reading
Reporting Success Stories Alongside Formal Benefits
Ever since I read "Made to Stick" by the Heath Brothers I’ve been a keen collector of success stories about my programme.
As the programme manager I have to report on the progress of my team. Risks, Issues, Budget, Milestones, Financial Benefits, Reach, etc, etc. Lots of numbers and facts. Terribly significant and rather dull.
So, to spice things up, I also report on success stories.
Continue reading