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:
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.
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
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
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
Apologies for the recent outage. My hosting provider scheduled an upgrade to the server and broke the site at the same time. Normal service has resumed.
In part six of my series on software craftsmanship I have a look at how software craftsmanship is sometimes portrayed as an apprentice’s journey up a guild heirarchy to the elevated rank of “master”.
Continue reading
A few years back I did a big agile roll out and I asked people for a list of the things which might upset the agile software delivery process. Although I asked for Agile Gotchas the team actually came up with was a set of questions on "What do I do when … ?".
I’ve answered many of these questions in my big articles on Agile Project Management but I’ve decided to put a bit more focus on them. So, in a new series of monthly posts, I’ll answer questions on the theme of What do I do When.
I have some questions in mind but I would also welcome other questions along the lines of What do I do When … ?. If you’ve got a suggestion please drop me a line or add a comment.
I’m worried about Raja. Unless I do something drastic he’s going to die. In a rather messy and unpleasant way. Crushed by the weight of a 60 person-year software product.
But I think I’ve got a solution. Cucumber might well save Raja from his gruesome fate.
Continue reading
In part five of my series on software craftsmanship I look at the definition of software craftsmanship presented in the book by Hoover and Oshineye (2009). Their definition is wrapped around the concepts of community and values. Nice embracing terms but what does that mean for software craftsmen?
Continue reading