You’ve got a product backlog as long as your arm but the system is live and operational demands keep landing on the developers doorstep. What to do?
Many development teams have to cope with operational commitments in addition to their new work. This is inconvenient but reality. Basically you need a mechanism to get operational work through the process despite high priority new development. There are a few mechanisms to enable this.
Continue reading
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
Managing Successful Programmes (MSP) is about programmes but it does have something to say about how to run the subordinate projects. And projects in MSP are not meant to be agile in any way. Although agility is encouraged for MSP programmes agility in the projects is viewed as a “disaster”. Given the people who use MSP are most likely to be using PRINCE2 this belief is perhaps not surprising. But it is not a belief I hold to.
Continue reading
Tomorrow night I’m speaking at the BBC Cardiff Kanban Meet Up on the topic of “Delivering incrementally with Agile methods”.
I’ll be presenting material from three of my blog posts:
Come along if you are in the area.
Karine doesn’t show up. She has a good reputation and was previously the product owner on a run away success. But on your project she seems quite distracted by other commitments. What she is working on is all good stuff and related to the wider programme but it means Karine often misses the important meetings with your development team. When she does turn up the team are very happy with the input she provides. They’d just like it more often. Much more often.
Phil doesn’t show up. He is a colleague of Karine and is product owner on another work stream within the same programme. Phil’s development team never sees him at all as he is entirely focussed on external communications.
Mike doesn’t show up. He’s the external customer and commissioned you and your company to build some software. He knows his business inside out but he’s never been involved in software development before. And Mike is quite busy and doesn’t often make it to your offices. When he does come in he talks to the CEO and not the developers.
I’m sure elements of these scenarios will sound familiar to you?
You’ve got a a big problem if the Product Owner does not show up to the key meetings of the Agile Heartbeat or is otherwise not engaged.
To address this problem you’ve got three options: Educate, Delegate, or Escalate.
Continue reading
Given Managing Successful Programmes (MSP) is for programme management what PRINCE2 is for project management, you’d expect to find a rather rigid process at the heart. So I was surprised to find, when re-reading the 2011 edition recently, active encouragement for agility. Admittedly this is agility in the wider sense rather than specific practices from the Lean-Agile movement but any agility looks good to me.
This post is not about how to make MSP more Agile – although I’ll make a few suggestions – but is merely a commentary on how Agile MSP is coming out of the box.
Continue reading
Agilists love a good catch phrase. You Aren’t Gonna Need it (YAGNI), Do the Simplest Thing that Could Possibly Work, and Pain Driven Development are three of them. In fact these three are different ways to say the same thing.
All three phrases are about addressing a technical problem the team might face in the future. Immature teams will immediately attempt to solve the potential problem and thus add complexity to their product. More mature teams take a slower, more considered view.
In fact Agile teams should go through these stages when considering a potential problem/solution:
That considered process is Pain Driven Development.
Continue reading
The most liberating day of my career was when I realised that, despite being responsible for the project I was running at the time, I actually controlled very little of what happened. That was the day I freed myself from the “fallacy of control”.
I can’t really control who does what. I can’t really control whether an individual does the work to an acceptable quality. I can’t control whether or not the product owner is going to change their mind about priorities. I can’t control whether the proposed technical solution turns out to be much harder than anticipated or just a dead end.
All I can really do is influence what happens in my programme/project. Spot issues quickly and react appropriately. Lean-Agile gives me the tools to do that.
Continue reading
Search the Lean-Agile literature and you’ll struggle to find much mention of vision. Agile is all about short planning horizons, releasing stuff early and often, and learning. And a vision doesn’t necessarily help with that.
My direction? Anywhere. Because one is always nearer by not keeping still
The quote is from Engleby by Sebastian Faulks (cited Good Reads) and pretty much sums up the Agile attitude. Movement is the key rather than the direction of movement. Most Agile initiatives (i.e. projects and product development) are simply about building high priority stuff now, so it is no wonder that the Lean-Agile methods are relatively silent about the future.
In contrast a programme is about organisation change and the vision helps define the future state and attract buy-in – it is a “Postcard from the future”. A clear vision is an essential mechanism for staying aligned with business strategy. Alignment is, of course, one of my three threads within Agile Programme Management. The vision should be stable; not static but broadly resistant to change. Despite Agilists desire to “Embrace Change” a radically changing vision suggests the programme is no longer aligned with strategy and hence raises the question of whether the programme should be shut down.
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