XPDAY7: Why do Agile projects fail?
At
XPDay 7,
Joseph Pelrine and
Jiri Lundak asked
why do Agile projects fail?With the wind blowing in one direction, an iceberg moves in the opposite direction. Why is that? The wind only affects the tip of the iceberg visible above the water. The iceberg's direction is influenced by what you can't easily see. The majority of the iceberg lies beneath the water and is affected by the currents moving in a different direction to the wind. Your project is the iceberg. Your visible controls - time, cost, quality, scope and resources - only affect the tip of the iceberg. There's a lot more going on beneath the surface where the project is massively influenced by emotion, culture, learning through reflection, improving through adaptation, and sharing knowledge and building a sense of team through collaboration.
They described 4 failure modes:
- Inspect and adapt gone wrong. People don't apply before inspecting and adapting. The cycle should be apply - inspect - adapt. When you learn to drive you learn lots of different techniques - how to turn, starting on a hill, reversing around a corner, parallel parking, etc - because they all work together and are known as 'driving' and you will draw on them every time you venture out and drive your car. Omitting practices is akin to "Oh when I learned to drive, I never got that whole left turn thing, so I just drive straight ahead now".
- "You can't handle the truth". People are often not able to deal with the results of the process. Everything becomes visible, good and bad.
- Using the wrong tools to solve problems.
- Interpersonal team dynamics (communication and grouping). A team operates within a socially complex domain where cause and effect cannot be predicted. It's not possible to anticipate what will influence the 'system' and, because people are non-deterministic, it's not possible to know how the 'system' will react. Only with retrospective coherence, can we look back and, knowing how things evolved, have things make sense. You're unlikely to achieve success if you focus on predicting what's above the water.
Listen to Joseph talk at CINCOMSmalltalk about the
process of software development and some of the issues that come up.
Tags:
xpday,
social complexity,
retrospective coherence
Links to this post
Well, we did our
XPDay session:
Have you compromised your agility?The run-up to the conference was a bit manic because we thought
XPDay was a week later than it actually was. Our thanks go to
Steve Freeman for spurring us into frantic action. We burnt the week rushing around buying props (coloured table cloths, battery powered candles, lollipops, etc), preparing posters and handouts, and putting together a chilled-out music playlist. We pretty much knew what we wanted to say in the session but it was delivered mostly on a wing and a prayer. Despite me getting over a cold and Gus being hungover, we thought it went reasonably well and we had lots of fun. There must have been around 60 people in the cafe, probably twice the ideal number, but it went smoothly enough. More people arrived, some turned around because we were at capacity on the tables, others stayed and formed a circle on the floor.
We wanted to do the session because we're worried about the state of affairs. We're seeing more organisations trying to be agile but, when you hold them up to the light, the standard is often poor. Agility is being compromised for corporate fit. We want organisations trying to be agile to raise their game. There needs to be both organisational change and cultural change. And we want people to expect better and do more.
We think arguments about dogmatism versus pragmatism, or one approach over another, detract from the real issues:
- Organisations value the wrong things.
- People do not maintain a high-level of craftsmanship.
- Organisations adapt Agile for corporate fit rather than to improve.
- People accept mediocrity to maintain the status quo rather than strive for excellence through continuous improvement.
- Organisations focus on efficiency and don't worry about achieving effectiveness first.
- People are not empowered to do the right thing.
Agility is partly about process and practices, and these are the parts that organisations typically latch onto, but its capability is rooted in the culture established by the values and principles and peoples' behaviour. These are often in conflict with the organisation.
In the session, each table was given a real issue to discuss. A mind-map for each issue provided a 'starter for ten' and was used to spark a debate. The IT industry is perennially failing 'the business' and while there's no silver bullet, agile approaches can, at least, help us make improvements and do better. Our aim was to hopefully raise awareness of declining standards and inspire people to help us raise the bar.
I've included the mind-maps and doodlings. The debates were engaging and pretty intense and consequently it's difficult to distill too much from the doodlings.
1. Misplaced values?
2. Adapting for fit?
3. Accepting mediocrity?
4. Doing the right thing?
5. Is the process adding value?
6. Managed or led?Only 15 people left feedback but it was the last session on the last day and everyone wanted to get to the pub. The feedback was overwhelmingly positive. 13 people said "they loved it" and that it was "a great format with interesting topics"; 2 people said it was "a good session"; nobody said they "wouldn't recommend it to others".
Here's the
poster show and here are some photos of the event:
Tags:
xpday,
compromised agility
Links to this post
XPDAY7: Embrace uncertainty
In his keynote,
Jeff Patton reminded us to
embrace uncertainty and asked if we've forgotten the meaning of iteration.
Pascal has
written about the keynote and has included some photos.
Kerry Buckley also has a good write-up. Here's an extract:
We have forgotten the meaning of iteration, and are working in increments instead. We are expecting an 'iteration' to contain a number of fully-completed stories, which we can then forget about and move on to new features. The problem with this is that when we deliver those stories, the customer is not entirely satisfied, and we have to introduce new stories to refine the design.
Iterating is like progressive prototyping and validating as you move from vagueness to realisation. Incrementing is like building a wall brick by brick. But incrementing suggests you know exactly what you want. We all know that's not true. Your notion of what you want becomes clearer over time. To help deal with this uncertainty, Jeff encourages us to:
- Follow the money back to the customer/user and prioritise business goals before stories.
- Keep options open and avoid choosing a solution too early ("a requirement is tantamount to an irrevocable decision"). Maintain bigger stories describing what users want to achieve and defer writing smaller stories that describe software until the last responsible moment, and
- Build (functional) quality iteration by iteration.
As
Johnny Rotten said, "I don't know what I want, but I know how to get it" - iterate!
Tags:
xpday,
uncertainty,
user stories,
iterating,
incrementing
Links to this post
Keep your options open
Lately, I'm talking a lot about maintaining options and deferring commitment by making small, reversible decisions quickly to build momentum and delaying irreversible decisions until the last responsible moment.
Chris Matts gives us some good advice:
- Options have value.
- Options expire.
- Never commit early unless you know why.
(Listen to Chris talk about
real options and agile software delivery).
Recently, we've also started taking a set-based approach to find solutions to a few tricky problems. So far this has worked really well.
Tags:
lean,
options,
deferred commitment,
last responsible moment
Links to this post
There's a hole in your side of the boat
There's a hole in your side of the boat -
Jeff Patton
This is the best quote I've heard in a long time. Basically, it doesn't matter who's fault it is, we're in this together.
Tags:
blame,
team
Links to this post
How to get a local presence for a remote person:
Mutually immersive mobile telepresence.
A solution for distributed people working together? Don't make me laugh! Well... actually... it does make me laugh ... a lot.
Tags:
xpday,
colocated
Links to this post
Create a Lean Organisation
Get startedFind a change agent who wants to
get the knowledge to apply lean thinking and lead the transformation.
Map the entire value stream for each product and
find a lever for change by seizing an existing crisis (or creating one) to help everyone take steps to adopt lean thinking and create a lean organisation.
Forget grand strategy for the moment, create a sense of urgency and
begin asap with an important and visible activity that's performing poorly. Just get started,
demand immediate results to build momentum for change quickly, and
when you've got momentum, expand the scope to link and improve other activities in the value stream.
Create an organisation that channels product streamsReorganise by product streams containing dedicated people and functions so that value flows smoothly to the customer. When batch-and-queue activities are converted to lean techniques less people produce more product so
deal with excess people at the outset. Devise a growth strategy to put those people who have been freed up to use elsewhere and
remove the anchor-draggers - those who won't give new ideas a chance.
When you've fixed something, fix it again. Instill the principle of continuous improvement in everyone and
create a permanent lean promotion team to take the lead in planning successive improvements across the organisation.
2 steps forward and 1 step back is ok. No steps forward is not ok.Install business systems to encourage lean thinkingTo make the lean approach self-sustaining
utilise policy deployment to facilitate organisation-wide agreement on the lean tasks to be completed each year and
create a lean accounting system, which causes product streams to always do the right thing by indicating whether efforts are adding more cost than value or vice-versa.
Make everything transparent so that the rate of improvement can be measured and everyone can see what is happening all of the time,
teach lean thinking and skills to everyone so that everyone is thinking about the total flow of value, and
pay people in relation to the performance of the organisation. Batch-and-queue thinking sees large, fast, elaborate, dedicated, and centralised tools being most efficient.
Right-size the tools - processes, information management systems, organisational units, etc - to ensure product flows smoothly to the customer without delay and to enable the product stream to respond quickly to serve new business needs.
Complete the transformation
Convert from top-down leadership to bottom-up initiatives to generate automatic and prevalent lean thinking.
Develop a lean global strategy and
convince suppliers and customers to take the above steps to enable the creation of value to occur closer to the customer.
Tags:
lean
Links to this post
