In 2004 some people met to define what agile project management should mean. In February 2005 they published a statement called the “Declaration of Interdependence” (DOI). According to David Anderson (Kanban and the DOI), one of the signatories, the intent was to:
A common English phrase is:
Don’t put all your eggs in one basket
English proverb
This is sensible advice and is really suggesting a risk mitigation strategy (see Risk Management). The proverb, fairly obviously, means don’t put all your resources (money, time, energy) into the same activity, just in case that activity fails. Or, put another way, avoid single points of failure. Or, to use another common phrase, keeping your options open.
This advice applies in many situations and at many levels. For example:
The Royals apply this advice in their efforts to have an "heir and a spare" to ensure succession.
At a more mundane level a sensible share portfolio has diverse investments to reduce the risk of failure of any one.
As my main interest is programmes, portfolios and projects I’ll concentrate on the last examples.
Continue reading
I have moved the website and blog from Joomla to WordPress. WordPress is simpler, with a cleaner user interface, yet has better functionality out-of-the-box. Apologies if anybody has any bookmarks which are now broken.
I was on leave for a week and when I got back I found a new flip chart was on the wall.
Critical Success Factors when we release:
Kelley Hunsberger interviewed me for her article “Change is Good: For agile projects, redefining scope isn’t such a creepy thing”. It is great to see agile thinking in a mainstream project management magazine such as PM Network. And the article was a very nice little summary of why it is good to embrace change.
I took the opportunity to reiterate some of the points I’ve already made on Agile Project Scope and Agile Change Management, namely that all projects experience changing requirements and it is better to embrace this than fight it. For example legitimate sources of change include:
Ignoring any of these sources of “scope creep” would be foolish.
Continue reading
Today a new project manager, somebody running one of my work streams, asked to put her risks on my programme risk and issues log. She didn’t really want to but apparently she’d been told to do this by her organisational masters outside the programme. I told her not to. Why? Because I use the log for the programme not the sub-projects. Since I had to explain my thinking to people in the company I thought it warranted a blog entry.
Continue reading
I ran a massed prototyping exercise with my current team. The whole team: development, user experience and design, testing, product management, business analysis, programme/project management and the programme director. It was a concerted effort to get a solution covering everything. The idea was to build wide not deep. The requirements for the end to end workflow was a generic operating model we’d developed previously. Microsoft Sharepoint was the underlying platform so this exercise concentrated on “out-of-the-box” solutions based on Sharepoint.
I allocated a week for this so the cost was quite high. On the other hand I expected considerable benefits. I expected “Build it in a Week” to enable us to:
As programme manager I thought it worth the cost.
Continue reading
I was asked by a corporate Programme Management Office (PMO) to provide a glossary definition for “Agile”. This is the definition I gave them.
Continue reading
I’ve worked in a variety of organisational settings including matrixed and non-matrixed. Based on this experience I thought I’d write up a few observations about organisational structures.
Traditionally companies have been organised into functional teams. More recently, partly as a result of Scrum and Lean for Software Engineering, companies are moving to departments containing cross functional product teams. Some organisations have a mix, for example, design might be a functional department but other departments might contain product teams. Other companies try to combine function and product into a explicit matrix structure. This ensures both product and function are represented on the management team.
Continue reading
There are a variety of terms in use for chunks of functionality that are worth releasing and the requirements that describe them. Desirable characteristics for these features include being minimum, releasable, and valuable. At the moment I am using the phrase Minimum Releasable Feature (MRF) so I thought I’d explain why and some of the alternatives.
Continue reading