Category Archives: Musing

Reflections, observations or just musing on something that sparked my interest

Managers v Leaders: Are Managers Plodders and Leaders Cool?

Posted on by

I consider myself a good manager and a passable leader. This should be okay but there is a certain anti-manager trend in the business world that is particularly prevalent in the Agile community. For example it has been common for Agilists to say "We don’t need no stinking managers " (Esther Derby: Rethinking Managers Relationship with Agile Teams).

It seems that leaders are somehow more cool than managers. Conventional wisdom says "Managers do things right; Leaders do the right things" (Buckingham & Coffman, 2001). And Jim Highsmith (2009), one of the Agile gurus, makes it clear that Leader = Agile and Manager = Non-Agile. Ouch.

Agile leaders lead teams, non-agile ones manage tasks.

Highsmith (2009) cited by Scrum Expert

All of which makes self-labelling as a "manager", particularly an "Agile manager", rather risky. But before I go off to find a job as a leader, for which I’m possibly under qualified, I thought I’d take a look at the differences between leaders and managers and assess whether common wisdom is, after all, very wise at all. To do that I’ll outline what a couple of other people say about managers and leaders and how that marries up with my own view.
Continue reading →

Declaration of Interdependence

Posted on by

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:

  • define a value system by which modern 21st Century project managers should live and
  • galvanise a community around general application of agile project management

Continue reading →

Putting all your eggs in one basket

Posted on by

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:

  • Royal succession
  • Personal investments
  • Infrastructure
  • Portfolio management
  • Programme or Project contingency
  • Technical design

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 →

Change is Good for Agile Projects

Posted on by

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:

  • The customer learns as they see working functionality emerging of the development effort.
  • The technical team is also learning as they discover what works.
  • The environmental context might also dictate changes, such as changes in the market or legislation.

Ignoring any of these sources of “scope creep” would be foolish.
Continue reading →

Programme versus Project Risks

Posted on by

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 →

Using a Product Led Matrix in Lean-Agile

Posted on by

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 →

Minimum Releasable Feature

Posted on by

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 →

Two Pillars of the Lean Thinking House

Posted on by

The Toyota approach to lean is quite sophisticated and is based on a model called the Lean Thinking House (Larman & Vodde, 2009). The Toyota model includes two pillars:

  • Respect for People
  • Continuous Improvement

These pillars struck a cord with me.  I’m normally more interested in what practices work than in values and principles however these two phrases seemed to nicely summarise my approach to work and are key themes in my career.

References

Larman, C., and Vodde, B. (2009). Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum. Addison-Wesley.

Difference between programme, project, portfolio and product management

Posted on by

P3M stands for "programme, portfolio and project management". Product management is a closely related discipline and as most software organisations do product development I’ll include it in the discussion.

P3M Levels: programme, project, portfolio and product management

P3M Levels:
programme, project, portfolio
and product management

That bit is simple. The tricky bit is agreeing what a project, product, portfolio or programme is. Projects and products are pretty straight forward but definitions vary quite a lot for programme and portfolio. A portfolio for some people is a set of products where for others it is a group of projects. I have, for example, met a portfolio manager who was responsible for some projects and within the same division met a another portfolio manager who was responsible for the product portfolio of the entire division. Programmes are sometimes seen as simply as a complex project or set of projects, or, more interestingly, as an initiative to deliver business benefit.
Continue reading →