Brian Williamson has commented that although “problem-solving is important and good when you are stuck. I’m convinced we are in need of some more purpose finding.” I agree and finding purpose manifests in several places in my approach.
Continue reading
Tag Archives: project initiation
Nine Things to do When Nobody on Your New Team Knows Lean-Agile
Last month I looked at what to do when everybody on the team says they know Lean-Agile. This month I look at what to do when nobody on your new team knows Lean-Agile.
Continue reading
Everybody on your new team says they know Agile. Don’t believe it
Early in my Agile career I was the only person on my team who knew anything about Agile. Now everybody claims to know Agile and/or to have Agile experience. Certainly this has been true for most people on my last couple of teams. My advice to you is – don’t believe a word of it. Assume they know nothing.
Continue reading
No space to co-locate team – think again
I knew I had a big problem when I walked into the new programme space and found 18 desks. 18 wasn’t enough. I predicted I would have about 35 people on the team and I wanted them together. Co-location is so important to me that I will always challenge the assumption of “there is no space”. And I have found there are lots of things I can do to get my team together.
Continue reading
Programme Organisation for Software Delivery
I thought I’d share the way I organise programme teams. I’m interested in software delivery so I’m talking about programmes that have software development at the core. Non-software programmes would have a different structure and mix of roles. I push Agile but the same organisation would work with a less nimble approach.
There is nothing mysterious or radical about my programme organisation. In fact it is entirely in keeping with the guidance from Managing Successful Programmes (MSP). If you didn’t know Organisation is one of the nine Governance Themes from MSP.
Although I tend to apply the same shape to all of my programmes I do adapt it to local conditions. The size of the team makes a big difference so I’ll show how I have organised large, medium sized and small programme teams. I’ll also take a quick look at a poor structure for a programme team – with role based teams – and explain why I don’t fancy it.
There are obviously other ways of structuring a programme team but this is what has worked for me.
Continue reading
Benefits Map: Impact Mapping for Programme Managers
Gojko Adzic has recently published a great book on a technique he calls “Impact Mapping”. Gojko’s Impact Maps are a visualisation of the business drivers and the associated project scope. This means the people doing the work (developers, UX, testers, etc) know what to build but also why they are building the functionality, how the functionality fulfils the business outcome and and who the functionality is for. Love it.
As it happens Programme Managers already have a very similar tool for a similar purpose. Benefits Maps, like Impact Maps, are used to visualise business drivers and associated scope, in this case programme scope. They answer two key questions:
- Why are we doing the programme?
- How will we realise the benefits?
The dual function – showing why and how – make Benefits Map high value documents. It also means a Benefits Map can easily morph into the initial Programme Blueprint. For a simple programme the Benefits Map may be the only Blueprint. And the diagram format means it fits on one page. Even in a world where we value “Working software over comprehensive documentation” that one page is worth having.
Continue reading
A Clear Vision is Essential for Agile Programme Management
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
Opportunity Assessment – 10 Questions to Evaluate Proposed Features and Projects
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
Reinforcing Success in Products and Projects
A fundamental military axiom is to reinforce success.
Reinforcing success is a strategic concept used in many areas of decision making and management. Originally a military doctrine, the term is also used in theories related to parenting, business and other fields. It is essentially a selection criterion, or a prioritizing principle. A course of action is selected from various options on the basis of previous results of similar actions. The basic idea is: if it works, keep doing it; if it doesn’t, don’t invest more in something that’s failing.
Wikipedia: Reinforcing Success
I believe businesses should apply this principle to projects, products and product features. So not surprisingly I apply this as a guiding principle in my own work as an agile programme manager.
Continue reading
Two Types of Post Implementation Review
Recently people at work have been asking my advice on how to run post implementation reviews of major programmes so I thought I’d write up my thoughts. I believe there are two types of post implementation review and I recommend doing both. The first type happens in Project Closure and the second happens after the project has finished, i.e. Post Project.
Continue reading