Identifying the challenges facing agility
May 30, 2007 by Colin Macandrew
On Wednesday 4th April I was the guest speaker at the Agile Practitioners Forum, organised by Les Oliver and Simon Voice and sponsored by Radtac and Connections Recruitment. For the third time, the venue was aboard the HMS Belfast, moored on the Thames River. The idea for this session was to build on the thinking that was done in the previous two sessions, and move the forum beyond sharing experience and into innovating new techniques to address some of the problems encountered in initiating and running Agile projects.
The forum has a high proportion of long-toothed silverback agile gorillas. With such deep and broad experience, it’s impractical to capture every anecdote and analyse them for common themes. To simplify things, the session was split into two parts. The first part of the session attempted to simply capture observed constraining behaviours, and the second part looked for the underlying motivation and drivers that cause these behaviours. The sessions were time limited. Although this meant that some behaviour would inevitably be missed, the sessions captured the issues that the forum felt most passionately about. To give a general structure to session, behaviours were written on a post-it note and stuck to the wall under these broad categories:
- Human Behaviour
- Organisation Behaviour
- Systems (Technology)
The (sometimes surprising) results from the session were:
Human Factors:
| How do we (should we) provide/allow for the inevitability of legacy and/or package systems and project management requirements in a transformation to agile (or more agile) practices? |
| Fear of change |
| Fear of failure |
| Fear of unknown |
| Fear - afraid to try |
| Shell shock |
| Commanding workers |
| Maths bigots |
| “One true way” |
| Power-hungry clipboard Hitlers |
| Command-line bigots |
| “I don’t get agile” - software religion |
| Using agile as a word to mean whatever you want it to |
| Not telling the truth |
| Psychotic management |
| GUI bigots |
| Superstition (aka expertise) |
| People not held accountable |
| People don’t take responsibility |
| Making mistakes is not ok |
| Drama queens |
| Agile threatens peoples identities |
| Specialists who don’t want to collaborate |
| Reading too many books that offer unclear direction - leads to confusion |
| Personal / political power |
| Ego |
| Dogmatism (especially agile zealots) |
| “I’ve always done it this way and I know what I’m doing!” |
| Habit |
| Communication |
| Lack of understanding |
Systems - Technical Constraints:
| Behaviour | Driver |
|---|---|
| Machines being locked down | Control, Cost reduction |
| Security gone mad | Control, Regulation |
| Tactical solutions | |
| Microsoft rules! | |
| Tool fetishes | Lust, Greed |
| Achtung torpedo!* | |
| Strategic solutions | |
| Technical debt | Maintainability, Modifiability, Developmentability |
| Workspace (office, desks, phones, headphones - no whiteboards) | |
| Legacy technology | |
| Imposed corporate standards | Regulatory, Cost Reduction, Kingdom building |
| Open vs. closed source | |
| GUI lovers | Easy life |
| Lack of environments (machines) | |
| Corporate network policies | Control |
| Root access | Control |
| Technologies that don’t lend themselves to testing | Top-down decision -making |
| Secretarial Windows builds | Control, Cost reduction |
| Software tail length |
Organisational Constraints:
| Behaviour | Driver |
|---|---|
| Management fears loss of control | |
| Fear of change | |
| Fear of failure | |
| No real understanding of what’s valuable to business | Pursuit of goals that ultimately don’t help company, e.g. personal goals or silo goal |
| Silo departments | Silo values: false efficiencies / superstition, command and control (political power, kingdom building, self-worth) |
| Product sponsor doesn’t have sufficient power to effect wider change | Distrust by management, accountability without authority - lining up a scapegoat, silo values, shielding / insulation |
| Measuring success against internal standards | Conformance to corporate culture |
| Projects in different regions with same/similar goals (duplicate effort) | Sense of ownership, kingdom building, distrust, control, path of least resistance is to do it yourself |
| Centre of power / vision in different country / continent | Control, political power, them and us |
| Decision-making is only made ‘at the top’ - no empowerment | Control, distrust, fear, ignorance, ego |
| Attitudes to waste | Short-term gain and long-term pain |
| Annual budgets | Programme justification, fear/exposure |
| Lack of slack (too much time chasing cows, not enough time mending fences) | Distrust of motives, previous buy-in pain |
| Difficult to find right people / difficult to remove wrong people | S.O.P |
| Difficulty cross-selling into rest of org | Listening to diverse view points, receptiveness to the idea of change, openness |
| Distrust of staff | Bad people, bad management, bad policies, micromanagement, fear |
| Accounting practices | Accountants = fear of change, want to lock everything down, need fixed figures |
| Method rigour vs. benefit delivered | Zealotry, pride |
| Death by committee | Responsibility, accountability - people afraid to make decisions on their own because of repercussions |
| Too many people without “skin in the game” | |
| No accountability | No empowerment |
| No responsibility | No empowerment |
| Thinking certification is the answer to finding good people | Laziness, blame, avoidance |
| Keeping agility after consultant has left | Understanding, belief, ignorance, arrogance - self-belief |
| Helping management be agile | They think agility is a techie thing |
| Contracts | Want to nail everything down, want lowest price, fixed scope for a fixed price |
| Forced offshore resource / process | Trendy, money, short-term gain |
| Teams organised by role (not cross-functional) | Ignorance, herding instinct |
| No strategy / conflicting strategy = stragedy | |
| Perceived inability to plan | |
| Office layout and changing it | Health and safety, furniture police |
| Top-down decision-making | Control, don’t trust front-line people to make decisions |
| Unimaginative organisations | Pickled, institutionalised, comfortable, “that wouldn’t work here” |
| Fixation on process / methodology | Dogmatism |
| Business user / customer not available | |
| Institutionalisation | Pickled, comfortable, maintain the status quo |
| Thinking that its possible to give a single date on which a project will be delivered | Budgeting, contract |
| Fear culture | Power = good |
| Empowerment is a threat | Fear of failure, challenging status |
| Holistic vision and buy-in | |
| Numpty IT managers | |
| Multiple corporate entities related by contracts | |
| How do you know if the process is being followed, e.g. TDD? | Understanding, retrospectives |
| Process over people | Institutionalised, control, people are automatons |
| Acceptance that quality can be sacrificed | Delivery is king |
| Decision-making not even happening at the top | Incompetence |
| We shouldn’t change - agile needs to do all the adapting | Arrogance, lack of understanding, Ignorance |
| Command and control | Habit, fear of loss of control |
| No clear vision | Poor management, no business buy-in |
| Widespread acceptance of mediocrity as norm | Laziness, easy ride, no fear of consequences, no leadership, no accountability |
| No slack in business org | Streamlining (false cost-cutting), not investment |
| So the company expects Prince2-type artefacts and these aren’t provided/delivered/satisfied by agile - what now? |
Conclusion
The results as shown have a lot of potential. With further analysis, it should be possible to convert this into some useful tests that improve the chances of agile surviving in a hostile environment. One practical thing that could be achieved is an organisational scoring matrix. This would be list of checks and measures that would show how easily an organisation could adopt agile, and highlight any potential pitfalls that should be resolved before attempting agile adoption. Part of the scoring matrix could also include a set of must-have preconditions that are necessary to avoid failure. If an organisation finds it difficult to conform even to the preconditions, then this shows clearly communicable obstacles to adoption. The matrix could also include a continuous risk analysis that gives an early warning system for when agile is going badly. This would be useful for PMs to monitor changes in an organisation that might impact their projects.
Just because I happen to find it interesting, I intend to have a go at building an agile scoring tool I could use every day. There are a lot of other uses for the results shown above. I would welcome anyone’s ideas on what else could be done with the information.
At the end of the session we came up with several topics for future discussion:
- Command and Control - what are good ways to manage strategic leadership with self organizing teams? How can you check the big picture?
- Transition to agile – what are good ways to do this? How do you know when you’ve done it?
- Sustaining agility – what make Agile stick?
- Agile metrics - can some of points raised generate metrics that can be built into an agile tool?
- Selling agility – are there good ways to do this? Pitfalls?
- Education – certification?
- Strategic agility – agile principles at board level?
We probably have enough to discuss, but here are a few more:
- Dysynergy – the antagonism that exists when behaviours work in isolation but royally screw things up when you put them together. What are they?
- Do the Agile Manifesto values and the principles it encompasses need to be refactored to take account of the issues of adoption?
- What are the good ways to manage the tension between high level commitment to objectives and low level reacting to change? Are time boxes time bombs?
- “If your not doing this, you’re not doing agile”…What’s the best way to communicate this to the outside world to stop labeling projects as agile, when they clearly aren’t?
- Do we need an agile practitioner’s charter? Would everyone in the forum sign up for all the agile principles? Which principles would you be unable to swear to and why?
- Agile bad press: It’s a cult? It’s elitist? It’s a dogma? What do we do about that?
I think another factor that needs to be considered is the quality of the people. In projects that have worked well, you’ve had teams of mixed experience (in terms of years in the industry and technology set). However, they have all cared about the quality of the work they deliver and have a can do attitude. Organisations that have average and below average staff will never get the best from Agile.
Colin’s final point 4 (when is an Agile project not Agile) seems to be something that comes up quite frequently. We need to start talking about Agile and RAD, the two are similar but different and I suspect that many ‘false’ Agile projects are really old fashioned RAD! That said, the Agile community does not want to be labelled as elitist - care is needed.