A Lean-Agile Perspective at the Project Research Institute

I was recently asked to write a series of blog posts for the Project Research Institute of Athabascau University in Canada. The institute wanted to expose their audience, mainstream project managers, to an Agile perspective. I relished the opportunity and readily agreed.

My aim with my PMI series is to show how the principles and practices of Lean-Agile Software Development offer creative solutions to general project challenges such as governance, uncertainty and complexity, under estimation and empowerment. My first post for the institute tackles this head on and I argue that Lean-Agile relevant to all project managers” simply because Lean-Agile offers a new slant on these problems. I am not advocating the wholesale adoption of Agile by all project managers. Merely to offer up a different perspective to that of main stream project management. Armed with this perspective project managers from other domains may be better placed to face their own challenges.

The first couple of posts have already been published and the rest of the series will appear over the next couple of months. If you want to follow the series on the PIR site then have a look at my blog at Athabascau. Otherwise I’ll also post updates here.

Agile Infrastructure

A senior manager in the operations area of my organisation recently commented:

There is no such thing as agile infrastructure

That got me thinking. I can imagine that adopting an agile approach to infrastructure might be inappropriate in certain circumstances, for example military or medical domains.

On the other hand my current programme needed a completely new infrastructure stack and I found a considerable amount of agility was possible through that exercise. To my way of (probably simplistic) thinking any changes needed from the infrastructure are to provide either more capability or faster capability. With that in mind I’ve found it is possible to architect for agility and deliver the infrastructure in an incremental and iterative manner.
Continue reading

Management on the Ground

You have to keep your feet on the ground when others want to put you on a pedestal. After a while on a pedestal, you stop hearing the truth. It’s filtered by the henchmen, and they read you so well, they know what you want to hear. You end up as the queen bee in the hive, with no relationship with the worker bees.

Bill Burns, CEO of Roche Pharmaceuticals
quoted in Goffee & Jones (2006), p. 43

One of my project managers recently mentioned that, despite being a programme manager, my own management style is quite "hands-on". In the sense of being on the ground with my team rather than in the technical sense although the two often come together. This approach has held me in good stead over the years.

Others, like Bill Burns quoted above, have realised dangers of being distant from the people doing the work and the corresponding benefits of being on the ground. I thought I’d take a quick look at some of these previous advocates of being on the ground:

  • Military Commanders on the ground
  • Management by Walking Around (MBWA)
  • Toyota, Lean and Genchi Genbutsu

I’ll wrap up by having a quick look at the Agile practices that help me be on the ground.
Continue reading

Side Bets and Sweeties in Organisational Change

People don’t resist organizational change!People resist being changed!

The Communication Toolbox

My current programme is using new, bespoke software to drive organisational change. So I need people to change what they’re doing. A lot of people. As a first step I need them to adopt our new software. So I am always looking for ways to push the software roll out. In an earlier post I described one approach we use for encouraging adoption: Foot in the Door Technique. In this post I look at two other methods – which we call "Side bets" and "Sweeties".
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

Managers v Leaders: Are Managers Plodders and Leaders Cool?

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

Foot in the Door Technique

My four year old daughter is an master social psychologist, or just a natural manipulator. Here’s an example:

Daughter: Can I go over to Lilia’s house to play?

Dad: Sure

… some time latter …

Daughter: Can I stay for a sleep over?

Dad: Um, I guess so.

My daughter doesn’t know it but she is using what social psychologists call the "foot-in-the-door" technique (Brehm & Kassin, 1993). The same technique is applicable when rolling out new software.
Continue reading

Putting all your eggs in one basket

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

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

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