Pols Consulting

Preston Smith has written a pragmatic overview from of why Agile works. I particularly liked the reference to Donald Reinertsen’s research that showed:

• Out of hundreds of projects, there is no case in which requirements remained stable throughout design.
• Of more than 200 product developers, fewer than 5% had complete requirements before beginning design.
• On average, design commenced with only 58% of requirements specified.

If requirements are going to change, wouldn’t we be better off acknowledging this and building our processes to accommodate it.

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!).

Here are some tips I picked up this week from a friend. He has just started at a new company. His new company has lots of projects without any clear indication of their business value. So he got them to draw a matrix like this (an evil 2×2 consultancy as it’s known in the trade):

He then asked everyone to place their project in the appropriate box!

This really helped people think about the business value. Just trying to justify the position in the box, makes you think about the value of the project. We’re not just doing projects for doing them sake (hopefully).

It was surprising how many high-risk, low value projects appeared on the grid! You can now ask “Why are we doing these?”, followed by, “Shouldn’t we be investing our energy elsewhere?”

The best bit of advice came at the end. I asked him, “But won’t they simply do the chart to humour you, and then return to their old ways?”

“Don’t be silly, I’ll just keep giving people more work until they stop working on non-important stuff!”

Still, I thought it was an interesting technique that was worth sharing.

Check out http://www.waterfall2006.com. I particularly like the registration page:

We’re sorry but registration is not yet ready. Our software developers have a really wonderful design. They’re almost done entering it into it a UML tool. They’ve told us not to worry and that finishing it will be “trivial” because “all that’s left is the coding.”

I have noticed a couple of common problems when the team meet the business to estimate what they are going to do next:

1. There is too much talking and the estimating takes far too long.
2. It does not involve the whole team. Some people don’t feel confident to participate while others dominate the proceedings.

Here is a little technique that is worth trying if you find yourself in this situation:

1. Get someone to read out and quickly explain the task that needs estimating.
2. On a count of three (as if playing Rock, Paper, Scissors!), each developer presents a hand showing their estimate with a finger representing a unit of work. If you feel that the task is too big for 5 units of work, simply break the task down and repeat for the smaller tasks.
3. We take an average of the team estimates.

The nice thing about this is that it is quick, fun and appears to provides reasonably accurate estimates (probably because it involves everyone).

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.

ComputerWeekly.com have an interesting article (European banking giant adopts agile development methodology)

It’s full of mixed messages!

On the one hand it talks about Fred Tingey positive experience of using Extreme Programming (XP) at BNP Paribas.

And then, it switches tack with an apparent “Security Expert” taking the view that agile is far too risky:

…this type of development exposes users to unnecessary risks as it is difficult to build security into the software development lifecycle.

This is a strange thing to say as security is a feature (not a lifcycle issue) and delivering features is what XP is really good at. I have never had any problems adding security to an application that has been developed in an Agile way.

The wonderfully ironic twist is that Fred Tingey won the Risk Manager Of The Year award for using Agile (sadly not mentioned in the article)!

Oh well. The key part is that Fred Tingey is is winning awards for using Agile and that the banking community is starting to recognize the benefit of agile techniques. Well done Fred.

Henk de Bruin has sent me two photos of me and Duncan Pierce in action at the Agile Business Conference. Thanks Henk

The Guardian has an article on extreme programming and even mentions XPDay. Great.

http://www.guardian.co.uk/online/story/0,3605,1342328,00.html

I have just noticed an(other) article arguing that you must must be mad not to do waterfall development in the appropriately named website (http://db.riskwaters.com/public/showPage.html?page=195099

Steven Little claims IT projects must have the following process:

1. Step One: What do I have to do? (write the business specifications)
2. Step Two: How am I going to do it? (write the technical specifications)
3. Step Three: Do it (actually start implementation)

The print version has a wonderfully ironic photo showing the tools of the trade as hammers chisels.

I wonder why people still feel that waterfall is such a great idea for managing project risks?

Waterfall was first described by Winston Royce in the famous paper “Managing the Development of Large Software Systems”. Many people, incorrectly view this paper as the paragon of single-pass waterfall. In reality, he recommended an approach somewhat different than what has evolved into today’s waterfall concept, with its strict sequence of requirements analysis (Step one), design (Step two), and development phases (Step three).

In a personal communication with his Son (Walker Royce), Craig Larman (http://www2.umassd.edu/SWPI/xp/articles/r6047.pdf) discovered:

He [Winston Royce] was always a proponent of iterative, incremental, evolutionary development. His paper described the waterfall as the simplest description, but that it would not work for all but the most straightforward projects. The rest of his paper describes [iterative practices] within the context of the 60s/70s government-contracting models (a serious set of constraints).