During the last year I have spent a lot of energy on recruiting project managers. I was looking for something specific and although I spoke to a lot of project managers, some of whom came highly recommended, it took a long time before I found what I was looking for.
Having spent a fair bit of energy on this, I thought I’d write up what I believe makes a great project manager.
Continue reading
As I’ve said before the most common problem I’ve seen with software development teams is over commitment. If worse comes to worst you get to the end of the spring before realising the problem. But you don’t have to wait until the end of a sprint to take corrective action.
Taking Corrective Action mid-Sprint to address Over Commitment
What I didn’t mention is that more mature teams are likely to spot what is going on earlier.
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 product backlog is not complete and we still want to deliver our product on the agreed date? It is hard for the Product Owner to prepare a complete feature backlog and for developers to estimate the required time in order to get a realistic burndown chart during the sprints. The product backlog is kind of dynamic.
In response I’m going to look at three states for the product backlog and strategies for managing backogs when in each of those states:
The first of these states is, well, normal. You never know everything about the scope. You just have to manage what you do know.
The other two states suggest something is going wrong in the product management space. And that is very much a product owner issue. The agile project manager / scrum master role is to help the product owner and/or organisation realise their problem.
Continue reading
For the last couple of years I’ve been running a lean startup within the BBC. No really, I mean it. It is indeed possible to have a successful lean startup inside a large publicly funded corporate. It is all about your outlook.
Continue reading
Daily meetings are an essential communication tool within Lean-Agile, specifically for Agile Planning and Agile Project Monitoring and Control. So if you notice that people don’t show up then you could have a problem.
Continue reading
This is what having a large number of tasks unfinished at end of Sprint looks like:
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:
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.
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
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.
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