Pols Consulting

Ooooh, this year’s XPDay looks like it’s going to be a good one - it just keeps getting better and better.

Steve Freeman and I are running a session on various techniques for exploring customer requirements. It’s based on our experience in applying some of Dave Snowden’s and Luke Hohmann’s ideas on our recent projects.

A software group is best measured by its customers’ success. Understanding what they really need is critical, but customers are human too which means that they’re fallible. Customers can’t always tell you what they want because sometimes they don’t know themselves, so asking them to rank requirements or write stories might not be the best place to start. This workshop presents techniques for working with customers and other stakeholders to help them understand the context and goals of a project or product. It describes a range of techniques such as “Speedboat”, “Product Box”, “Butterfly Stamping”, and “Give ‘em a jacuzzi” and runs two of them as exercises.

Nice phrase to descibe the way a team thinks for themselves (they take command). This is the opposite of some teams where the management what to control everything they do.

I stumbled across this the other day. Bill Strickland is amazing. All organisations need a Bill Strickland… I recommend you give it a look.

http://stream.fuqua.duke.edu/Content/fuqua_events/2003/Strickland/Strickland.smil

You can find more about Bill at http://www.fastcompany.com/magazine/17/genius.html

I particularly like this observation:

“Artists are by nature entrepreneurs, they’re just not called that,” Strickland says. “They have the ability to visualize something that doesn’t exist, to look at a canvas and see a painting. Entrepreneurs do that. That’s what makes them different from businesspeople. Businesspeople are essentially administrators. Entrepreneurs are by definition visionaries. Entrepreneurs and artists are interchangeable in many ways. The hip companies know that.”

Some time ago Chris Stevenson and I wrote about our experience working on a legacy application.  Martin Fowler liked our approach and decided to call it a
Strangler Application.

Brian Marick includes it in his recent blog discussion about the different approaches to dealing with legacy code.

I have been thinking about this a lot lately.  I have been working with a client where a strangler application would have been a good solution.  It was an almost repeat scenario from when we first applied the Strangler Application approach to a legacy financial trading system.

One of the key aspects of the original project is that we left the legacy application alone.  The legacy application was still maintained by the original team. A new team completed the replacement “strangler” application.  The rationale behind this was that the original team had repeatedly failed to address the legacy problems and was holding back the business. A key problem was the team itself. The team appeared incapable of coming up with an alternative solution, but management did not want to change the team as they were the only people who knew how the legacy application worked.

The new client rejected the approach –

We can’t do that! There is no way we can get the budget for two teams

Asking for more money in this way highlights the problems of the original team and the fact that the project management don’t know how to fix the original team (and have not addressed it before).

I now realise a critical success factor of the original project was the way the Project Manager hid the cost of the strangler application by associating it against a different project that had spare cash available.

This is a real barrier to applying these ideas in this situation. I wish I knew an alternative way to make this happen (any thoughts on this would be welcome!).

Continuing on the theme of breaking the self imposed rules I heard a wonderful story about a team working in an environment that involved a customer requirement to provide an audit trail of all project design decisions.

This was a real rule.

Many teams would interpret this as a requirement to have lots of heavy documentation and associated traceability. This would have been a self imposed rule.

This team solved the requirement in a wonderfully low energy way. They simply attached a long roll of brown butcher’s paper around the room. Whenever people on the team made a decision, they made a note of it on the paper, dated it and signed it. This acted as a short term information radiator of team decisions. Once it was full, they rolled it up, marked it with the date range and filled in it the corner of the room.

The auditor loved it as it was quick and easy to see what was happening over time.

I had an interesting conversation while running an agile training course with Alistair Cockburn. He has a common theme running through his books – that agile is cheating legally to win.

When you explain Agile to people you often get the response, “but that’s cheating!”

Our conversation with the class was about which rules are real rules (i.e. those imposed by the customer, or legal bodies) and which rules are ones the teams have imposed on themselves without realising it? When you run a retrospective on your process, you are trying to find ways of making things better (which rules you can break legally!).

When you start thinking in terms of real rules and self imposed rules it really opens up opportunities. Try it as let me know how it goes.

I was reading Willem van den Ende’s blog and came across a reference to “The 6 Myths of Creativity” by Bill Breen on the Fast Company web site. It’s one of those papers that triggers the “well, that’s obvious” reaction when you read it. In fact it is so obvious most companies do not do it.

This paper provides an overview of Teresa Amabile’s research at the Harvard Business School into organisational creativity and innovation. She has been collecting daily journals from 238 people. She simply asked them to tell her about their work and their work environment as they experienced it that day. It’s interesting that the feedback from these diaries matches my pleasurable experience of working with highly creative teams.

The fact is, almost all of the research in this field shows that anyone with normal intelligence is capable of doing some degree of creative work. Creativity depends on a number of things: experience, including knowledge and technical skills; talent; an ability to think in new ways; and the capacity to push through uncreative dry spells. Intrinsic motivation — people who are turned on by their work often work creatively — is especially critical.

A good agile team should be able to harness the creativity of the team. I just love working in creative teams – teams where everyone comes up with interesting solutions all the time. We have conversations with the users and say “Why do you want that?”, “Wouldn’t blah be simpler?” Likewise users say “If you could add this, it would be really cool because we could now filter our sales revenue by different regions… and that would save us loads of time”.

While agile does not guarantee creativity, an up front waterfall process kills this type of conversation.

Here is a nice technique to remember!

Think of everyone having just two neurons, one of which triggers when you talk to them. These are:

1. You are an idiot neuron.
2. I am brilliant neuron.

So if you say, “this system will help you do your job better“, the idiot neuron will fire and they will disregard what you say. How could you possibly know when you have never talked to me before? Clearly you do not know what you are talking about.

If, on the other hand, you say something along the lines of “How could we build this to help you do an even better job?“, the brilliant neuron will fire and they will listen to what you have to say.

I like to think of the neurons I am triggering when I talk to people. It really helps me.

Chris Matts (the other half of the Agile Business Coach has just published a new paper on the joys of negative feedback: Encouraging the “Right Stuff”  (PDF format)

A nice quote from the Civic Forum in Banja Luka (this is in Republica Srpska, the Serbian enclave in Bosnia).

Change happens when people who don’t normally have a say talk to people who don’t normally listen.