change management

Guess who? (Kill the Agile Buddha)

Tuesday, 25 January, 2011
By: marc

Guess who am I now.

I’m in a supermarket, I’m pushing a trolley. I’m putting items into it. I just need some bread and I’ll be going to the checkout. Who am I?
I’m in a bank, queueing up in front a machine for depositing cheques. I’ve got a couple of cheques I need to pay in. Who am I?
I’m in an electronics store. I want a new printer but I’m not sure what’s the best for me, I’m looking for someone to help me. Who am I?

Or maybe what am I?

I am a customer.

Aren’t I?

Business language backs up my assumption. The employee at the supermarket checkout is called a Customer Service Rep, my personal (customer) details are held in the banks Customer Relationship Management system, in the electronics store I’m looking for Customer Support. And after I’ve bought my printer I’ll be asked to complete a Customer Satisfaction Survey.

So everything indicates that I am a customer. Or that is what I thought I was.

Apparently not according to the Scrum zealots.

At Agile 2009 Tom Illmensee presented a paper “5 Users Every Friday: A Case Study in Applied Research”. It describes how an eCommerce division of an electronics retailers introduced agile and how the user experience team adapted to agile. It starts by describing how their initial forays into agile were deemed successful. It was collaborative with the disciplines well integrated; “whiteboard wireframes, minimal documentation, and product demos. Usability tests with paper and semi- functional prototypes were conducted with shoppers each sprint”. More than that, the whole team enjoyed the experience. A decision was made to “take agile to the next level”. The next level was the introduction of a consulting firm who brought in scrum training. The scrum dogma was painful to adopt, but they got there in the end. But there’s a line in the paper that made me angry:

“The peculiar semantics of Scrum were especially confusing at first. In retail customers were people who bought things like stereos and flat-screen TVs. Not anymore. Agile had changed the definition of perhaps the most important word in our business environment: customers were now internal product owners. Customers would now be referred to as shoppers—or users.”

I’ll write that again. Customers (the people who the business depended upon, and “the most important word in [their] business environment”) would now be called shoppers. Or users. Because in agile, customers are internal product owners.

Sorry, these consultants, these agile zealots, these software egos have got too big for their boots. Dan North, pulling to pieces the nonsense of ‘software craftsmanship’ put’s it eloquently:

Software Craftsmanship risks putting the software at the centre rather than the benefit the software is supposed to deliver, mostly because we are romantics with big egos. Programming is about automating work like crunching data, processing and presenting information, or controlling and automating machines.

Software at the centre rather than the benefit the software is supposed to deliver. Software is the means to an end, not the end itself. If a certified scrum master (certified master based on two days training and a multiple choice questionnaire, now there’s a farce) tries to rewrite your business language, tries to tell you that your domain language is wrong, show him or her the door.

There’s a budhist saying “If you see the Buddha on the road, kill him“.

If you see agile in your workplace, kill it.

Why kill the Buddha? because the Buddha becomes an object, your own illusion of what it is. And it this illusion is wrong. To turn the Buddha into a religious fetish is to miss the essence of what he taught. Killing the Buddha means taking responsibility for yourself. Same with Agile; to turn agile, to turn software development into a religious fetish is to miss the point of what it is all about.

===

I presented on the customer theme a while ago, here are the slides.

And here’s me narating the slides on google video.

Nothing and nobody is indispensable

Tuesday, 31 August, 2010
By: marc

The cemeteries are full of people who thought they were indispensable.

If you didn’t turn up to work tomorrow, if you never came back, what would happen? I mean, what would really happen?

The world wouldn’t stop.

Can you hand on heart say it would be the end of your organisation? So you may be the ‘key man dependency’, but is that your ego making you think that? (OK, so I once worked with an organisation who had one of those. Their system was written in some obscure language that only one person knew its inner workings. He spent his weekends base jumping. Our job was to migrate the data to a new system to alleviate this risk).

When was the last time you took a holiday? Been too frightened to because you fear everything will fall to peices when you’ve gone? Get over it. Take a vacation, Nothing will change whilst you are away. You’ll get back and nothing will have changed.

What is indispensable?

OK. Now think bigger. History is full of organisations who thought their products and processes were indispensable. Of the FT30, (the oldest index of share prices started in 1935) only one company (Tate & Lyle)is still there after seventy five years.

What do you think would really happen if your organisation ditched all that process and product baggage it held onto so closely? What would really happen? Are your current ways of working really indispensable? How about your business model? Maybe time to do some scenario planning to ask precisely those questions?

<Personal Interlude> Eight months ago I was a lazy tub of lard. I could barely swim the length of a pool, my bicycle had two flat tyres and I’d be breathless and beaten after running 50m to catch the train. I looked for a goal, something that was outside my comfort zone, my frame of reference. I entered the London triathlon, sprint distance. Completing a triathlon became an unobtainable dream (you have to understand that I went to Loughhborogh University, home to the Jocks, [and a rather good Human Sciences department and Ergonomics course, hence my attendance there], I felt totally alienated from all the sporty types, and triathlon represented the pinnacle of pointless exercise and sport). And slowly started training for it. Running, I hated. My first swimming lesson I discovered the need to breath. Cycling, I discovered the ride to work scheme and bought myself a decent bike. I put myself on a change programme. A programme of gradual change. Baby steps. And a few weeks ago it all came together at the London Triathlon; the swimming, the cycling and the running. A multi-disciplinary effort, a radical change to my being. And I completed it. In a not overly embarrassing time; in fact I can in the top half. but better still, I ended it charged up with how much faster I could have gone, now that I know what it is like. I paced myself too slowly. I’m buzzing on triathlon. </Personal Interlude>

Organisations I see are like the tub of lard I was. Full of inertia, and reasons why they can’t change, why they can’t be triathletes.

Yeah, wouldn’t it be great to be an Apple… But we just don’t have a Steve Jobs. Reasons why you can’t rather than inspiration, spirit and belief in why you can.

There is nothing in your organisation that is indispensable. There is no reason why you “can’t” other than your own myopia and inertia and inability to dream the future and train and practice to make it happen. All you need to do is get over the inertia and make it happen.

Are you managing expectations beyond the team?

Monday, 30 March, 2009
By: marc

There’s this idea called the Disconfirmation of expectations theory that states that having unrealistically high expectations from the adoption of a new IT application will result in lower levels of realised benefits. Get customers excited about a new product and fail to deliver on it and you will have unsatisfied customers. And unsatisfied customers are unlikely to use the product to its full advantage.

There is a risk with products developed using agile approaches that they fail to deliver on their initial promise. The immediate stakeholders know that the product will evolve incrementally, but is this true of the broader audience? Are they aware of the intended regular heartbeat of delivery or are they expecting a fully featured product at the first release. How are you managing expectations beyond the immediate product team?

Be wary of what you say early on. Creating a vision is essential but be mindful of how this is communicated. Early demos, proof of concepts, prototypes, wireframes often show a vision of the end goal, several releases into the future. Words are easily forgotten, explaining that this is an end goal vision is not enough, you must show a vision of what the cut-down product for the first release is and ensure it is appropriately communicated.

Expectations work both ways, it is easy for the business to tell IT their requirements and assume they will be developed in their entireity in one go. Similarly it is easy for agile developers to expect the business to understand their incremental approach to delivery. The key to success is effective change management; identifying all stakeholders (both core and peripheral) and create a culture of agility that goes beyond the immediate project team. In a large organisation that maintains more traditional approaches, agile projects must be supported by a well designed communication plan that builds the relationship between both IT and the business. Identify whose life will be touched by the product and develop a strategy for communicating to them. This doesn’t mean “they can see what is going on on the project Wiki” this means someone taking responsilibity for listening, engaging and evangelising on the product, the project and its goals.

How are you managing the change?

Thursday, 16 October, 2008
By: marc

To the development team ‘change’ relates to scope and requirements within the project, but change runs far deeper than that.

A question that I am often asked is how do you manage business change on agile projects. Release regular and often is an often quoted mantra, but what does that mean to the business where rolling new software across the large, multi-site organisation? How do you manage the piecemeal introduction of new technology, features and functions to hundreds or thousands of people, many levels removed from the project across remote offices and geographical locations? How do you ensure the recipients of the new technology rapidly adopt it and accept the change, even when change is occurring every few months.

What are the financial and human performance implications of each new release in terms of training, productivity and morale? What is the overall burden on people in frequent change?

The reality is that it is not unusual for projects deemed successful by IT and the immediate business team to ultimately fail when released to the broader organisation. Effective change management can be even more important when an organisation adopts agile software delivery.

An analogy as an example. If I expect a screwdriver and you only give me a cross-headed screwdriver when I really want a flat head one I am going to be unhappy. The core team may have prioritised the cross-headed one first for good reason, a flat headed one maybe coming just round the corner, but if you don’t deliver to my expectations I am going to be unhappy. Worse, I am likely to become resistant to future change and less likely willingly cooperate with the uptake of future releases, even if they do start to deliver to my needs.

Keep it on the shelf
The first point is that regular and often does not necessarily mean release to production for the entire organisation or marketplace. Running a number of internal releases, keeping them on the shelf until a complete and marketable product is ready is a strategy often employed. Significant value can be accrued by getting tested and working software into a pre-production environment and held “on the shelf” awaiting a full release. This maybe a UAT environment where a limited number of stakeholders test the functionality in an ‘as-live’ environment. Or it maybe a beta release to a small, selected number of interested people (e.g. a ‘friendly user trail’). This can often pay dividends with usability issues and minor gripes being picked up and addressed before a major roll-out.

Communication
Let’s assume that the team wants to roll out the application early and often to the whole target population. Critical to the success of managing the business change is communication. It is important to manage expectations on a timely and appropriate manner. Explain what the upcoming release will do and more importantly what it will not do (and when it will do it). Keep all stakeholders informed of the project progress (setting up a project blog can be a cheap and easy way of letting interested people know of progress), yammer maybe another way of broadcasting updates and information. Having a release count-down can also prepare stakeholders for the change. The techniques can be googled, the important thing is to communicate and manage the expectations (and be ready for inbound questions and comment after go-live).

Adaptable user interface
It is not unusual for the core team to drive for as much functionality as possible in the first release, considering UI enhancements as ‘nice to haves’ and consigning them to later releases. This is a false economy. Consider the cost of training and lost productivity through a hard to use interface. Now multiply that across multiple releases that focus upon utility before usability. Delivering a first release that is self contained and compelling will go a long way to driving organisational buy-in of the new application and greater acceptance of future change. (Jeff Patton writes some great stuff on using story maps to explain what the system should do. Using these will help focus on complete and useful slices through the application rather than random features that are perceived to be of value but do not make a coherent product).

A new user interface, however well designed will inevitably take time to learn the first time it is used. The challenge is with each subsequent release to introduce funcitonality and interactions that leverages the users existing mental model of the application, building upon what has been already been learned. Starting with the end-state, wireframes that articulate the final application then trimming out features, feields and controls to represent each notional release can be a good way of ensuring a UI that will scale as new functionality is added.

Agile organisation
Ultimately the most successful way of introducing agile is to build a beta culture with everyone as agents of change across the whole organisaiton. More importantly change becomes a cycle of learning and continuous improvement. And here I’ll borrow this most excellent graphic from David Armano. David compares what he calls conventional and unconventional marketing but the parallel with software development is obvious. His iterative cycle is “plan-design-launch-measure” but that is not a million miles away from the lean philosophy of “plan-do-check-act”. And critical to the journey is the learning cycle between iterations.