Skip to main content

Posts

the field of dreams

It was 2005, some years after the dotcom boom and a financial software house asked Colin to help with a project they just couldn’t seem to deliver. Colin sat down at the table with the development team and Henry, the Marketing Director. “Ok,” he said, “You’ve been working on this project for three years but haven’t released any software. Can anyone tell me what the problem is?” Henry spoke up first, “We’ve told them many times what we need but they keep building something totally different.” Mike, the development team lead, shook his head and said, “Yes, but you keep asking for things that can’t be built!” After some similar exchanges, the conversation looked like descending into total chaos so Colin held up his hand to get everybody’s attention. “Can you give me an example?” he asked. “You have to understand we are working in regulated environments,” said Henry, staring angrily at Mike, “this means it’s a massive advantage to us if we can supply a footprint-free application. Anything

the point

Willy, the CEO, was at his desk feeling very satisfied and confident as he read the monthly IT report. Everything was looking good, the report told him the development teams were really performing well and velocity was up yet again. Unfortunately, an email from Jackie, the CFO, disturbed his calm. “I can see the IT teams are busy,” read the email, “but busy doing what? Can we get our changes delivered? They will save us hours of work every month. Why haven’t they been delivered? – Jackie.” To see if he could resolve Jackie’s issues, Willy hosted a meeting between her and RJ, the CTO. “Right, what’s the issue, Jackie?” asked RJ, keen to get the meeting started. “RJ, every month I get reports telling me how many more points your teams have delivered.” Said Jackie, visibly frustrated. “In the latest one, you’re bragging about some of the teams delivering sixty points a sprint for the last three sprints. They may have delivered 180 points but I’ve seen none of my changes. Where’s my stuff?

not what i meant (part two)

Currently, I'm staying in Bangalore and, as many of you may know, I like to keep myself presentable, so everyday I clean my shoes using the little tin of polish provided free by the hotel. Yesterday however, the housekeeping staff apparently didn't notice I'd used it and so didn't replace it, as they usually do when they make up the room. Now I could have gone, or called, down to the front desk to have them send me some up but it isn't really a big deal and it won't hurt my shoes to have them miss a day's polishing, so I just left a note on the bed this morning saying, "Shoe polish please." Imagine my surpise when I returned from work today to find there was still no sign of any shoe polish in the room but there was a very highly polished pair of trainers sitting where my grungy old gymn shoes had been this morning! Written requirements, eh? How can they not work? :)

not what i meant

Had a really good session with the developers while delivering the two-day TDD course at a customer site recently.  During the course I had quite a long discussion about Bob Martin, et al's concept of 'Clean Code' and recommended that the attendees each buy a copy of the book as I consider it one of the most important books on modern software development.  Later I spoke to their manager and he agreed to purchase a copy of the book for everyone.  Two weeks later I saw him reading a copy and asked him what he thought. "Well, I'm not really a coder but I see what he's getting at and it seems quite reasonable" was his response.  "Did you get copies for the developers?" I asked.  "No!" he replied, "I got  a copy for everyone , like you said. They can take it in turn to read it when I've finished"   Oh dear!

water babies

Some years back Colin, our intrepid consultant, needed to recruit a coach to help with the transformation at a customer site. On this particular day, he was interviewing what he thought would be an excellent prospect and had booked an interview room for the day so he could have some privacy. The candidate entered and Colin spent a little time chatting with him to put him at his ease. Once he felt the candidate had settled down he said, “Why don’t you tell me a bit about yourself and what you’re looking for in this engagement.” “Well,” said the candidate, “If you’ve read my CV, you’ll know I’ve been a coach for many years and have worked for many blue-chip companies. I’ve thought of myself as successful but, to be honest, I’ve always been a bit disappointed, too” Colin was curious and wanted to hear more about this. “So, tell me what you’ve been disappointed about.” he said. “The one thing that’s really disappointed me as a coach,” replied the candidate, “Is that so far, all of my custo

jedward

A prevailing Agile myth is that we don't do design but as I pointed out in a recent class, design should be continuous throughout development. One of my favourite areas of design occurs between defining the acceptance criteria for a story and going to code. It is here that the team needs to do: J ust E nough D esign W ith A ll R equired D evelopers to make sure that we have a shared vision of what it is we are going to build. We call this the JEDWARD stage... ...cue Doris Day, "Oh, the JEDWARD stage is a-rollin' on over the plains..."

bad science

My business is change. I like to think we help people to change for the better and improve by introducing tools and techniques we think are good practice. To do this, we rely on our own research but we also encourage our customers to do their own research, too, and for the most part what they find backs up our suggestions for improvement. Imagine my surprise, then, when a customer recently sent me a link to some 'research' from a company billing itself as a 'Research Lab.' To give it even more credence, the company trumpeted its very own 'Chief Scientist' complete with PhD. The 'research' was pretty standard stuff, they'd done some static analysis on a bunch of systems from large companies and had found out pretty much what many of us already know - most computer systems aren't written very well and there is an awful lot of technical debt around. There are many reasons for this, which, again, many of us are aware of, so I won't bore you by ev