Thoughts from a Thirsty Bear

The power of caring and smarts

2012-02-11T18:24:00.000Z

Just recently I have been thinking a lot about what really makes a good agile team member. The reason is that over the years I have seen some teams become incredibly successful in terms of delivering products, and other teams crash and burn even though they have the same superficial traits and abilities. I have also seen teams go from zeroes to heroes (and back again), while others remain at whichever end of that spectrum they started at and never change. There is obviously some "secret sauce" (as Jeff Sutherland calls it) that needs to be mixed in.

Well, I think I have identified one piece of this particular puzzle that I had underestimated previously.

Recently, one of my tweets resonated with quite a few people:

"Realised that agile has one fatal flaw. It still requires motivated, smart people who care for it to succeed, same as its predecessors."

(actually I was fibbing slightly - I have suspected this for quite a while now. I haven't only just realised this)

I think these two are key ingredients for success, and not just "nice to have". They are the "secret sauce", not just for agile teams, but for software development in general.

You need people who are smart. By smart, I don't think I mean conventional intelligence and IQ, but something different. The best way I can describe it is a combination of problem solving ability and intuition.

You also need people who care. Some people have a deep seated drive to do good work. To excel. To better themselves. To maintain their humanity and help others achieve too. You need people with a strong inner motivation who want to make things work.

When you combine these two, magic begins to happen. I believe that people who care and have exceptional problem solving abilities (who care about solving problems, maybe?) tend to have the right attributes for agile (and other) software development teams:

Able to communicate
Willing to learn
Humility
Courage
Passionate about quality
Curiosity
Integrity
Initiative
Creativity
Imagination

But that is not all. I believe they will naturally obtain the basic technical skills to do their job as a side effect of the curiosity, the courage and...actually all of the above! Now imagine what an entire team of these self-motivated, capable people can achieve.

However, I should emphasise that creating a functional, high performing team is not as simple as simply hiring in the people with the Right Stuff. You also need to put them into an environment that will nurture them and allow them to grow. If you put caring, smart people into an environment that actively discourages the right behaviours and attitudes, whether by accidental cognitive dissonance or deliberate edict, then there will be trouble ahead. But getting the right people on the bus (and its corollary, getting the wrong people off the bus) is a good start to sorting out your delivery problems - "Lead them, follow them or get out of their way".

So it looks like agile has the same achilles heel that its predecessors - waterfall, DSDM, RUP etc - have. It does not do away with the need for good people working in a good environment. You cannot force anyone to do a job well if they do not want to. No matter how much you believe that agile provides a framework for building high performing teams, it cannot force people to inspect, adapt and learn if they do not want to. But it does provide one huge benefit. It fails fast. You find out if the project is progressing - or not - very quickly. The feedback it provides allows the rapid identification that something is going wrong, whether it is environment, design, policy or people. This has enormous implications for our industry in terms of how we need to handle hiring, team building and behaviours in the future. More on that soon.

How many holes are you falling into?

2012-02-07T11:50:00.000Z

There’s A Hole In My Sidewalk– by Portia Nelson

Chapter One
I walk down the street.
There is a deep hole in the sidewalk.
I fall in.
I am lost… I am helpless.
It isn’t my fault.
It takes forever to find a way out.

Chapter Two
I walk down the same street.
There is a deep hole in the sidewalk.
I pretend I don’t see it.
I fall in again.
I can’t believe I am in the same place.
But it isn’t my fault.
It still takes a long time to get out.

Chapter Three
I walk down the same street.
There is a deep hole in the sidewalk.
I see it is there.
I still fall in… it’s a habit.
My eyes are open.
I know where I am.
It is my fault… I get out immediately.

Chapter Four
I walk down the same street.
There is a deep hole in the sidewalk.
I walk around it.

Chapter Five
I walk down another street.

So which chapter is your team at? Be honest now.

Infamy! Infamy!

2012-01-17T08:52:00.001Z

...they've all got it in for me!

Excruciating Carry On pun aside, here's the long overdue link to the talk I gave to the Limited WIP Society way back in March 2010 (my fault for not posting it here - it's been up on the SkillsMatter website for ages).

(Sorry, this is just a link. I can't work out how to embed this directly into the blog page - any ideas, anyone?)

Software development is not an assembly line

2012-01-16T20:14:00.000Z

Analogies are useful to a point. They allow people to relate new ideas back to something they are familiar with, giving them a safe framework from which to explore new territory. However they can also be immensely damaging and misleading. I was recently reminded of one particularly well worn example of the latter type that needs to be laid to rest once and for all:

Building software is not the same as building a car. Developing a software product is definitely not a simple assembly line process.

When building a car on an assembly line, you make the individual components - wheels, engine, chassis, seats etc - and then construct the finished item from these. Each component has already been designed in its own right, and they have all been proven to fit together many times previously. There is absolutely no creativity involved in the construction process. There are limited opportunities for different combinations of components (and those that are possible are well tested).

Software development is a fundamentally different problem. You don't have a set of predefined components. But you do have close to an infinite number of ways to build the final product. Individual components making up the final product need to be built, and so have not been proven to work together. The whole construction process requires a huge degree of creativity to produce a final, working deliverable. The nearest you can get to a car manufacturing analogy is to think of building software as attempting to build a car from raw lumps of metal, with no existing, pre-proven designs for the components. Trying to emulate an assembly line by believing that you can build component after component and expect them to immediately bolt together without problems will inevitably lead to tears before bedtime. Yet many teams still fall into this trap.

If it can be related at all to this analogy, software development has more similarities to car research and development than manufacture.

Consider this. A new car design is first prototyped as a collection of conceptual drawings that are iterated towards a final design. Then these are fleshed out to various models and mock-ups which would never make it to the forecourt, but which are used to invite more feedback. Then working prototypes are produced, and again, more feedback obtained, and designs iterated (or the design is shelved or binned). Finally, after many, many iterations, there is a new model of car available to purchase. Sounds familiar? Iterative software development creates a simple demonstrator of the system, then keeps on adding to it, refining both the functionality and the design until it is good enough to release to users.

This is where software development fits. It has more in common with pre-manufacture prototyping than assembly lines. But this doesn't stop us from stealing relevant, useful ideas from the assembly line. Kanban, anyone?

Misquote

2011-11-22T20:44:00.001Z

Anyone who reads my articles will already be familiar with the quote I use at the top of each page - "It is not the strongest of the species that survives, nor the most intelligent, but the one most responsive to change.". For me, this cuts to the very heart of agile and lean techniques. Being successful is not about being powerful, or even knowledgeable in the traditional sense, but about being adaptable and smart.

Way back in June an anonymous poster pointed out that the quote was misattributed to Charles Darwin. To my shame, I sat on the comment until I had the time and patience to research the correct answer.

I can now confirm that you were absolutely correct, Mr Anonymous. It was misattributed. The quote most likely comes from the writings of Leon C. Megginson, Professor of Management and Marketing at Louisiana State University at Baton Rouge. The quote is a paraphrasing of Darwin.

I won't bore everyone with details, but here are links to the corroborating articles.

One thing Darwin didn't say: the source for a misquotation
Survival of the Pithiest

Quiet here, isn't it?

2011-11-22T20:31:00.001Z

I've been fairly quiet recently for various reasons, but rumours of my online demise have been grossly exaggerated. The brief hiatus has given me time to think about several new articles that are now in the pipeline, so watch this space.

Blogger Profile Change

2011-07-06T20:56:00.002+01:00

All change!

I am in the process of migrating this blog to another account. For anyone following via my Blogger profile, I am now over here.

It's not personal

2011-07-06T19:33:00.001+01:00

Oh dear. It would appear that some people reading this blog and Twitter feed believe that I am writing specifically about them. Naturally, this makes them a little sensitive to the criticisms that I sometimes level at the industry and the comments/observations I make.

Let me reassure everyone that the articles I write generally don't relate to any one client, or incident, or person, or project. There really would be little point in writing about anything that is only specific to one project; to be fair it would be deathly dull, and irrelevant to everyone else. Even in the rare case when there is a particularly interesting success or failure story, I ensure that names are changed, and generally wait a while as well before publishing to anonymise the problem and protect the guilty. And remember I have had people I have never worked with before accuse me (albeit lightheartedly) of spying on their project, so some observations must be common across multiple projects.

Sometimes I publish idle thoughts. Sometimes (hopefully) insightful. Other times complete rubbish, the ramblings of a madman.

So where do these snippets come from? Certainly some of the material comes from personal experience, both past, and to a small degree, present. General observation of the industry provides a huge amount of material, with certain themes and problems coming up time and again (and often from way back too). Some comes from discussions with fellow developers and coaches working in other companies, a throwaway comment triggering anything from an idle thought to a complete theory. Some more comes from talking to managers, a very different but related discipline. Yet more from talking to people outside our small, mad world of software development. Then there are the books, films, documentaries, seminars... Everything influencing everything else, trying to compete for space in a grand unified theory of software development, the universe and everything.

So maybe, just maybe, it's not about you.

But...

If you do start thinking that anything I write sounds like it is directly referencing your project. Or your company. Or even you personally. Stop and think. Why is it resonating with you? Why is it sounding familiar? Why are you embarrassed/angry at seeing something so familiar in print?

Then ask yourself the two most important questions of all:

"Are we doing something stupid here?"

"If we are, how do we stop doing it?"

Remember, it's not personal. It's about working smarter.

A blast from the past

2011-07-05T17:44:00.018+01:00

Once upon a time, in a galaxy far, far away, I spent several happy years working for the legendary Acorn Computers and their near mythical set-top box subsidiary, Online Media. We did some seriously cool, groundbreaking stuff there, including being (arguably) the first to stream video over internet protocols. All the computers ran on RiscOS, a homegrown, lightweight, adaptable operating system for ARM processors.

Alas this time came to an end, and Acorn disappeared, but their legacy lived on. RiscOS carried on, supported by various companies.

I had mostly forgotten about it until now. An old colleague recently mentioned that in 2006 a group of ex-Acornites started a new company, RiscOS Open Limited (ROOL), dedicated to maintaining the operating system and take it forward. The OS is still available, and supported. So do take a look, and if you have an interest in RiscOS then do consider helping them out.

The hidden danger of accepting broken windows

2011-06-01T15:34:00.002+01:00

By now we should all be aware of the "broken window effect", not least because there is now concrete evidence that it exists. As a reminder, the "broken window effect" is that subtle, damaging change in attitude that causes perfectly normal, law abiding, sane people to break social norms if they see others doing the same thing. People are more likely to litter an untidy, graffitied street than a clean one. They are more likely to damage a car that has already been damaged. And they are more likely to write badly structured code and cut corners in a codebase if there is evidence of others doing the same thing.

But I think there is an insidious, darker side to this. Accepting broken windows for too long desensitises and deskills your team.

What happens is this. The bad behaviours that happen due to being surrounded by the broken windows - broken builds, releasing untested code, mend-and-make-do workstations and so on - become the new social norms. People get used to them; they will become disinclined to fix them, and it becomes the accepted reality. "It's the way we do things here". But if they are now the accepted status quo, then the next thing that gets broken is on top of the existing problems. Since the culture has now become one of acceptance, the new problem doesn't get fixed either. And so on - the system degrades to the next level. And the next. The cycle spirals downwards.

Remember, these are sane, normal people being sucked into this. Suddenly there is a real danger that a perfectly good software team get so used to breaking the rules and living with the broken windows that they forget what the civilised rules are. They effectively forget what "good development" is. If you don't use the good practice patterns - green builds, continuous integration, TDD and so on - you do forget them. Your team actually begins to deskill, which in turn speeds up the descent into failure....

Fortunately the process is reversible, but depending how far it's gone and how much technical debt you have accumulated before accepting the situation, fixing it can be painful. So just bite the bullet, and fix those broken windows as soon as you see them. Demand better!

A bit of a Spring Clean

2011-05-27T11:01:00.000+01:00

As regulars will have noted I'm having a bit of a spring clean of the blog layout - new title, template etc.

Feedback and reports of weirdness welcome - contact me here.

A note on electronic agile tools

2011-05-27T10:49:00.001+01:00

It’s always a bit of a shock when you get unexpected feedback, especially from someone who you have known for a while. It happened to me quite recently with a conversation that went something like this:

Friend: “You’re dead against agile tools, aren’t you?”

Me (confused): “Erm...not exactly....”

Friend: “But didn’t you persuade several teams in <major co> to throw out <agile tool vendor> the other year?”

Me: “Not me. The team simply decided that the tools were not providing value to the way they worked...”

However, thinking back I think I can see how some people have formed the misconception that I think agile tools are Satan’s Spawn, and should be eradicated at every opportunity in favour of a simple pen, 5x3 cards and at a push an Excel spreadsheet. Reality, as always, is a little different....

My view is that many teams prematurely select an “agile tool” before they know what they need. Teams (and departments, and companies) are like kids in a sweetshop when it comes to new toys, and want to buy the glossiest, most feature-rich application. This is mostly because they want the mythical Silver Bullet that will allow them to “do Agile” painlessly and with minimal disruption.

So what happens when this shiny piece of software gets installed? After all, that nice salesman said it will kick-start your agility...

Feature Frenzy. That’s what happens. You can imagine the thought processes:

“We must use every single thing in this software package. We’re paying a pretty penny for the licensing after all. And it’s there for a reason, right? Oh look, there is an ‘Estimate’ field on the Story entry page, and it says ‘days’. So let’s ask developers to estimate in real days (after all, that’s the same as MS Project does).

“Wait a minute...we can put in Actual Time as well. Wouldn’t it be great if we knew how well we were estimating, and feed that back so we get better and better until we know exactly when a project will be delivered.

“Oooh...even better. It gives us ‘Percentage Complete’, so we can tell how far from finished Stories are! Cool!”

...then when things start to slip from these “Estimate” fields...

“But you said that would take 1 day, but it’s taken 5 days....AND it’s been at 90% Complete for 4 of those days...that makes you a Bad Person”

This scenario is based on real behaviours I have seen more than once in teams who have asked me for help, and I have no doubt that I shall see them again. You get the idea - the process and behaviours begin to map to the tool, not the other way around. Or to put it another way, the tail is wagging the dog. The team didn’t know what they wanted, so they used the tool as their process model.

I suspect this is why some may think I am anti-tools (or manically pro-pen-and-paper?).To put the record straight, I am anti-inappropriate-tools. I am against prematurely selecting a tool before allowing your process to bed-in. All agile and lean teams end up doing things slightly differently - estimation, swim lane mapping of the current process and so on. The most efficient application of these proven techniques relies on flexibility. And yes, I have helped some teams to realise how some electronic tools were hindering them rather than helping.

So select your electronic tools to match your mature process, or at very least ensure that it is flexible enough to cope with anything you throw at it (products with this level of flexibility are starting to appear).

Also, never adopt any feature in an existing tool until you see a concrete, real-world and evidence-based reason that you need it.

If you are not using many of the facilities in a particular tool you have purchased, save your cash and look for a cheaper (free?) version that does less.

Finally, if you are using an electronic tool make it visible in the same way as a whiteboard would be or you will lose most of the benefits - bite the bullet and invest in a touch screen TV/monitor for each team at each location it is used. If this is too expensive, then I see a trip to a stationers for pens and cards in your future....

Updated: I can haz agile certification?

2011-03-14T19:57:00.001Z

Via various convoluted routes:

Become a Certified Agile Software Specialist!

Update: the link is now cobwebbed, but if you did the original then please get in touch!

Update 2: It's back! FTW!

Hudson is fired, Jenkins hired!

2011-02-08T18:40:00.004Z

Following a fairly public spat and veiled threats over trademarks by Oracle, the Hudson CI server has been renamed to Jenkins.

OK, technically Jenkins is a branch of the Hudson code, so it's more like Hudkins or Jenson. Oracle (sorry, "the Java community") will continue to develop the Hudson trunk, however the branch appears to have the blessing of the core ~~Hudson~~ Jenkins development team and the community (the vote to fork appears to have been virtually unanimous). If it looks like a duck & quacks like a duck....then the parent might just start resembling a dodo.

I'd like to wish the Jenkins team good luck. I've used Hudson to great effect many times, and look forward to the future improvements with the new project butler.

LSSC 2011

2011-02-07T12:59:00.001Z

I'll be attending the Lean Software & Systems Conference in Long Beach, California 3-6 May. I'm not in the States very often any more, so make the most of it. Come over and introduce yourself!

UPDATED: Keep behavioural driven naming out of unit testing

2011-02-06T12:07:00.000Z

Something is happening in the Test First world. There appears to be growing use of "Behavioural Driven Design" (BDD). That is, the test names in test classes are becoming sentences describing what the class should do, eg testFailsForDuplicateCustomers(). In my opinion this trend is damaging the effectiveness of Test First Design in the field.

Don't get me wrong - I think the fundamental idea behind BDD is sound. But I am finding that this kind of naming approach for unit tests is seriously detracting from the "code is the documentation" ideal. If you have a class with method "X", you should expect a test method "testX" that defines the method's contract. If the method's contract is more complex, you might expect to see a set of methods like "testX_NullInput" etc. This approach documents the class pretty damned well in my experience.

Now image the same class being tested by something like "testFailsIfCustomerIsNull". What fails? What input? Have I tested method "Y"? But method "Z" shouldn't fail if Customer is null! You end up doing some serious analysis to work out what is going on which fundamentally defeats the object of the tests replacing design documentation. Using BDD test naming here is actively obfuscating how the system works at a class level, not clarifying.

(Note - nothing that I am suggesting excuses obscure method naming. A method should do what it says and say what it does, with the detailed clarification of the contract being defined in the tests. All I am saying is that there should be a simple, obvious mapping between methods and the tests that verify their behaviours)

Where BDD comes into its own is when defining interactions. Integration tests that check the interaction of closely cooperating classes benefit hugely from descriptive naming. Also User acceptance tests reap huge rewards from the approach since the tests are described in business language that allows a Customer to understand what is being tested. Yes, use BDD naming in these cases because it does help.

Just keep it away from Unit Tests!

UPDATE: I wrote this article back in 2007. It's now February 2011, and a lot has happened. Since then those fine chaps Nat Pryce and Steve Freeman have written their excellent Growing Object Oriented Software with Tests book showing how it should be done. Jason Gorman's observations on two distinct TDD styles also filled in some gaps I had missed. Also, the whole "Software Craftsmanship" movement has moved understanding forward a huge amount by daring to ask questions and clarify.

And then there was the clincher, the tool that stuck everything together for me, giving the penny a clear path to drop with a loud Clang! The IntelliJ TestDox plugin. Suddenly the BDD approach to unit tests makes much more sense, to me at least, so I am happy to admit that my views expressed here have now changed. Or at very least, softened a huge amount. I now tend to use behaviours rather than specifics to define class level behaviour.

Which just goes to show what can happen if you keep an open mind and try different approaches.

Broken Windows effect proved?

2010-12-21T09:01:00.002Z

There has been a bunch of stuff written about the “Broken Windows” effect - the way that even good people will begin to do bad things if everything else is bad around them. In areas that look badly maintained, people tend to drop more litter. Where people are obviously flouting the rules others are more likely to bend them themselves. And in software, when you are working on bad code you are more likely to write more bad code.

I first stumbled across the idea in an interview with the Pragmatic Programmers, but the evidence given is fairly apocryphal. So I was pleased to find something more definite. And it does make for interesting reading. The effect is indeed real, and significant. The number of people breaking social norms when they see that others have done something similar more than doubles. It's the 'no-one will notice another little bit of mess' effect.

The study quoted in the article reinforces the need to maintain a high level of hygiene in your software. Some typical pointers:

Keep classes small, compact and easy to read. Keep honest by using peer review (pair programming, formal review etc).
Keep your code syntactically green. Don't tolerate compiler warnings unless absolutely unavoidable, and even then try to make these exceptions explicit (eg by using annotations). All modern IDEs are able to apply rules to warn of potentially error prone constructs and styles.
If you are serious about unit testing, unit test everything. If you need exceptions (mutators?) then make sure everyone knows what they are and agrees with the decision, then get everyone to police it. Reinforce the social norm.
Keep your tests green. No excuses. If it breaks, fix it or roll back quickly (I have heard of one team using an SVN hook on their gateway build; if that fails, the changes are immediately and automatically reverted to the last successful build).
Make sure your processes (QA, deployment etc) are slick and clean. If they're not, iterate them until they are. Anything that is difficult to do will encourage quick, dirty hacks and workarounds "until we get around to sorting things out".
Actively drive out all forms of technical debt. Or as one team succinctly put it, “Don’t step over the poo”. Don’t let tech debt accumulate and become acceptable otherwise it will fester and grow. Technical debt is the software equivalent of broken windows.

I could go on, but you get the idea. The golden rule is:

Don’t live with broken windows. If you see one, fix it!

Stop Press! It's official. You're better off promoting people randomly

2010-10-01T17:40:00.001+01:00

Those fine people at the Improbable Research Institute have awarded the 2010 Ig Nobel Prize for Management to Alessandro Pluchino, Andrea Rapisarda, and Cesare Garofalo of the University of Catania, Italy, for demonstrating mathematically that organizations would become more efficient if they promoted people at random.

So that's it. Maths supports what many people strongly suspected to be true for years.The Peter Principle is real. We can replace all those pointless appraisal systems with a random number generator.

Read their paper here.

Too easy to pair? Then automate it!

2010-09-13T13:23:00.007+01:00

"We don't pair all the time, some things are so simple they don't need it". I have lost count of the number of times I have heard this.

It's undoubtedly a seductive idea. Something done multiple times that is so easy that one person can do it, without error, guaranteed. But it is in fact a very subtle process smell, one so subtle that it's easy to overlook/justify.

If something is so simple that an individual can do it without error, guaranteed, it is a prime candidate for automation. Take some time and care (and pair) to free up developers so they can focus on what they're best at - things that require creative thought. Don't waste any more time on the dull and scriptable than you need to.

What's in a name?

2010-09-13T11:19:00.002+01:00

Everything, young padawan!

The "Dev Complete" Fallacy

2010-07-01T08:48:00.000+01:00

Has your manager ever walked over to you and asked when the story you're working on will be "dev complete"? Or have you ever overheard someone ask in a planning meeting "When will the product be dev complete?". Yes, I'm sure it sounds familiar. It's also one of my least favourite managementspeak phrases because it nonsensical.

Let's stop for a moment and consider what's being asked. What is "development complete"?

Many managers are stuck in a waterfall, sequential way of thinking. Requirements are thrown over the Chinese wall to developers, who throw it over the wall to QA and then, somehow, magically, working software appears out of the end. To them "dev complete" usually means ready to pass to QA. However the tacit implication is that it is not expected to come back again….that, well, development is complete…. The problem is that unless it's been tested, who can know whether this is the case? And if it there is a problem, then more development is required, so it's not complete.

So here's my alternative definition for this bizarre phrase:

"Dev Complete" means Done. As in Complete. Finished. Tested. Ready to ship.

Any other definition is simply "Dev incomplete".

Drop the "Certified" tag, guys!

2010-05-26T08:25:00.005+01:00

Scrum Alliance has now launched its "Certified Scrum Developer" qualification. It's a seductive idea - hire people with this certification and they will have been pre-bootstrapped into an agile way of thinking and working, same as Certified Scrum Master. So why do I think it is such a bad idea?

It's taken a while to work it out, but I think I finally understand why I (and some others) don't like it. It's wordology. Pure and simple. "Certificate" and "Certification" carries a whole bunch of mental baggage.
Consider these two phrases:

"I attended a 5 day Object Oriented Design course"

"I am a Certified Object Oriented Designer"

I am referring to the exact same thing - way back in the Dark Ages I did indeed go on a week long course in OOAD. They gave me a certificate at the end, presumably because I turned up and didn't snore too loudly. Yet the first phrase carries far less authority than the second.

And here lies the problem with Scrum so-called "Certification". It suggests that you are an "expert", or at least have attained a level of competence over and above "I have stayed awake through a 2 day course". However, on the flip side, it undoubtedly does make for a better sales pitch and allow people to make a ton of hard cash issuing the certifications. Then there are the courses to certify the trainers, and certify the trainer trainers, not to mention the yearly subscription to keep your certification....

The problem could be fixed with the strike of a pen. Renaming Certified Scrum Master to the "Introduction to Becoming A Scrum Master Course" would be a great start. While we're at it, rename Certified Scrum Developer as the "Introduction to Agile Development in Scrum Course". You get the idea. Reserve "Certified" for anything that gets assessed properly, where you show that you have indeed mastered the skills.

Needless to say I won't be rushing out to become Certified just for the paper certificate. I'll let my CV show that I'm post-certification standard. If a company believes that attending the course is more important than actually being able to do it then I probably don't want to work there.

“We’ll paint it red and call it a Ferrari”

2010-02-25T16:44:00.003Z

We have all seen them. Aspiring boy racers who have taken an old banger and put on the trimmings of a sports car - spoilers, big noisy exhausts etc. But it doesn’t change what is under the disguise - an old vehicle, nearing the end of its useful life, but can still limp along and get the owner from A to B. Eventually. If you have an old, rusty, Ford Fiesta, you can’t just get away with painting it red and calling it a Ferrari. It is still a Fiesta.

Yet it still appears that some parts of the software industry genuinely believe that they can get away with this mentality. Let me say this one more time (with feeling) - you cannot simply take a broken software development process, put some agile tools and ceremonies around it and expect it to perform like the real thing. Or to put it another way, no matter how many spoilers and exhausts you bolt on, they can never have a significant impact on the performance of something that already has the aerodynamics of a brick and the power of an asthmatic hamster....

To change a Fiesta into a Ferrari you need to change what is at the very heart - the engine. And you need to upgrade what that engine is attached to - the chassis, brakes, bodywork, oil. It’s the same with software. To turn your clapped out system into a high performance delivery-focussed process you need to change the people by educating, empowering and inspiring them - they’re your development engine, and many of them will already be up to the new, high performance job if given the chance. Then change anything that stops them performing - existing processes, bureaucracy, corporate inertia. Make nothing sacred - if it’s in the way, remove it. Now add some performance oil - make the resistance to further change as low as possible.

Any vehicle needs a skilled, motivated, passionate driver at the wheel who knows where he wants to go. This is your Product Owner. Put someone like this at the wheel and you just might have your race winning formula.

One final thought to consider. At least with software development you stand a chance of changing your old banger to a Ferrari.

Repeat after me....

2010-02-22T14:43:00.008Z

"What are we trying to do?"
"Where is the failing test?"

Repeat this mantra all the while you are developing. When you pick up a story, when you start a new slice, when you rotate onto a story, when you simply feel bogged down in detail and need enlightenment.

These questions leave you with nowhere to run to, nowhere to hide. And certainly no excuses.

Starting with Kanban Q&A

2010-02-03T15:51:00.002Z

OK, I admit it. I have played on the Dark Side, and can confirm they have some damned good cookies. Yes, I introduced kanban to the Scrum process being used by my customer.....

I know there are many people interested in this technique, so here are some key questions (and answers!) that you will come across during rollout. It's not exhaustive, but hopefully it will provide a practical starting point from which you can experiment. I have assumed some knowledge of what kanban is - limited work in progress, not timeboxed etc etc.

Firstly, some background. The project I was coaching consisted of three cooperating but independent teams consisting of 4-6 devs and 1 QA. There is just one Business Analyst acting as Customer for the project - Product Owner by proxy. The project used fairly standard Scrum techniques to manage progress - stories on cards, on a board, estimated using planning poker. The board consisted of swim lanes Not Started, In Progress, QA and Done. Standard stuff.

However they were suffering from problems associated with the abstract nature of story points - are they really days or fluffy bunnies? And how many Gummi Bears make a Mars Bar? So I was looking for a way to simplify planning further but without losing the ability to plan ahead.

So what happened when we rolled out a kanban system into the first team and limited their work in progress? They had to address certain key questions:

Q. "How many columns should we have?"

A. The first team initially stuck with the old trusty "Not Started, In Dev, QA, Done" pattern. But they put a work in progress (WIP) limit across both In Dev and QA columns. Later teams simply didn't bother differentiating, and simply have an "In Progress" column, forcing developers to actually talk to QAs when a card is finished (a radical idea at the time!).

Q. "What are our WIP limits?"

A. There was some interesting discussion around this, especially since all the teams were starting to actively encourage pair programming. They quickly realised that the WIP limit can be used to enforce pairing, but also allow a degree of solo development.

Remembering we have a team of 6 developers, initially they went for 3 in the 'Not Started' and 4 for 'In Dev/QA'. Considering the latter first, a limit of 4 allows 2 developers to work independently without pairing, the rest are forced to pair up.

The team quickly found that the 3 card 'Not Started' WIP limit was too small. It was running out too quickly, and it did not allow enough focus on what comes next (eg stories that naturally group together). It currently stands at 6, which definitely seems to be better without changing the cycle time too much.

The team is operating with no slack in their In Dev/QA queue. It's always full. This appears to be working so far, but there have been no "urgent, do now" stories yet.

Q. "How do we stop blowing our WIP limit?"

A. A problem quickly arose from the particular flavour of storycard discipline I teach. I ask people to start with a simple story, and write decisions and agreed requirements on the back to capture them as they are discovered - hence it's often useful to take it with you when working on the card. An avatar is used as the placeholder on the board to show what's missing.

It quickly became apparent that stories were being sucked into empty WIP spaces because the card was on someone's desk, even though an avatar was there; the WIP space wasn't "real". This meant the agreed WIP limit was being exceeded. This was the case even though the team only had enough magnets for the limit (magnets stay on the board, but were being reused).

They solved this initially by having 'placeholder' cards - generic cards that were swapped with real story cards. This carried on until the team had the discipline to only pull in cards when the magnets were in an "available" area on the board. (Photos to follow!)

Q. "How do we track our cycle time?"

A. Cycle time is the time from a story being pulled out of the backlog to be done to actually reaching "Done" - a critical measurement for planning. The solution for tracking this was elegantly simple - the Customer has a date stamp. When a card gets pulled in to 'Not Started', it gets stamped. When the Customer sees the story has been finished to his satisfaction, it gets stamped. No-one else is allowed to use the stamp, so the Customer has to see the story demonstrated. Simple.

Q. "I can't line up cards that follow a natural order"

A. This was a Big Issue for some of the team. Limiting the incoming work had an interesting effect - it forced people to talk to each other more! Especially the developer-customer conversations. Rigidly limiting the number of cards in 'Not Started' encouraged the Customer and Developers to work out what really needed to be there. An unexpected but valuable effect.

Q. "What about blocked stories?"

A. Many of the stories in the project are dependent on 3rd party software. So if that software is not working, the story cannot progress to "Done". It is blocked. There is no point in a blocked story blocking a WIP slot, so the team introduced the idea of a "Sin Bin" - stories that are blocked beyond the team's control. Stories in the Bin are monitored for progress, and when they become unblocked they are re-added to the backlog for prioritisation as normal. The Sin Bin also provided a useful visual indication of just how much work was being blocked by the 3rd party.

Q. "How do we show burndown/progress?"

A. This is the one issue that I am not yet happy with. How to estimate a finish date for a given amount of work.

On the one hand, there is the cycle time. No problem there. A story card start-to-finish is taking 3 days or so. But the problem is the extensive backlog. There is no guarantee that the stories are correctly sized, so either the team needs to go through every single story to make sure it is roughly the right size (or is an 'epic' equivalent to 2, or 3, or however many real stories), or to increase the size of a story to a "Minimum Marketable Feature" and track those.

I admit I don't like the idea of MMFs - in this context they would be too big a slice through the system and remove the benefits of iterative development. Currently the teams are taking the first approach - estimating epics as stories.

Another issue around planning is the external business. Like many companies, they are addicted to Gantt charts and are nervous about not having a definite statement that "this story will take x days". Story points and burndown graphs showing the real situation were not always well received because they didn't fit the "plan". Switching to counting cards is having similar problems, and is seen by many as an oversimplification.

Q. "We don't have timeboxes any more, so do we still need regular demonstrations? Retrospectives?"

A. YES! The teams demonstrate their progress to a wider audience of stakeholders every week. Everything demonstrated is truly "Done" - it is ready to ship. No smoke and mirrors, no mock layers, and everything running on the real product. This approach has been hugely successful in motivating the team, and ensuring the stakeholders know exactly where the issues are. By using a weekly heartbeat like this, any problems and decisions can be identified and addressed quickly.

Teams are still retrospecting every week too. However the next logical step would be to change this to ad hoc kaizen events as problems are found, and maybe holding a larger, formal retrospective less frequently.

Planning Games are held when required - i.e. when the 'Not Started' column is nearly empty. And because they only need to pick a maximum of 6 cards they tend to be brief.

So overall, how has the change been received? The main feedback from the people actively involved with the project has been almost entirely positive. Everyone feels that it feels like it is a more natural way to work.

From a coach's point of view, the change to "Scrumban" was far easier than I imagined. Why did I wait so long?

Don't just interview new developers. Audition them!

2010-02-03T15:09:00.002Z

It's such a common mistake. A company claims to be "agile" (whatever that is) yet keeps the old, stale accoutrements of waterfall interviews. The developer candidate walks in, answers random questions on what can relate to extremely wide and deep subject matter, and is then judged on their ability without them ever actually demonstrating that they can do the job. Sometimes the successful candidate really can fit in with the team, sometimes not. But most importantly, good, well suited people will inevitably be dismissed as unsuitable simply because they learn the principles and not the detail.

Being a "good" software developer is no longer about memorising a spec. The ability to regurgitate arbitrary sections of a language specification parrot fashion on request, although previously useful, has been de-emphasised by the invention of radical new ways to store information. Like books. And the internet. All you need are the basic frameworks, objects and principles; i.e. you know the bare bones, but look up the detail.

Nor is software development about how you react as an individual to unexpected coding puzzles while denied even the most basic of tools to help you - if the first reaction is "I wouldn't normally solve it like this..." (or worse, "There's a smarter way but you're not letting me use it") then the entire exercise is likely to be pointless. I have lost count of the number of companies who, over the years, have handed me a pen and paper, or a whiteboard marker, and expected me to write a technically correct solution to an abstract problem. No real world example, so it's not real world coding.

Agile teams are about people and the way they interact. It is all about being able to work smart. It is about being able to write good code collaboratively, helped by tests. The recruitment process needs to put more emphasis on interactions, initiative, and ability to process unfamiliar information - the wetware aspect of development. So what if you cannot remember the exact interface to QuadCurve2D? As long as you know it exists and understand the design patterns it is based on you can look up the details.

So how to identify the right people for the job if traditional interview techniques don't work?

Simple. Audition them. Get the candidate actually doing something related to the job they have applied for. Do they look for the right things from the start? ("Where's the continuous integration server?", "Where are your tests?"). Get them down and dirty in the codebase, see their reaction. Do they get lost in the detail, or do they start to tease out the structure with tests? Code with them. Cooperate with them. Can you work with them? Does their coding behaviour fit team culture? How fast do they learn? Are they a craftsman or hacker?

You could even say you are unit testing the developer.

Auditions do require a little more effort, but in my experience they take some of the guesswork out of the traditional interview process when trying to find good people for the team.

Sign up for change

2010-02-02T12:47:00.002Z

The Independent has recently published an article highlighting the state of the UK Government's IT projects. Let's just say that it's not a success story:

...the total cost of Labour's 10 most notorious IT failures is equivalent to more than half of the budget for Britain's schools last year. Parliament's spending watchdog has described the projects as "fundamentally flawed" and blamed ministers for "stupendous incompetence" in managing them.

Think about it. That's £26 billion of taxpayers' money down the drain because of "fundamentally flawed" projects and "stupendous incompetence". Putting this into context, university funding is being cut by a mere £449 million next year - so we are cutting investment in our future, while frittering away £26 billion on avoidable failures. Epic Fail.

I have already suggested that these failures are likely to have been entirely avoidable. So have others. But there needs to be a fundamental change in the way that Government IT projects are run.

Rob Bowley has started a petition to Number 10 to try and raise the profile of this problem with the Government. It reads:

We the undersigned are tired of hearing how much of our money is being blown on failed governemt IT projects.

We believe that this is mainly due to the nature in which these projects are firstly procured and then delivered - that of demanding and committing to all the requirements for enormous projects up front, consigning them to failure before they have even begun.

The private sector has mostly moved away from this failed model to an incremental approach, which allows for changes in understanding and requirements and enormously reduces the chances of failure. It's about time our government did too.

We ask the Prime Minister to demand a review of the current approach and look at adopting a more incremental and agile approach to Government IT projects

Whether it makes a difference only time will tell, but I urge anyone who cares about public sector IT development to sign it. Any journey starts with a first step, and this might be it.

Japanese Proverb

2010-01-22T12:21:00.002Z

Just read an article containing this Japanese proverb:

"If you don't know what to do, take a step forward"

It's been a long time since I have read anything that sums up iterative improvement quite so well.

Using agile tools takes away some of your intuition

2010-01-21T15:06:00.001Z

It's no secret, I really don't like using tools to run agile projects. More than that, in my opinion giving an inexperienced agile team an "agile tool" is like giving a toddler a chainsaw - it's going to end badly. Give me index cards, pens and a whiteboard anyday.

Allan Kelly has beaten me to blogging about tools - and hit upon an interesting anecdote from Jack Kilby, inventor of the silicon chip. Basically Jack believes that the replacement of the slide rule with calculators has taken something away from engineering. Intuition. Using a tool (the calculator) distanced the engineer from needing to know what he was doing (the calculation). As someone who has used both calculator and slide rule, I tend to agree.

And here lies the problem with agile tools.

Using complex tools takes away a basal intuition about what you are trying to do. You lose that indefinable "connection" with the product. You might even say you lose the craftmanship. Another illustration might be the difference between bland, machined furniture and furniture that has been hand crafted by skilled cabinet makers - building 'by hand' copes effortlessly with the small, unexpected imperfections that rigid machine programs do not cope well with, resulting in a more polished product. That's not to say the cabinet makers don't use the occasional power drill or sander - but they understand when it is appropriate.

So stick with cards and pens at first until you understand when using tools (and which one!) is appropriate. Keep you intuition intact. Your product will be better for it.

Have tea with Energized Work

2010-01-19T13:19:00.001Z

Those nice people at Energized Work have extended an offer for an informal chat - all for the cost of a cup of tea (or coffee, in Gus' case, although I've heard he is quite partial to green tea).

So if you would like to see a presentation, or brown bag, or simply want to chat with the 2009 Gordon Pask Award winners and see what makes them tick, then drop them a line.

One thing I can guarantee - you will find the meeting challenging and productive.

Services, clients, chickens and eggs

2009-11-30T16:43:00.003Z

I find it remarkable how some teams manage to invent new and exciting ways to undermine the benefits of agile process and principles. The latest I have come across is what I have started to call the SOA chicken and egg dilemma - how do you develop a service and an associated client?

Here is the wrong (but sadly too common) way to approach this. Mock the client, build the service. Then mock the service and build the client. Then integrate. Each step being presented to the Product Owner as “done” separately. Worse still, some projects are using separate teams to develop each side.

See the problem? It’s mini-waterfall. Make the service, make the client, make it work. It can’t be used until you have developed both sides in isolation and integrated. Each side is based on BUFD assumptions about what it should do, and not what the system needs to do from a user perspective.

OK, so how would I handle this? Slice the functionality, not the components. Pick a nice, easy user oriented function involving the client-service combo, and make it work end-to-end. Then pick the next piece of functionality, make it work, thickening the slice. Iterate until sufficient. By all means use mocks to make life easier, but don't mislead yourself and your customer into thinking that if it works with the mock it’s ready to ship. Only ever demo as complete using a real client and service.

By approaching the problem in this way you get all the usual benefits - ability to ship working functionality as far as has been implemented, fast identification of design problems, ability to finish when there is just enough functionality.

The principle underlying this approach is simple. Done is DONE. No smoke. No mirrors. No excuses. If it can’t ship it ain’t finished.

Government IT failures - could we do better?

2009-11-03T11:54:00.005Z

Once again the UK Government has a failed IT project. Failed as in almost three times over budget (an approximate overspend of a whopping £456 million), 3 years late (and still not delivered) and not satisfying fundamental requirements.

The chairman of the committee commented, "There was not even a minimum level of competence in the planning and execution of this project." Ouch!

So what went wrong? From the Public Accounts Committee report it appears that some of the key issues were:

Underestimating technical complexity
Underestimating the need to standardise ways of working to avoid excessive customisation
Poor planning
Poor financial monitoring
Poor supplier management
Too little control over changes

Costs and progress were not monitored for 3 years?!

Sounds familiar? It does to me - it smells like a typical "throw the requirements over the wall and hope" waterfall failure pattern.

But would a more agile, flexible approach helped us here?

Continuous delivery of requested features that were truly "Done" and ready to ship would have highlighted the project was floundering early. Iteratively delivering real features enables open, honest and irrefutable reporting, including useful data like estimated end dates, and cash burn so providing financial monitoring.

Highlighting a failing project early allows the right conversations to take place, leading to corrective action before the situation is critical. It is highly likely that problems with work practices, excessive customisation and technical difficulties would have been identified and fixed early.

Finally, controlling changes. By making the resistance to change as low as possible and applying a customer focussed "what is important" criteria the system would have had the most valuable features implemented first. This ensures the true nature of the project reveals itself very quickly - so if it is technically complex, it is discovered quickly and either mitigated (maybe the difficult feature is not that important after all?), or the project can be shelved or cancelled completely.

So in my view, using some common sense could have helped this project deliver, or at very least not burn £456 million in a failure.

There are two more points I would make. I don't know who was to blame, nor do I care. But I can see two fundamental behaviours that compounded a bad situation:

The Government abdicated its responsibility as Product Owner. Allowing a team to go dark for 3 years, especially when they have effectively a blank cheque, is simply ridiculous.
The Supplier abdicated its responsibility as development team. Even if the Product Owner is not engaging fully, I believe that a Team has a professional responsibility to inform them of progress, good or bad.

I see these failure modes all the time. But it does not have to be like this - there are a growing number of genuinely professional companies, teams and developers who could improve on this performance if only they were given the chance.

Liskov Ducks

2009-10-27T09:10:00.001Z

In case you missed it, here is the Liskov Substitution Principle summarised in a handy motivational poster.

(from a set of originals by Derick Bailey, released under Creative Commons)

Burn up? Burn down? Who cares?

2009-10-27T09:02:00.000Z

It seems that some people have some quite strong views on the "right" way to track progress. Here's my view.

In the red corner, we have the traditional burn-down graph. You start with a certain amount of estimated work, and as you finish it you cross it off the list. You finish when you hit zero.

In the blue corner, we have the burn-up graph. Here you still have a certain amount of estimated work represented as a line across the graph. Work is added cumulatively and you finish when you reach the target amount of work.

OK, so what's the difference? In my opinion, not much. Some suggest that a burn-up graph is psychologically more motivating because it is going up. Others I have spoken to prefer to see completion as zero, and like to see work left heading downwards. Personally I'm with the burn-downers.

Another factor in choosing which way the burn goes might be ease of changing the goalposts - in other words, how easy is it to add or remove from the backlog estimate. Let's throw in 50% more unexpected work into iteration 7:

Again, much the same. Personally I prefer the burn-down since to me it is more obvious that work has been injected, but again, others mileage varies.

So does it make any difference which you use? Is one "better" than the other? In my opinion, no. Having used both, as far as I can tell it makes no difference whether you burn-up or burn-down. Decide which suits you/your team and don't get bogged down in unnecessary debate about which is best. The important thing you are doing is tracking real progress, and adapting to what it is telling you.

That said, I have no doubt that debating the pros and cons of burn chart direction makes for a fascinating late night bar conversation at the conference of your choice....

So you want to be an Software Craftsman?

2009-10-26T16:58:00.000Z

Dear aspiring Software Craftsman,

Here is my advice.

Take whatever courses you think are interesting.
Study closely the work of the Old Masters.
Stop writing software that was only designed in your own mind.
Stick with one technique until you perfect it.
Buy a book on software structure. It's the only book you need.
Until you can write a program without bugs you don't know how to program.
Stay away from Javascript. You'll never master it. Very few ever have.
Forget about commercial frameworks. Use Open Source. It's where the action is.
Visit an old age home. Talk to the people who remember 8 inch floppy disks and punch cards.
Learn to play chess.
Take a business course.
Do not use an MP3 player.
Learn a foreign language. Scala should do it.
Learn to cook. Please. Before you get scurvy or rickets. There are more food groups than pizza, coffee and chocolate bars.
Learn to play a musical instrument.
Learn to swim.
Do not litter.
Avoid politically correct people.
Avoid anyone who says "We have always done it this way".
Take away the keyboard of anyone who says "We need a bug database".
Remove the Version Control account of anyone who claims to write bug free code without tests. Better still, take away the account, and their PC, and desk, and chair just to be sure.
Listen to classical music and jazz. If you are unable to appreciate it at least as much as contemporary music, you lack the sensitivity to develop into an craftsman of any real depth.
Keep your word.
Do not work with anyone who you do not trust.
Never explain yourself. Better yet, never do anything that will, later, require you to explain yourself or to say you're sorry.
Always use spell check.
Stop aspiring and start doing.

I can't guarantee anything, but this is how you might, just might, become a software craftsman...

(Thanks to HR Giger's agent, Les Barany, for inspiration and some of the ideas that seem to apply to both crafts)

Congratulations!

2009-09-13T12:08:00.003+01:00

My buddies at Energized Work, Gus Power and Simon Baker, have won the Gordon Pask Award for Contributions to Agile Practice.

Their "No Compromise No Excuses" approach has proven incredibly successful, and is helping many in the industry raise their game, myself included.

Congratulations guys!

Of Waterfalls and Ponds

2009-09-13T11:20:00.002+01:00

Just found a great metaphor to contrast waterfall development with agile. Agile is more like a pond. And you get a picnic at the end!

The Opposite of Waterfall is Pond

Thanks Alan Atlas for a very clear, beginner-friendly metaphor.

Agile is Dead. Long live Agile!

2009-06-25T12:04:00.001+01:00

It seems that right now "agile" is flavour of the month everywhere.It has hit the mainstream. Everyone has it on their CV, too, so we have a situation where the industry want the skills, and everyone has the skills. Everything is fine and dandy in the software industry. Right?

Dead wrong.

There is a disturbing trend appearing in the industry. It is becoming increasingly difficult to identify anyone who has genuine agile experience. Many developers, BAs, QAs and product owners declaring agile experience on their CVs, when put into a true agile/lean environment struggle to cope (to say the least). To give typical examples, consider the developer who claims "agile" experience, but does not understand (let alone able to write) unit tests or the power of automated build systems. Or the "experienced agile" guy who had a Gantt chart showing the story contents of every iteration. Or the teams who believe it is acceptable to leave the build broken for weeks on end "because it's too difficult to keep it green". I could go on. If this is the level of agile experience on the average CV, it's a joke.

The only explanation I can offer for this is that the cargo cults and corporate pseudo-agile processes are finally strangling the real deal. The team members now being churned out by these behemoths only have experience of a pale imitation of the real thing. The end result? As far as I am concerned, putting "agile" on your CV or job ad is completely worthless. Agile is dead.

Or is it?

There are still islands of excellence out there. There are still people who who actively remove wasteful practices and work leaner, faster, better. There are still companies who are trying to build experienced agile teams in order to build quality products using lightweight processes and have fun while doing it. There are companies and people who demand more, demand better. But how to find them? How can they avoid the wagile hiring trap? Two ways.

Firstly, word of mouth. Personal recommendation by someone you trust is always the best way of doing things. I have a personal network of developers, Product Owners, BAs, QAs etc who I have worked with and rate highly (you know who you are). These are the guys I would work with myself, hire should the need arise, and also recommend to others. If a client asks for recommendations, these are the guys I phone first to see if they are free. Hiring a Coach is a good way of tapping into these kinds of lists (yes, a shameless plug, but true :-) )

But what if you don't have any way into this kind of network? Since having "agile" on a CV is now so devalued, the only choice has to be audition. Get the applicant into the office. Pair with him for an hour or so. Solve a real-world problem with him. He obviously talks the talk to get this far, but can he genuinely walk the walk? If you don't have anyone experienced enough in genuine agile process to do this, don't be afraid to hire someone to do it for you - another example where an experienced Agile Coach can come to the rescue.

So long as you vet your team rigourously, any reports of the death of agile will have been somewhat exaggerated. Although somewhat beaten and battered, lightweight processes are picking themselves up and are faster and stronger than ever before. Whatever form they evolve into (agile, kanban, lean, call them what you will), lightweight processes are still the sensible way to develop software.

If you want to go faster, raise your internal quality

2009-05-28T10:47:00.001+01:00

Mike Hill has written an excellent article titled "How TDD and Pairing Increase Production"

An excerpt:

"If you want more production, look first to raising your internal quality.
...
All day long, every time you make a move, you will be depending on the code that’s already there. Every line of it you have to study will slow you down. Every extra open dependency will slow you down. Every bad variable name will slow you down. Every flawed design decision, be it big or small, will slow you down.

If you want to work as fast as you can, you want to work with clean code. Period."

There are many more thought provoking truths in there. Read it! It might just change the way you write code.

Something to ponder

2009-03-17T19:16:00.002Z

If you get an infinite number of non-test-driven developers programming in a room for an infinite amount of time, would you end up with the works of Shakespeare?

What is this software craftmanship thing anyway?

2009-03-12T16:36:00.003Z

There's a buzz in my tiny corner of the industry at the moment. "Software Craftmanship". But what is it exactly?

I for one am not sure. Currently it seems to be all things to all people, but with a common theme of quality running through it. Some think it's fairly hardline, others think it needs to be flexible and all-encompassing. But one thing it's not - it's not just about agile or lean processes and practices (although personally I think they are a significant step in the right direction). So what the hell is it? Here's an attempt at defining what it needs based on existing professional engineering and other disciplines that could be considered craftmanship (for example, carpentry, surgery, architecture/building and so on).

It needs a set of ethics. This is what keeps you honest and provides a structure on which you can base decisions. Ethics tell you when to walk away when you are being asked to compromise too far. They provide the line in the sand that you do not cross. In XP, these are the Values.

It needs a set of tools and techniques that are the generally accepted best way of doing something. Think about a stonemason, or cabinetmaker - they use specialist tools in specific ways. Also a surgeon has an array of specific techniques to handle different situations. Note that there is absolutely no reason why there should not be multiple ways to achieve the same results here. However, unfortunately for us the software industry is notorious for aggressively defending personal preference and style over and above effectiveness and quality so there are plenty of red herrings to remove.

It needs continuous learning. A master craftsman will always be experimenting with things, looking for new tools and techniques to add to the entire craft. Since these new techniques are outside the accepted practices, they can be carefully assessed in controlled conditions in much the same way that, say, a surgeon would try a new procedure with extra precautions, or a master stonemason would try something new on a cheaper, expendable offcut of stone first.

It needs apprenticeship. Beginners and journeymen need to teach and be taught. An apprenticeship model works extremely well for this - see something, do something, remember something. Plus by working alongside master craftsmen you learn the nuances that can never be documented.

Once the majority can agree on the values, principles and practices that fit these four things, then - and only then - can we really claim to be software craftsmen. Until then it's simply another forum flame war.

Let the Craftsmen Craft Software

2009-03-10T14:48:00.007Z

There are times when the software industry makes me despair. Making an analogy with someone building a house, you wouldn't:

Hire the cheapest cowboy builders you can to build your house. ("'We build you house very cheap. £500', 'OK, you're the cheapest. It's a deal!'")

Hire skilled builders but force them to compromise by refusing to supply them with the resources they need ("Oh we can't let you use electricity. Or petrol - it's a fire risk. Or let you move that fence that is in the way. Or..."), restricting their working environment ("You can plaster that room, but you have to do it through the letterbox") or by unreasonably restricting budget ("you can only buy the cheapest bricks").

Hire skilled builders but tell them how to do the job, despite not knowing anything about building ("Don't lay bricks like that. Stack them, don't overlap").

Also you wouldn't make the same mistake when building the house again and again when it collapsed, expecting that somehow things will be different this time around.

You absolutely would not build a house like this. So why expect to deliver software successfully like this?

Here's a dangerous idea for you - hire skilled people, provide them with what they need and let them do what they do best.

Groan

2009-03-05T09:47:00.004Z

A recent exchange between me and a non-developer, trying to explain that some Scrum Masters are better than others:

Me: "Scrum Mastering is pretty much the same as Team Leading. To find a good one you need to look at their past. They almost need a 'pedigree'."
S: "Oh, you mean Pedigree Scrum?"
Me: "Yes. They need to eat their own dogfood....."

At that point we had to temporarily abort the conversation.

OK, maybe you had to be there....

Scrum needs XP

2009-03-05T09:45:00.000Z

I stumbled across a blog post about Scrum's origins on Jeff Sutherland's blog recently. The whole thing is worth a read in order to get a perspective on where the methodology came from, but especially interesting was the following comment:

"Few implementations of Scrum achieve the hyperproductive state for which Scrum was designed (5-10 times normal performance). Those that do all implement variations on XP engineering practices..."

This fits with my - and others' - experience over the past few years. Scrum, with a few tweaks based on personal experience, provides a good starting point for a lightweight management framework. But that's just it - it's a management framework. You need wrap something to be managed in it. And if that something is a lardy, slow mini-waterfall process then you will simply end up delivering stale garbage more efficiently.

XP has the opposite problem. It provides tools and techniques to develop quality software efficiently, but it does not provide any guidance on tracking or how to control requirements. It benefits from being wrapped in something to manage its external dependencies.

Combining Scrum and XP may not be the only way to develop software but it does seem to be a damned good starting point for further iteration. Do it - you know it makes sense.

The Right People

2009-03-02T18:12:00.010Z

I talk a lot about getting the "right people on the bus" when talking about teams, especially agile teams. Quite simply, by ensuring the people involved can all pull together rather than undermine each other makes a critical difference to the success or otherwise of the team. Research suggests that this is more critical than we might think.

But how do you find these people? How can you recognise them? What traits do these people have? I've had a go at nailing down specific behavioural traits based on my experience of working with good - and bad - engineers over the years. In no particular order:

Courage. The "right people" that I talk about are courageous. They overcome their fear of being wrong and are prepared to challenge ideas. They are also "doers", people who have the courage and motivation to get up and make a change where it is needed.

Pride. Not the damaging kind, but pride as in wanting to do a job well. Professional pride is definitely one trait that separates a money focussed Mortgage Driven Developer from a Software Craftsman. Striving for improvement is always valuable.

Respect and Humility. Being humble is hugely important when working closely with others towards a common goal. It is the ability to sit and listen without judgement, then provide feedback and respectful challenge. It is the ability to admit when you are wrong. The ability to resist pointing fingers and scoring political points when others stumble. From humility comes respect.

Curiosity. I cannot think of a single successful developer or manager who does not play with new technologies and/or techniques to see if they are useful. If they work, they get added to their toolbox. If they don't work, they get put to on side until they find a use. Active curiosity stops people from getting stuck in a rut and proves they have the ability to learn.

Communication. The ability to communicate is essential. Gone are the days when developers can "go dark" for weeks on end. Active, regular communication engenders understanding. Rolling this ability in with respect, humility and courage creates a powerful mix that gets results.

Sense of fun. Fun is a useful way of releasing potentially damaging stress. I also think it is massively undervalued in the workplace. In my experience, people who have fun tend to be better motivated and have a better work-life balance than those who are 100% focussed on serious work. The better balance allows them to deliver day in, day out. And sometimes a Nerf duel is simply the only way to settle that pointless design argument....

People who have these traits are rare but worth seeking out - they are definitely out there. If you can build a development team of these kinds of people then you really will have a team to be reckoned with - if you put them on the right bus...but that's another article.

One bad apple spoils the barrel

2009-03-02T15:46:00.003Z

Via Coding Horror:

"A recent episode of This American Life interviewed Will Felps, a professor who conducted a sociological experiment demonstrating the surprisingly powerful effect of bad apples."

This is not news. In fact it's something that I and other coaches have suspected for many years. But this study provides some more scientific backing for our suspicions. In short, even one misbehaving team member can upset the entire team and endanger delivery.

Getting the right people on the bus makes life much easier, massively reducing the risk of introducing agile thinking to a company and increasing the chance of successful delivery. OK, the study also suggests that a good facilitator can defuse the effect of the Bad Apple, but as the study shows, people capable of doing this are few and far between (only one team out of the entire study had a team lead capable of counteracting the problem).

Oxymoron

2009-02-17T08:53:00.004Z

Just spotted in a job ad for a lead developer:

"You will be expected to implement a rigorous Agile Development process and work with the Technical Architect who will define the technologies and toolsets"

Website revamp, stage 1 complete

2009-02-04T14:07:00.003Z

Finally, after several days of thinking, searching for templates, scratching head over the CMS and rewording, my poor, neglected website has been revamped. Or at least Stage 1 is complete, and it is now in a state where I can iterate further changes over the weeks/months/years. It now reflects more accurately what I actually do these days, which is an added bonus!

Don't compromise quality for speed

2009-02-03T09:44:00.004Z

Ron Jeffries has just blogged about dropping quality in favour of speed. Take a look at Quality-Speed Tradeoff — You’re kidding yourself. Having seen many, many projects fail because of this common fallacy, it is a subject close to my heart (but there goes the draft blog article I was writing....).

In summary, there are two choices. Subjective historical addenda are mine based on my experience:

Reduce quality to go faster. You might get ahead short term, and you might even get ahead longer term if you don't add too many bugs and if you don't make the code uninhabitable. [But history is really not on your side here.]

Increase quality to go faster. There is a chance that you will over-polish and not add important business functionality. [Historically this will not happen. Especially if you make this possibility an integral part of the quality process by holding regular customer product reviews and focus on delivering important business value first.]

Google-oops!

2009-02-02T17:56:00.002Z

It would seem that someone at that fine institution Google had a bit of finger trouble over the weekend.

I can't help thinking that some (more?) unit testing might save them a whole world of pain and panic in the future.

'nuff said.

Bletchley Park Needs You!

2009-01-30T11:29:00.007Z

Bletchley Park is an unremarkable, run-down country estate in South East England. Unremarkable, that is, until you realise that it was where a team of boffins, including geniuses like Alan Turing, broke the German Enigma code in WW2. This allowed the Allies to intercept vital information and save countless lives. It is also likely to have significantly shortened the war - maybe by up to two years and 22 million lives. Its place in history is assured by this alone.

But even more remarkable, in order to break the code the scientists had to invent from scratch the first ever electronic computer - Colussus. Thanks to the efforts of Max Newman and Tommy Flowers and many, many others we have the computers we have today. Through their efforts, we have the software industry - the productivity tools, the games. We have levels of communication no-one could have dreamed of back then - mobile phones, satellites, GPS. We went to the moon, and are now eyeing up Mars and beyond. We have the ability to carry out advanced research, analysis and ultimate cure of crippling diseases. The potential they unleashed is endless.

Now a museum and tourist attraction, Bletchley Park is suffering from a crippling lack of funds. They need a huge amount of money to restore it to its former glory (around £10 milion). Anyone involved with the IT industry should be concerned by this - Bletchley Park represents the birthplace of our industry and as such deserves to be saved. So I urge everyone to donate just £5 to the cause, more if you can.

Also, if you have a blog or website, promote Bletchley Park's cause. Spread the word.

Yet another name for compromised agile process

2009-01-28T17:08:00.003Z

Via Simon Voice:

wagile adj a cross between agile and waterfall process. The mess that's left if agile is only partially implemented without cultural change. See also: failure, compromised, doomed

Re-energised

2009-01-21T19:08:00.006Z

I have just finished doing my own, personal retrospective of 2008 after spending a couple of weeks relaxing and decompressing. Definitely a cathartic experience that has left me re-energised and ready to go in 2009.

Highlights:

2008 saw me go into several flawed companies/teams in succession as well as some well adjusted ones. Although I delivered results, they were nowhere near the level that I am used to getting, and the battles to get even those results were long, protracted and draining. Portia Tung wrote about something she called "The Wall". Well, I found my wall last year and although I managed to scale it, it wasn't elegant. So in 2009 I intend to only work with well behaved clients who genuinely want to change, or have already made the change to agile/lean thinking but need guidance. Life is too short not to. Consulting should not be a battle, it's a co-operation. More of that in a later blog post. But I also need to understand better what my personal "wall" feels like, how to recognise it more quickly and how I don't just scale it but burst through it.

One of the related problems in 2008 was isolation. Sometimes when you work as an independent consultant you can feel very alone and begin to lose focus (the ancient wood for trees syndrome). You really need to bounce ideas off like-minded people to identify root causes and figure out new and exciting ways to deal with them. So I intend to kick off a peer review group amongst some trusted friends and colleagues and see how it goes. I have used the peer review approach before but this will be more challenging since the people involved are likely to be on entirely different projects....

Last year I neglected the important-but-not-urgent stuff. Things like this blog, going to conferences, networking with people, getting the industry vibe. That sort of thing. So expect more blog posts, and watch out for me at the odd conference. I might even present at one (although it's probably too late for 2009).

In 2008 I learned a helluva lot about myself and the state of the agile nation. I am entering 2009 better educated and more aware of the issues which can only make me better prepared to recognise and solve some of them.

I had nowhere near enough fun last year. It was far too serious, filled with destructive conflict and injury instead. So I fully intend to make 2009 a better year - both at work and in my personal life.

So here's to a happy and prosperous New Year packed full of learning, delivering top quality software, and fun, regardless of what the current economic situation throws at us. Cheers!

You don't need bug tracking

2009-01-19T15:07:00.002Z

I have just been reading a thread on an agile group discussing the best practice for bug tracking in an agile team. Almost everyone has immediately jumped in and suggested things like Bugzilla and Jira. At risk of this turning into a rant:

You do not need a formal bug tracking system in a healthy agile development team

Quite a sweeping statement. Let me explain.

The whole problem seems to come from a fundamental misunderstanding of what a 'bug' is. I define a software bug as "undesired or missing functionality". Now let's compare this to a definition of a 'story' - a story is a statement describing the desired functionality - i.e. it is an invitation to correct undesired or missing functionality... Sounds familiar!

In other words bugs are stories. And if they are really stories, then why treat them differently? Simply write them on cards1, throw them onto the backlog and let them be prioritised along with everything else. Bugs that are important to the Customer will always be done first. Unimportant bugs will get fixed eventually/never in the same way as unimportant stories would.

[1] I use red cards so that bugs are visible in the backlog. That way if they start to multiply the team can stop and fix the problem causing it.

Twitter

2009-01-13T10:20:00.003Z

I have been playing on Twitter for a month or so to see if it could be useful.

As yet I'm undecided, but it has been useful enough to capture idle thoughts on the run so I'll stick with it for a while longer.

For anyone interested in following my random ramblings I can be found here.

When weekly iterations go bad

2009-01-09T13:25:00.002Z

Having tried several different iteration lengths over the years, I now tend to recommend iterating weekly. It provides maximum flexibility and adaptability while being extremely intolerant of waste - problems are quickly surfaced with such a tight feedback loop.

But it does not always work as I found out over Christmas.

Our live system broke. Something ate some important files so the app collapsed. This was quickly traced to the Jetty servlet container deploying to the /tmp directory by default. Not a problem in itself, but there was a default cron script that helpfully tidies up /tmp by deleting anything that has not been touched for 10 days.... Of course, the Team was in Christmas shutdown for two weeks, and sure enough 10 days after our last live deploy...<BOOM!>

We missed this because we were using weekly iterations. We were deploying to the various dev, QA, demo and live systems every week so the deployed files were never older than 7 days.

So beware...weekly iterations can bite back!

New kid on the blogosphere

2008-12-21T15:14:00.004Z

My friend, Simon Voice at Connections, has just started his own blog. I know he has some interesting views on the whole agile software revolution as viewed from a recruiter's perspective, and already has some interesting posts on there.

What a difference a sand timer makes....!

2008-11-20T13:34:00.001Z

Planning Games can be a problem. Especially with large teams where it is difficult to get consensus, and also far too easy to descend into lengthy discussions where different people are in fact violently agreeing with each other (at least in terms of what size something is). What should be a simple one hour maximum meeting to scope out the relative sizing of specific business stories can turn into a Dilbert-esque four hour meeting from hell.

Classic Planning Poker rules suggest using a timer to try and avoid these kinds of situations. Anyone can start a two minute timer, and at the end of the time the team must estimate. Limiting the amount of time gives a degree of pressure and focus to the discussions especially when there is disagreement. Also it limits otherwise lengthy discussions where in fact everyone now agrees on the estimate.

I the past I have tried using this technique with some teams that had a tendency to get bogged down but with limited success. I have tried using a mobile phone, but people found it too complicated to set up quickly and easily. It was also too "personal". A stopwatch did not achieve the right results either - it was simply ignored probably because it counts up an not down. And I have never found a decent egg timer that is easily and accurately settable to two minutes (same problem as the phone). Then I stumbled across a kids 2 minute sand timer....

(Yes, it really is that pink!)

What a difference the low-tech solution has made! It's easy to start (!), obvious when it's running and/or running out and does not disrupt the flow of conversations. Everyone I have spoken to has agreed that it has saved time. It has not always worked, but in general the signs are positive so far. I have even seen the timer being used in other entirely unrelated meetings.

Black Hole Team

2008-05-13T13:19:00.004+01:00

Have you ever noticed how some teams do not have a "buzz"? That certain energy that differentiates a good team from a great team. Anyone who has worked for any length of time in software will almost certainly have experienced the lacklustre plod of a team in crisis.

But there is a rarer but not unknown phenomenon created by the further collapse of teamwork and common sense. I call it the Black Hole Team. Here, all joie de vivre has been crushed out of the team. All hope of changing, evolving and improving working practices has been extinguished. Team members are simply coding zombies, attending work not out of pleasure or professional pride, but instead simply to churn out second rate code that gets them from 9 o'clock to 5. By this stage the team has become so dense (sic) that new team members have the life and energy actively sucked out of them until there is just the shell left.

So just how does a team collapse to this level? The ways are many and varied, but common problems include:

Unsupportive leadership. If a team tries to improve but is simply not allowed to action the necessary changes, eventually they will give up trying to improve.
Political environment. Politics poisons software. Period. Engineers need to have the space and encouragement to improve, but are generally not political animals - most find it distinctly distasteful at best.
Poor environment. If a team is working in a physical environment that is uncomfortable, or that stifles free communication of ideas, and cannot change things then they are in serious trouble. Nothing says "The company does not give a stuff about this project or this team" as lousy desk spaces.
Cliques. It is possible that a significant minority of the team has worked together before and are now fixed in their ways. Bulldozing through stale ideas and techniques at the cost of innovation leads to damaging conflict unless justified by genuine hard facts and discussion.
Random edicts imposed from outside the team. Again, this kind of thing makes a team feel unvalued especially if they have already solved a problem adressed by the edict in a more efficient manner. It sends the clear signal "they can't be bothered to work efficiently so why should we?"
Professional pride. Yes, untempered engineering pride in delivering a good product despite the odds can be counterproductive. This misplaced loyalty will gradually be replaced by contagious cynicism, despair and even active undermining of product in extreme cases.

Pulling a team out of this state can be achieved by two things. Leadership and the authority to make certain key decisions (they don't always go together). The aim is to get back to a working environment that is seen as safe to work in, where suggestions are respected, considered and actioned, where the team has the ability to change and adapt anything to get around waste that is stopping the job getting done. Things to try:

Get the team what they want. Accomodation bad? Improve it. Get the team identify key areas for improvement and then make sure it happens.
Remove the politics and focus on delivery and adding value.
Correct or remove disruptive team members. I have said before, there is no point in trying to change the behaviour of someone who does not want to change, but the person causing trouble may not even realise they are doing it. Use one-to-ones and talk to them, but be prepared to move them to a more suitable team.
Break up cliques. In the same way as individuals can disrupt a team, so can groups. Split them up and use them to form two or more experienced teams.
Protect the teams from random edicts. Try and understand what the underlying business requirement is, and negotiate a mutually acceptable solution with the help of the team. Another more subversive strategy is to ignore it until it becomes inevitable - often no-one ever notices. If becomes impossible to ignore then make sure the true cost of the decision is fed back to all interested parties, especially your customer since I can guarantee that he will not be happy that it's costing him!
Disarm the professional pride problem. Persuade people to go home at a sensible time.

Give people the space to fail, to learn. Show that they are valued even when the going is tough. You will still have the loyalty (more, in fact), but it will be sustainable even on the most challenging of projects.

All of these actively demonstrate that the team - and by implication, the project - matters. When a team knows they matter you will be amazed at what they can achieve given the chance.

Selenium and HTTPS

2008-05-13T13:12:00.002+01:00

This is documented elsewhere, but here it is again:

The problem - you want to test a web site where you get a popup to accept an unrecognised certificate, eg when using a self-generated certifictate. Selenium cannot click on the resulting confirmation window, but worse still Selenium does not store your decision even though you have selected 'permanently accept' manually the first time.

The solution - basically Selenium is launching a clean copy of the browser each time. So you need to create a persistent profile to use each time.

As far as I know this is only possible with Firefox.

Create a new Firefox profile (firefox.exe -profileManager). In this case the name of the new profile is selenium-https-profile

Add the certificate to it Add a suitable .pac to redirect to the SeleniumServer

function FindProxyForURL(url, host) {
if(shExpMatch(url, '*/selenium-server/*')) {
return 'PROXY localhost:4444; DIRECT';
}
}

Start the server

java -jar selenium-server.jar -firefoxProfileTemplate "C:selenium-ffox-profile"

Use the *custom target in your Selenium client to start Firefox with the specific profile

*custom C:\Program Files\Mozilla Firefox\firefox.exe -P selenium-https-profile

Seagull Architects

2008-05-13T13:08:00.003+01:00

How familiar does this sound? Your Friendly Neighbourhood Architect flies in, makes a lot of noise, craps all over the design without any sort of interaction with the user or codebase and flies out leaving the Team to tidy up as best they can....

Unfortunately Seagull Architects are still out there causing a nuisance on all types of project, not just agile.

So please, Do Not Feed the Seagulls....

(Note - there are unconfirmed reports that Seagull Architects are evolving. Into Vulcan Architects. Here they walk in, Vulcan-mind-meld with the requirements and codebase (again without any real interaction with customer or real world code), and announce the design required. "That's illogical, Captain")

Quote of the Day

2008-03-13T10:58:00.001Z

From The Inquirer (of the latest Firefox 3 Beta):

"Still it does make Microsoft's IE7 look like a bloated asthmatic slug towing a caravan full of elephants in comparison."

Now there's a vision....

If you think you're beaten...

2008-02-21T12:58:00.002Z

If you think you're beaten, then you are.

I have recently been involved with a team where key players spent enormous amounts of time and energy trying to identify reasons why we shouldn't try things.

Working with people like this drags down the entire Team. It lowers morale because it becomes harder to make the changes that energise the working environment. The Team knows that it can never get better because the naysayers will do their best to block change and maintain the status quo.

If only people would spend time and energy actually fixing the problems instead of finding reasons to justify substandard tools, processes, practices and behaviours.

XP Day: Agile is a brand

2007-12-11T15:29:00.001Z

An interesting truism from XP Day's final session, Have We Lost our Mojo:

"Agile is a brand."

If it is, then it must have some kind of value. Therefore it is worth protecting from second rate imitations.

Schrodinger's bug

2007-12-11T15:14:00.000Z

A bug does not definitely exist or not until you exercise the code.

You can either let your users find it, or you can write tests to flush it out.

It's your call.

XP Day: Have You Compromised Your Agility?

2007-12-10T15:01:00.001Z

One of the more interesting sessions I went to during XP Day this year was the "Have You Compromised Your Agility?" session run by Gus Power and Simon Baker. Run in World Cafe format (complete with tablecloths and candles!) it set out to create an informal environment to discuss whether corporate attitudes are forcing agile and lean thinkers to compromise a step too far in order to become acceptable to traditional corporate culture.

OK, I admit it. I was a plant. No I wasn't quietly photosynthesizing in the corner, I was invited there by Gus and Simon to be deliberately provocative, forcing difficult issues out into the daylight. My table was focussed on "Values". Specifically, the premise was that some organisations have internal Values (and hence behaviours) that do not permit agile processes to develop and prosper but instead force them to mutate into grotesque, ineffectual parodies.

The reactions were interesting. On the one hand there were a handful of aggressive ad hominem challenges. "Who was I to question what a company calls 'agile software development'?" "Who was I to question the value of bug ridden software to the customer?" "If I couldn't work with the status quo of a company then I should be the one to get out rather than try to change it" (even if I had been paid to come in and coach/mentor!). And so on. I was genuinely shocked at the ferocity of some of these challenges, especially since they were targetted at a personal level and entirely missed the points being made. Perhaps I was being a little too provocative at first, but I obviously touched a raw nerve....

However, most of those involved recognised the issue many having experienced it first hand. But there seemed to be a general inability to address the fundamental problems. No-one seemed to feel suitably empowered to do anything. In some cases the deeper problem was justified by external pressures (delivery date being a common theme - "do whatever it takes to meet the date and functionality and to hell with the quality/risk"), others did not feel that they could make the changes needed alone (which is not surprising - people will not change unless they want to change). Only one or two said they would go back and try to change things.

So was the session useful? Judging by the feedback received by Gus and Simon, the answer is a resounding "yes". Did I find it useful from my position as a hired hand? Yes - I got an interesting insight into the current state of the agile nation from people who are in the trenches and trying to get things done using agile/lean thinking in what is sometimes an extremely (sic) hostile environment. Yes, agile is adapting for best fit. But the session confirmed my worst fears that in many cases it is being forced to adapt a step too far.

Planning Poker Cards Prototype Deck

2007-11-29T11:12:00.000Z

Finally.... I have finished a full suit of Thirsty Bear Software Planning Poker cards:

OK, it's still a prototype built from laminated pouches, inkjet printouts and a lot of patience, but they make a huge difference to the flow of a Planning Game. Even using a small subset (0, 1, 2, 3 and '?') has a significant impact by removing the "follow the leader" behaviour that conventional planning encourages.

Now to find a printer that can supply a small run as "real" playing cards.....

What's in a name?

2007-11-06T13:54:00.001Z

I think I might have stumbled upon a better name for what I was originally calling "faux agile".

"Cargo Cult Agile" seems to convey the sentiment far better by linking it to the cargo cult religions around the world. In short, it's when a team/organisation blindly adopts agile practices without really understanding them in order to get benefit from them.

I picked it up from an XP Day session description, but it has appeared elsewhere as well (drop me a line if you believe you invented the term, and I will attribute the source). I only wish I had thought of it.....

Continuous Improvement

2007-10-10T14:03:00.001+01:00

An interesting insight into continuous learning and improvement from Brian Marick:

"At the end of each iteration, each team member should be able to say why she is worth more money to her employer than she was at the beginning."

Can you put your hand on your heart and say that you are improving yourself every two weeks? It's certainly something to aspire to.

Agile teams should be like a bowl of thick custard...

2007-09-29T17:17:00.000+01:00

No, I haven't lost it. After seeing some interactions recently I think it's safe to say that a successful Agile Team can (and should) be "dilatant".

Be open to well thought out changes that obviously improve productivity, but push back against fast, ill thought out, knee-jerk responses, and also politically motivated decisions from outside the Team that compromise working values.

Take inspiration from your bowl of custard and get your just desserts.

TDD is an approach, not a task

2007-08-07T13:05:00.001+01:00

Tim Ottinger has written an interesting entry in his blog about test driven design.

His mantra? "TDD isn’t a task. It is not something you do. It is an approach. It is how you write your programs."

Couldn't have put it better myself!

Come and join our agile team...yeah, right

2007-07-30T21:05:00.001+01:00

I have recently been invited to join a(nother) "Agile Team" as a senior developer rather than coach. You might have already gathered that I am becoming increasingly sceptical about these claims having been caught out before.

I have no idea whether the latest offer is truly agile, or faux agile, but it got me thinking. What am I looking for in an Agile Team before I can join it while feeling safe enough to leave my coaching hat at home? Here are my initial thoughts:

fixed, short iterations with regular retrospectives
story based scope specification with a suitable Customer involved with the Team
regular replanning based on real, measurable progress
full integration of QA within the team
test coverage greater than 80%
regular (ie multiple times per day) automated integration testing

I'm sure there are more but these seem to be the essentials that are most often missing.

If you can't check these basic boxes then please have the courage and wisdom to recognise that something is wrong and get help!

Teaching pigs to sing....

2007-07-20T13:55:00.001+01:00

"Never try to teach a pig to sing. It wastes your time and annoys the pig" (Robert Heinlein, Time Enough for Love)

When trying to become agile, Team members quickly tend to fall into three main categories (the percentages are purely based on my empirical observations and should not be seen as set in stone or based on scientific study!).

10-20% will "get it". These are the guys and girls who will be able to use the techniques to learn from their mistakes, spread their wings and perform. They are the future of the new, agile Company.

60-80% don't "get it", but are willing to try, or at least toe the line. They need more guidance about how to work efficiently, and that things are OK. They need more reassurance that the Team does not need this, that and the other supporting items (eg the massive Big Up Front Design documents, or a full specification signed in triplicate). With careful nurturing some people in this bracket will "get agile" (and trust me, the lightbulb moment when they do is one of the most satisfying moments of any Coach's career...). However those that don't really understand the principles do follow the basic ground rules and are not actively damaging to the agile process or the Team as a whole. In fact gentle pushback and respectful challenge from people who don't fully understand is healthy and productive.

10-20% of the Team don't "get it", will never "get it", and in fact really, truly don't want to "get it". These people are the biggest danger to any agile transition since they are not always obvious but will actively undermine changes to the status quo. More obvious behaviours that I have witnessed have included aggressive, disrespectful and/or unecessary challenge, refusal to adopt new working practices agreed by their Team (including themselves!), continuing to use old heavyweight processes in addition to the lightweight replacements, refusal to engage with the Team as an equal member and so on.

Anyone falling into this final group can cause huge amounts of damage to any agile Team but this damage is multiplied in a fledgling agile environment since the result will be bad decision making in order to placate someone who has no interest in working smarter.

So what to do? A difficult decision needs to be made but ultimately the damaging disruption has to be neutralised as quickly as possible - usually the easiest remedy is to transfer them from the agile Team to one more suited to their skills and temperament.

Alternatively you can keep trying to educate...how are you at giving singing lessons?

"I wouldn't start from here"

2007-07-06T10:34:00.000+01:00

There’s an old joke that goes something like this:

“A driver is lost in the darkest depths of the countryside trying to find his way back to the hotel where he is staying. In desperation he pulls over to ask directions from one of the locals. “Excuse me”, he says, “Can you direct me to the Hotel please?”. The local looks at him for a moment, sucks his teeth and says “I wouldn’t start from ‘ere, Bor’”.

When switching to agile processes there is a temptation to not “start from here”, but to try and create a sort of alternative reality before you start where it will be easier to migrate to the new process. This misses the point.

To “be agile” you need to

Have the honesty to recognise where you are right now
Have the courage to admit where you are, warts’n’all
Now fix it one step at a time
Repeat...

Cruise Control health meter addendum

2007-06-12T13:46:00.000+01:00

A while back I pointed out that high performing teams tend to break their automated build. This might be misconstrued, so to clarify the point.

A successful, productive Team will inevitably discover unexpected issues that will break the build. However this does not make breaking the build acceptable so do make sure that this message is reinforced albeit gently and with good humour, for example with silly hats or similar.

Travelling Light

2007-06-07T13:41:00.001+01:00

I like to travel light. I hate carrying things, especially big, bulky laptops. But as part of my work I need to take notes, and also have access to a range of reference materials that can be used to help some Teams to understand what I am explaining - slideshows, summary documents etc can help get the agile message across. The problem is I often don't know that I need a specific document until I need it. I also have a (growing!) backlog of blog entries that need thinking about and finishing - it would be nice to be able to work on these when I can wherever I am but without the encumberance of a laptop.

In order to solve this 'write once access anywhere problem' I have been playing with the online storage service provided by Omnidrive to provide a central location for data I use regularly and "in progress" documents. The system integrates Zoho Writer with the storage so documents can be edited online anywhere - but also they can be posted to a blog. This looked promising except the version of Zoho integrated with Omnidrive won't post to Blogger.

Yet all is not lost! Zoho also host documents, so it should be able to store work in progress online to be picked up later and published from anywhere.

The proof as always is in the actual doing rather than the talking (we value working software over up to date documentation, remember). So hopefully this experimental entry will publish to the blog in one piece...!

Understanding Agile, Take 1

2007-04-18T13:20:00.000+01:00

To the optimist the glass is half full.
To the pessimist the glass is half-empty.
To the agilist the glass is twice as big as it needs to be....

Cruise Control health meter

2007-04-03T13:23:00.000+01:00

I use Cruise Control. It’s my automated build weapon of choice. Why? For no other reason that it was the first one that I got my hands on. I (mostly) understand it, trust it and know its quirks and foibles.

It also has a neat feature – it shows project metrics. These are shown as pie and scatter charts displaying successful and unsuccessful builds. Both of these provide useful indicators about the health of a given project.

Taking the scatter chart first. This is a calendar with day on the X axis, and time on the Y axis. A dot is placed on a calendar every time there is a build – red for fail, blue for success. From this you can get a feel for the following:

How many checkins are being done per day
How successful they are
How long a build stays broken
Whether the Team is staying unusually late or coming in at weekends

All of these are useful indicators as to how things are going in general. I look for regular checkins during standard working hours and fast recovery from breakage – and I encourage the Team to investigate if this pattern is broken. All fairly straightforward and uncontroversial in the agile world.

The pie chart does something similar – it shows the proportion of broken to successful builds in isolation. Not necessarily as useful as the calendar scatter, or is it?

I have noticed an interesting trend with the pie chart in Cruise Control. At the moment it is nothing more than a gut feel or rule of thumb based on the observation of several teams, and I certainly have no data to back this up….but successful, dynamic teams appear to break somewhere between 15% and 25% of builds.

Shock! Horror! Agile teams break the build!

Well, yes. Breaking stuff unexpectedly is how you learn and improve. It is also the motivation to fix structure and design. So the point I am making is: Yes, teams should expect to break the build once in a while and question if they are not. It would seem that somewhere around 20% is the sweet spot where the Team is behaving optimally. Much more than this and something is going seriously wrong. Less than this and there is either not enough refactoring pressure on the design or the design is almost perfect (I know which of these I would suspect initially).

"Learning is not compulsory" - The Dangers of Faux Agile

2007-04-03T11:54:00.000+01:00

I am noticing a worrying trend amongst companies wanting to take advantage of the perceived benefits of the Agile Revolution – specifically the faux-agile project. These are projects that have stamped themselves as “agile” but do not adhere to even the most fundamental good practice. When you scratch the surface they do not continually build and test, nor do they actively refactor bad design out. Unit tests are at best given lip service, and coverage is low. In most cases the only nod towards anything remotely agile is the lack of unnecessary – or indeed any – documentation.

When asked, the excuses for the shortcomings are many and varied – “We know the structure of the software is awful but we don’t have enough time to refactor it right now, but we will get around to it later when we have more time” (yeah, right…), “Our Company culture does not allow the Quality Department to be integrated into development teams”, “We don’t know how to implement the automated build”. The list of excuses given by faux-agile apologists to explain away their inability to address core agile principles is endless. And yet when the proverbial hits the fan and the project is not delivering, someone always has the audacity to claim that it was the agile process that failed! In reality the Team was using that time-honoured (but dishonourable) process called hacking and hiding it behind the Agile flag of convenience. I am sure I don’t need to expand on the potential damage that this can do the the Agile cause.

So why are these pseudo-agile projects becoming more common? First of all I am convinced that it is not deliberate dishonesty – all the members of faux-agile teams I have met and worked with are genuine, honest software developers. Some have even convinced themselves that they are following the Agile Manifesto.

So if it is not deliberate subterfuge, what drives these behaviours?

My opinion is that it derives from the interaction of several issues.

The cost of initial implementation of agile. Kicking off (or converting) a project to ‘agile’ requires some up-front investment. Setting up an automated build machine, defining an acceptance framework, educating the Team in agile process and so on.
Management cynicism. I believe that Management in general is still suspicious of agile methods because they transfer a significant amount of power from the manager to the development team. Add to this any significant cost of implementation (including development down-time), and a pinch of failed previous faux-agile projects and suddenly the tension rises – “Why should I, a traditional manager, risk losing a large amount of budget on an experiment like this? You can do it as long as I don’t see any downtime or schedule slip”.
Lack of understanding of the “Agile Way”. When a Team does not fully understand the holistic nature of an agile process, they will be tempted to cut corners and only implement specific parts, leaving the rest “until later”. This is especially true if they are under pressure to put it into place with no downtime or schedule slip. This is a direct consequence of skimping on Agile training – buying the Team a copy of Extreme Programming Explained does not usually magically make the Team agile…

And so the Team begins to stray towards the dreaded Whirlpool of Doom….not all the framework is in place so the Team works a bit harder to make the process work which means they don’t have time to fix the framework which means they have to work a bit harder which means they have even less time to fix the framework….

So how can we fix this? I would suggest:

Companies must begin to recognise that “agile” is not a silver bullet. It is an alternative way of developing software, and as such it does have a high risk of failure if not installed correctly. As such it will have a cost of implementation. This will involve proper training of the Team and Management and Customer. It will also involve the setting up of the infrastructure – automated build machine, acceptance test framework and so on. The exact cost depends entirely on how close to the agile ideal you are before you start – in other words how far away you are from your destination.
As with any major change, give the Team space to make initial mistakes. They will be better and stronger for it. Give the feedback process a chance to work. Enable the Team. Let the Team learn.
Don’t be afraid to get help! This is not simply a sales pitch for the Coaches and Mentors out there (myself included), it is an observation from the trenches. There are many guys (and girls!) out there who have “been there, done that, got it wrong, then got it right”. Some have decided to share their knowledge to help your Team avoid the mistakes they made initially. The right Coach will set up the Team and leave it in a state where it can be used to seed other teams later, ultimately making your Company self-sufficient in agile training. The short term cost outweighs by far the long term benefit of getting it right.

And what if your Company is not prepared to adapt and implement agile process in a responsible manner, instead insisting on perpetuating the faux-agile anti-pattern? The best advice I can give is to ponder a quote from Lord Deming – “Learning is not compulsory... neither is survival”.

What does an XP Coach/Mentor actually do?

2006-12-30T17:30:00.000Z

One of the things I do is XP coaching and mentoring. But a question that keeps cropping up (bizarrely, often after I have been hired!) is "What does an XP coach/mentor actually do?".

Interesting question. And is there a difference between a Coach and Mentor?

In my opinion there is a slight difference, but first the common ground.

What both do is to guide a given team through the learning process of implementing XP. It is the responsibility of the Coach/Mentor to gently guide the team around the pitfalls by encouraging the good agile behaviours - communication, testing, team self review etc. Equally, destructive behaviours - slipping into mini-waterfall process, not talking to (or not having!!) customers etc - are discouraged.

Often the best way of doing this will be from inside the team, demonstrating by example the power of the techniques. IMO this is the "Coach" part of the job description.

As the team begins to understand and becomes truly self-organising, the Coach must become less involved if the team are to stand by themselves. But they must still have the skills to keep themselves on-track. This is the "Mentor" stage - when the team is trying to stay agile after getting the idea. This stage involves acting as more of a sounding board for ideas; a sanity check that the decisions made as the development process adapts and evolves are correct and not reverting to traditional waterfall. I have found that this often involves acting as an über-team lead, advising the existing team leader and/or experienced engineers on how to handle specific situations but generally not solving the problems for them.

Change code? Be afraid. Be very afraid....

2006-11-19T17:10:00.000Z

In my role as a software developer I have come across many strange attitudes to coding, but none so strange as the fear of changing code.

A good example - I was working with a team trying to use XP techniques. I was hired as a XP developer to strengthen the team and get them over a busy patch - not as coach, but simply as someone who had developed Java code in an extreme agile environment. No problem there.

The product we were working on required new functionality added to it. Since the current software structure did not easily accommodate the new stuff I mentioned in the stand-up that I would be restructuring the internals to make it fit more elegantly. This kind of refactoring is normal practice in any agile team, and is necessary to evolve the design with emerging requirements, keeping it coherent and stopping it from descending into a meaningless Ball Of Mud antipattern. I thought nothing of it. But one of the senior engineers threw his hands up in horror at the thought. "You can't do that! You might break something!".

The thinking went something like this:

"Currently the code works. The area of code being touched took a long time to get right and there is a load of undocumented features we discovered along the way but we cannot remember exactly what these were. Therefore to change it is likely to break the end product. Also we don't have tests that check what the code should do so your changes might break the software without us even knowing it is broken. So any changes must not affect existing code. But we cannot test it so we can't tell if it does affect it...."

R-i-g-h-t.....so let's get this straight. The code "does something". We don't know what that something is (we don't have tests) but we suspect that this unknown something will change if anyone touches any existing code in a certain area. Therefore we cannot change the code, only add to it even though the new functionality should really require a structural change to maintain architectural integrity. But we can't even tell if the external changes have affected anything because we don't actually know what this thing does!

So the burning question is "How can anyone change any code anywhere if we (1) don't want any existing functionality to change and (2) we can have no certainty that a change has not affected existing functionality"

Now I should add at this stage that the guy in question is fundamentally a good, competent, normally coherent engineer (and is also a representation of several real-life engineers who I have come across in this situation!). Which raises the question why good, competent engineers can get themselves into this logical black hole and fear making changes in code.

There are several key issues here:

No tests. So we cannot reproduce what the product should do.
Lost information. The Team has not been sharing information effectively so nobody really understands why things are structured the way they are.
Undocumented features discovered in a third party library.
Unclear code. The code in question is satisfying several sets of responsibilities resulting in a monster 1500 line class.

The issues do highlight deeper issues with the way the specific team is working. They are indicative of several common behavioural antipatterns that often cause agile processes to fail. I intend to try and pin down specifics in later blog entries.

It's finally happened....

2006-10-16T12:38:00.000+01:00

Well, it's finally happened. After ages of deliberation, soul searching mixed in with good measures of apathy and procrastination I have started a Blog. So what finally gave me the boot up the proverbial backside to do this? Primarily an excellent blog entry from Steve Yegge explaining why everyone should start a Blog.

What will be in here? Good question. But I suspect it is going to be my thoughts, experiences and opinions in the field of software development, especially in agile processes. In addition it gives me somewhere to document all those irritating two-days-to-solve-a-simple-problem solutions for the amusement of others that knew the answer all along (and hopefully help at least one other person struggling to solve the same problem...).

So bear with me while I work out how this blog-thing will work in the Real World - always the hardest thing for an engineer.