me.andering

My take on projects in ye average bigge organisation has been: the price of a project depends only on the position on the corporate ladder of the manager who starts the project. The lower the level of the manager, the cheaper the project.

Please note that delivered functionality or business value is not part of the ‘project cost’ equasion…

I have often wondered about, and looked in amazement at these large projects that seem to go on forever. I believe that most projects can be done with less people in less time, and many projects are not worth doing at all.

Maybe someone at <insert large ‘consultancy’ company here> did actually invent a working perpetuum mobile…

Read what a (former) big shot in a large company writes on how this mechanism works in practice, and what it feels like to be on the receiving end. How to destroy your company by packages, outsourcing and ‘consulting’ companies (and not paying attention to your users and customers)….

“Outsourcing is a brilliant trick of the managers. The responsibility for the failing project is moved to an outside vendor. They are now the object of aggression.

The real customers don’t talk with the programmers. They talk with the managers that are talking to managers that are talking to managers. Somewhere in the chain of communication all the meaning is lost. The result is something they don’t want, the users don’t want and the customers don’t want. Last but not least the process took so long that the market has changed. They have to start all over again.

Do you now understand why we there is such a shortage in IT specialists? About 30% of IT-projects is succesful. This means that 70% of the IT-specialists are working for nothing.

My advice

Adapt what is working as long as possible.

A team of 15 people is capable of doing more than a team of 1000.

Do it yourself.“

Hans describes a full circle process of what happens before a project is outsourced. I call it the “Shit” cycle I couldn’t resist making a drawing of it:

I missed one phase in the process: the pre-project phase, which consists of a sales rep of <insert large ‘consultancy’ company here> taking the high-level manager to the golf course…

What I don’t know is, each time the project goes through the cycle again whether golfing is required (Hans writes about one project that cycled for ten years…).

I prefer small change over big change. I’m talking about transformations, of course :). Small transformations make it easy to check if what we want to happen actually happens, and how far of we are. If you’re reading this blog there is a fair chance you are familiar with growing software in small steps – I apply the same principles when working on myself or helping others to improve their (development) performance.

 

What works in teams is to use an change backlog to track items that we want to improve. A backlog of small changes makes even a big, bad, change tangible and thus easier to manage.

 

Allow me to show you why small change works better than big change, and how I approach it in day-to-day situations. Nothing is new, of course, and you will find literature references at the end.

 

If you want to achieve a change (say, introduce some Agile practices) you may believe performance is going to improve according to the learning curve model. If you really believe in this model, you may push a bit, so the learning goes faster:

 

“There will be a learning curve, it will take some time, but it will be ok… It will be worth it, trust Me! Now Change! I will even give you some time to learn…”

 

some people around you see this:

 

 

Chaos means lots of change, but no improvement that sticks – performance is wildly variable.

 

Especially if you preach a big transformation, say e.g. the Big Agile Transformation (BAT), and you go around preaching and convincing, people may feel threatened.

 

 

 

Or, if we go one step up the pushiness ladder, they may feel squeezed:

Assuming our intentions are good, and we are more interested in results than in convincing people, we would be more effective with a gradual approach that incorporates fear of the unknown plus time to learn, try and integrate new behaviour. The Satir Change Model can help us realise where we are.

 

 

In old (or late) status quo the system is stable, performing in a more or less predictable way. When the foreign element (in this case us, or our bold new idea or a shift in the environment) chaos hits. When the system finds the transforming idea (which we may believe we already have - but often the system needs to find its’ own because it experiences our transforming idea as a foreign element…), practice and integration starts - the system, by the people in it, experiments with the transforming idea by trying new behaviour. When the transforming idea is integrated in new behaviour, the system enters a new status quo, which over time becomes a new old status quo ;).

I like the model even better with colours (Red for Chaos, Yellow for Integration and Practice, Green for New Status Quo and Gray for Old Status Quo).

 

This still depicts Big Change – but at least there is light at the end of the tunnel, and you know that Chaos is only temporary.

 

My preferred application of small change takes this model, and sees it as a cycle: After (new) status quo another cycle of change starts:

A succession of these cycles gives us an upward spiral of incremental improvement. If we keep the change, we can prevent from getting stuck in a rut (late / old status quo - the grey zone). Drawn in a timeline, we can see increments like this:

 

a lot of small changes, each leading to improvement, and short amounts of chaos. Before status quo sets in, we start with the next change, so everyone stays accustomed to change (this is why for instance in retrospectives it is common to choose to do something ‘differently’, even though there may be nothing ‘wrong’ with the current situation).

 

Of course, it rarely gets as predictable as the previous picture. Each change is an experiment, with a hypothesis and a result, so what actually happens might be…

 

 

Some change experiments do not lead to improved performance, and some changes are so easy you hardly notice – the team is in the ‘green zone’ and stays there more or less.

If we forget the hard work involved in each step and push, we may (mistakenly) believe that we have a newtonian change model…

 

The subject of each change may be different, so we can leave some area for a while, and pick it up later.

 

As an example, here is a choreography for small-change agile transformations I’ve used:

 

 

How do we get there? There are a couple of ways, all of them involve a change backlog. The differences are in how the backlog gets filled.

 

sources:

• When I start at a new client, we have one or more ‘intake’ conversations. We discuss what current issues are, what is most important, and what would be a pragmatic place to start. Often I keep the backlog implicit, in my head or my notebook, and act as a mentor by suggesting pragmatic starting points.

• Project, Release or Iteration Retrospectives. A retrospective identifies areas for improvement and/or things to try soon. Participants can prioiritize items from the backlog, and brainstorm solutions / things to try, which feeds in to the prioritized improvement backlog.

• Stand-up meetings – blocking issues can be added to the top of the backlog.

 

As always, someone has to make a benefit/cost analysis for improvement. Time spent on process improvement can not be spent on delivering product, so we have to get bang for our change buck. Especially in the beginning, thinking about what to change next without disrupting the production of features can be difficult. A visible backlog helps to prioritize and reduce the amount of chaos felt by participants – we can track progress (this often is on a larger timescale than building new features, so not everyone is able to see the results without training.).

 

Once a team (or teams) start to click, change is often no longer a topic, and each iteration several items are added to and picked from the change backlog without much ado.

Credits

 

Quality Software Management - IV - Anticipating Change by Gerald M. Weinberg (explanation of the Satir Change Model and Lynne mc Lyman’s zone theory for the colors used in the drawings), and Virginia Satir for publishing the model in the first place.

Alternative change models comics by Nynke Fokma

“Kitch Kafich” photo of guys in car swinging a baseball bat by KRC

Lynne Azpeitia, for drawing the Satir Change Model as a cycle.

Nynke Fokma and colleagues for  color coding the Satir Change Model.

Kathy Sierra (Creating Passionate Users) for the inspiring visual style of her blog.

And you?

I would love to hear what your approaches to small change are. Feel free to leave a comment. Or, even better, join us at Agile Open or the Change Artistry Workshop at Agile 2007.

I’m enjoying and making sense of Dan Russell’s posts on sensemaking:

What’s always struck me about sensemaking behavior is this: People just don’t seem to be all that good at it. They take notes on the topic, then never go over them, or lose them in the shuffle of life.

I resonate with that. I’ve learnt a couple of approaches to make sense of where I am, where the organisation is, and where it’s context is, for instance systems thinking tools such as the Cynefin model. Whenever I’m confronted with a problem, I may or may not reach for my tools. Often, I get stuck in a situation, and _then_ reach for my tools and think “why did I not think of that before…”
For instance, I’m working on a product where the self-organizing team has not been able to agree on a direction and a planning method for a while. I look at the context - it is new product development, something like whatever we are going to make does not exist. If I get the Cynefin model out of the box, we find ourselves in the “Complex” domain, where cause and effect are only coherent in retrospect and do not repeat. The appropriate approach (according to the Cynefin model) is to create a bunch of products instead of one.

So it may not be a wonder that the team can’t agree on an approach - we shouldn’t. We are not blind men looking at different sides of an elephant - we are looking at several elephants, and each may require their own approach…