Category Archives: Experience

Reports from practical experience

What do I do When … ?

Posted on by

A few years back I did a big agile roll out and I asked people for a list of the things which might upset the agile software delivery process. Although I asked for Agile Gotchas the team actually came up with was a set of questions on "What do I do when … ?".

I’ve answered many of these questions in my big articles on Agile Project Management but I’ve decided to put a bit more focus on them. So, in a new series of monthly posts, I’ll answer questions on the theme of What do I do When.

I have some questions in mind but I would also welcome other questions along the lines of What do I do When … ?. If you’ve got a suggestion please drop me a line or add a comment.

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 →

Agile Infrastructure

Posted on by

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 →

Side Bets and Sweeties in Organisational Change

Posted on by

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

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 →

Requirements: State the Problem not the Solution

Posted on by

We all do it. Even those of us, like myself, who should know better do it occasionally. But it is wrong. Or if "wrong" is too strong a word, then it is at least misguided.

What is it? It is the habit of stating a solution when we should be explaining the problem. This habit isn’t confined to a specific role; I’ve seen all members of the team do this … users, product managers, project managers, business analysts, technical architects, developers, user experience designers, testers, and management stakeholders.
Continue reading →

Case Study: Motivating a team using Agile practices

Posted on by

A while ago I did some consultancy with an Israeli company that was kicking off a large, complicated and challenging project. They wanted advice on how to motivate the team so I looked in my toolkit – both Agile and general management – and suggested a few things.

It is worth emphasising that the company’s sole concern in this case, and the reason for my engagement, was "motivation" and not Agile per se.
Continue reading →

Foot in the Door Technique

Posted on by

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 →

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 →