Tag Archives: project management

New Agile Teams and the Overcommitment Bear Trap

Posted on by

The most common problem I’ve seen with software development teams is over commitment. Invariably individuals and teams are overly optimistic about what can be done in a certain time period. There are any number of reasons for this including arbitrary management deadlines and the team not pushing back, the developers desire to please, and just the fact that estimating in software development is hard.

Agile development teams are just as prone to this problem as any others. Every team I have helped transition to Agile has stepped into this bear trap almost immediately. And forewarning them doesn’t help. I now see stumbling into the trap as a valuable lesson and an essential step in the process of getting more mature about software development. I don’t mean maturity in the sense of the SEI’s Capability Maturity Model, I mean maturity in the sense of growing up, being realistic and accepting the limitations in themselves, their team and the organisation.

The difference about Agile, compared to traditional approaches to software development, is that Agile offers techniques to avoid the over commitment bear trap.
Continue reading →

A Lean-Agile Perspective at the Project Research Institute

Posted on by

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.

Management on the Ground

Posted on by

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 →

Reinforcing Success in Products and Projects

Posted on by

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?

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 →

Simon’s Critical Success Factors for a Software Release

Posted on by

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:

  • Functionality – Does it do the job?
  • Usability – Does it do it well?
  • Performance – Does it do it fast?
  • Evolution – Does it build smoothly on what is already there?
  • Delivery – Is it ready on time?
  • Comms / Training – Have we told people about it?

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 →

Build it in a Week

Posted on by

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.

Expected Benefits

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:

  • understand the requirements more
  • validate the generic operating model
  • validate the emerging information architecture
  • identify technical challenges and identify if “tricky” things were in fact simple
  • demo an end to end solution (even if clunky and with caveats)
  • understand Sharepoint 2010 more, specifically understand what “out-of-the-box” means in 2010
  • identify what we can’t do “out-of-the-box” right now
  • understand each other more

As programme manager I thought it worth the cost.
Continue reading →