Category Archives: Musings

Why The Manifesto For Half-Arsed Agile Software Development Is Actually Important But Not Enough

Posted on by
Reply
Reading time ~ < 1 minutes

“That is, while the items on the left sound nice
in theory, we’re an enterprise company, and there’s
no way we’re letting go of the items on the right.”

http://www.halfarsedagilemanifesto.org/

Not mine but this resonates strongly with my experiences. I’ve seen varying levels of agile interpretation including this during my career so far. (By contrast, the team closest to the original principles that I worked with hadn’t even given their working practices and culture a name.)

The sad fact is that it’s all too easy to fall into the checkbook agile, control & distrust trap in large organizations. What I like about this spoof is that it captures Ron Jeffries thinking from this article in a concrete and direct way that even the most disconnected exec should recognize what their teams are doing wrong.

It also uses a subtle but powerful tool that makes this worth paying attention to rather than just reading, chuckling and inwardly despairing.

In trying to understand what you should do it’s important to understand what you should not do. The original manifesto is vague. Many of the myths that cause execs to distrust agile when they first read the manifesto are made manifest due to its vagueness. Similarly, developers that see a get out of jail free card on having to do anything but cut code in the manifesto are able to do so.

The negative ad-libs at the end of each point in this cynical version provide a clear “bad” marker; a new, tangible triangulation point to avoid.

What we need are equivalent “good” triangulation points based on business reality for large-scale software development rather than a noble vision so that we can help our teams and managers do the right thing.

Writing Code is NOT a Value-Add Activity

Posted on by
Reply
Reading time ~ < 1 minutes

I’ve been working through David Anderson‘s last book; “Kanban“. Last Night towards the very end of the book I had a lightbulb moment.

When taking a lean approach to software development you need to focus on value-add activity. David’s acid-test for this is very smart – I paraphrase below…

“If it’s really a value-add activity, then you should be striving to do more of it”

Now, consider this. Are we writing code or delivering working valuable software that solves a customer or user business need?

Some of you may have worked in organizations that considered measuring programmer performance by lines of code produced. Like all great metrics, there are some fair reasons for measuring LOC but with the wrong motivation, it will drive the wrong behaviour. You’ll produce more lines of code but not more value.

So…

Writing code is not a value-add activity. Producing working software that our customers and users need is.

Remember the concept of 4GLs – the more coding activity you could automate, the more real output you can get.

This approach is still relevant. Great software development teams automate as much of the coding as possible so that teams with strong domain expertise can focus on only writing the advanced business logic and don’t have to worry about the scaffolding.

Agile 20xx – It Takes a Team

Posted on by
Reply
Reading time ~ 3 minutes

Inspired by this post I just read from Seth Godin. As an average joe, hob-nobbing with CEOs isn’t so likely for most of us but the interpersonal interaction certainly is worth making time for. However…

If you’re paying to learn and thinking of attending Agile 2011 (or any other really big conference) take a team!

For the last couple of years I’ve attended the big US Agile Alliance conferences. I love going although I miss my family; I really enjoy the social interaction, spending time with (on the surface) a bunch of smart, similar-minded people sharing a week of learning, collaboration and fun. There are of course undercurrents (see this old post from Jean Tabaka) but I still find attending these conferences a rewarding experience.

For anyone that’s not been, the Agile 20xx conferences are huge and seem to be getting bigger every year. The number of parallel tracks – all with great presenters means you really have to make a plan.

Each year I’ve attended, I’ve had the luxury of going out as part of a team. My advice to future attendees is the same – take a team and collaborate on what you want to see.

My goal each year is to walk away with at least 3 key pieces of new thinking that would add value to my teams. The travel and conference fee for just 3 ideas might be excessive but as I said, I also go to learn, collaborate and have fun.

If even 1 of the ideas I bring back is sticky enough to be introduced successfully to a group of nearly a thousand engineers worldwide then I think that’s worthwhile!

So which sessions do you attend?

Personally I tend to steer away from the “rock star” sessions. Most of what they’re presenting is covered in their current or forthcoming books (and I read a lot of those already) so I don’t get much from them. Other members of my team don’t read so much and so will go along to some of these. Get the team to strike a balance but make sure the motivation is to learn and share, not just to meet “famous people“.

The stuff out there from people without book deals is rarer so I make the most of those sessions but less-experienced or well-known presenters may mean a higher risk of a not-so-good session.  Also keep an eye out for the open space sessions and lightning talks. You’ll find a lot of up-and-coming talent and thinking out there but again, your mileage may vary.

I also tend to look for things that are relevant to my current context, and future direction, not just my current role. A big part of my interest is in viewing things from other people’s and roles perspectives – for example I’ve never formally had the job title of “tester” but “Agile Testing” is one of the best books I’ve read that really “gets” cross-role pairing and test strategies – relevant to developers and managers, not just testers!

Others may prefer to spend the entire week in “UX” or “Testing” tracks but generally I strongly discourage spending the entire week in a single track in your own domain – you just don’t learn enough of the other interesting gems. Maybe it’s just me but agile isn’t just about your own specialist area, it’s about the whole team and organization.

Having presented at Agile Cambridge last year; I and my team have submitted a couple of proposals for Agile 2011 as we’re hoping we can start to give something back. There’s a lot of presentations out there so our chances are slim however despite the number that don’t make it, there are hundreds of great ones that do.

When planning your sessions, take a team and go for a knowledge portfolio – balance risk & reward to get maximum return on your investment. You won’t regret it.

 

I’m Drowning in Confetti

Posted on by
Reply
Reading time ~ 3 minutes

What happens when card-walls, foam board and stickies get out of control?

The same thing that happens with poorly maintained software.

“…But we spent time on them we can’t possibly throw them away!”

Time for a litter patrol I think…

About 2 years ago I ran some Agile training up in Scotland. One of the early exercises was to get the team to brainstorm and develop a backlog for a new product. (later exercises covered release planning etc.)

On every table was a pile of coloured stickies, marker pens and biros.  I asked everyone to grab a pen and some stickies and collaboratively start developing a coarse list of features and end user needs. All but one person in the room grabbed a biro and sticky pad and started listing as many things as possible – on a single sticky!

There’s some lessons to learn from this abut giving good instructions but the big thing for me was realizing how our culture has changed so much at the site I’m usually based at.

In 3 years I’ve seen a team transform from nothing on the walls to everyone having their own personal whiteboards, pinboards, information radiators at every wall and corner, a myriad of story maps, coloured indicators, charts, tables, diagrams and the real killer – A0 size portable foamboards covered in stickes everywhere!

Sounds pretty good – all that information right?

Perhaps we’ve come too far.

I sat down in a meeting room today and looked at the board that had been “parked” in there sometime in the last 6 months and recognized my own handwriting.

It was from a difficult release retrospective I’d led for a large team. The board was covered in things to “try” and a few things to stop doing. The original retrospective didn’t end so well. I pushed for selecting a top 3 actions (from nearly a hundred ideas grouped into logical sets) and failed to reach a conclusion.

Looking at the board today, despite the pain at the time I reckon that team have actually achieved or tried nearly half the things on the board and most have stuck.

I’m going to take it back to the team shortly as it’s a great way to see just how far we’ve come.  Quite a neat find!

But…

This is one of nearly 100 foamboards in the building. (We have about 10-15 scrum teams). My team sees these particular boards multiple times per day during various unrelated sessions but we don’t do anything with them – they’re just parked.

Many of our boards are delinquent, things are starting to look a bit untidy. In some cases there are multiple boards that are the output of week-long workshops speculatively planning releases that we’re now in full swing on.

They were useful once but now they’re hiding in corners and we don’t know what truths they hold.

We have photos of them in the wiki but they’re not important enough to keep right in front of the team and maintained.  We still feel an attachment to them – all that energy and time spent getting those thoughts visible…

Time to clean house I think.

I can either be brutal or more selective. Much like clearing out the garage, sometimes having an impartial person to help clear up may be needed.

My Lesson: Just because you spent time on it doesn’t mean it needs to be kept. Remember the XP acronym; YAGNI?  “You Aren’t Gonna Need It”

It applies to all artifacts developed during a project, not just code.

If something has served its initial purpose or achieved most of its intended value, make a clear decision on what to do with it. Are we into diminishing returns? Should there be some explicit action to retire the artifact?

If you care that much about it, how about giving it a wake?

Whatever approach you take, don’t let your information radiators rot. All that out of date noise will cloud out the actual information.

Don’t Open More Barrels Than You Can Consume

Posted on by
Reply
Reading time ~ < 1 minutes

One of my colleagues is a Theory of Constraints guru so this stuff comes naturally to him but even so, his casual remark on a conference call not long after joining us stuck with the whole team. It’s now a poster next to my desk so that all my drive-by visitors can see his wisdom too.

“Starting more work doesn’t mean you’re going to get any more finished.”

My boss also repeatedly says:

“We need to see a few things 100% complete, not a pile of stuff 80% done”

I have my own pattern for this that I’ll be posting pretty soon – the title might be a bit of a giveaway.

A Decade of What?

Posted on by
Reply
Reading time ~ 3 minutes

Ten years since the Agile Manifesto and where are we?

Before I get flamed, much of this article is deliberately tongue-in-cheek but there’s a serious element to it.

Flashback: Chicago 2009.

After an amazing week at my first ever Agile conference I had the privilege to sit in the hotel lobby relaxing & talking shop with a few presenters & attendees.

Although I’ve not made time to catch up with him since; the ~day I spent at Agile 2009 with one of that group of attendees was career-defining. In just a day he taught (or perhaps reminded) me to open my eyes and see the world as it really is – not how it’s marketed to us. This post is inspired by that experience.

During one of many conversations he asked me if I’d read Mordant’s Need.

Being a fan of the Thomas Covenant series  I had secondhand copies of both books in my personal library but had never read them.

Some weeks later I finished the textbooks I’d been working through and switched my bedtime reading to fiction for a while. I picked up “The Mirror of Her Dreams”, blasted through it and moved onto the second book – “A Man Rides Through”.

At some point at about 4AM after yet another bout of insomnia and a reading marathon my mental lights went on.

The entire first book builds up a classic “long con” – a confidence trick drawn out over years – to the detriment of everything else. Incredible.

Now for some fun. Picture this…

SnowyOwl Surf Resort – 2001:  Post-Y2K, the .com bubble is ready to burst,  everyone with half a brain is in software and the consulting gigs are drying up…

Guys. Things aren’t looking so hot for us Cobol developers any more. We need a new cash-cow to milk…

Time passes,  brainstorming happens (with the only thing to hand – those little pads of hotel room stickies)

…well, what are we any good at?

duhhh – Writing software.

OK, that’s a good start but it’s no fun any more – what do we all hate about writing software?

… Maintenance…

…Documentation…

…Management…

…Long isolated hours…

I’ve got it! Let’s take everything we loved about writing software, throw the rest away, package it up and market it back to all the noobie developers as a revolutionary new way of thinking!

Hmm. I think we’re going to need some marketing to pull this one off…

…I have an idea, my buddies at 4N keep complaining nobody except hotels wants to buy stickies any more and they’re gonna be out of work soon. I reckon we can arrange some sort of reciprocal deal.

Sales & Marketing join the team…

So here’s the deal. Marketing to developers is only going to get us so far. We need a top-down approach as well.

…How about we add in project management 101 and package the whole shooting match up into a name that execs will think means better, cheaper and faster.

…Let’s call it “Nimble”.

It’ll be great! I see it now, a pyramid training scheme, conferences, book deals and… oh boy – consulting gigs to die for!

…You know what, this just might work but it’s too easy. We need to throw some stuff into the mix to make it that little bit unreachable for the majority of our marks – keep ’em coming back for more.

While we’re at it, let’s roll in a whole new subset of jargon for extra obfuscation and overlay with some real punchy one-page marketing.

Some years pass…

MickeyWorld 2010 – “Nimble Conference” keynote speech:

…In fact, if Nimble’s not working for you, that’s because You’re doing it wrong.  Donate a million bucks to one of our Gurus and you too will have perfect development projects, products everyone wants and fault-free software.

Here’s the real data from one really successful project to prove how great it is.

Present day – all over the world:  Everyone’s all-in. Despite the vision of a digital paperless office, our stationary budgets have tripled – but don’t the walls look pretty!?

OK, back to reality.

I wouldn’t have things any other way right now. How else would we counteract the incredible momentum of Taylorism and the erosion of good old common sense. Writing software in the 21st century is all about the business, coding is just a fragment of the job.  Gone are the days of a neat idea and a pile of VC funding, so too is the ability to write cool games single-handed at weekends (most of the time).  Here’s how we can make software development fun again. Better still, now we have the tools and support to demonstrate that software teams deliver real business value.

Look beyond the methodology marketing, the processes, the practices, the tools and get back to the root of why we’re doing this. Software is generally a means to an end. Agile, Lean, Scrum, Voodoo, whatever; our goal is to deliver business value to the best of our abilities.

I’ve committed my career to this. I’m having a fantastic time. Much of what I’m seeing in the agile & lean community is great but for large-scale enterprise software product development and large corporations it still is very hard work to make this stuff stick.

I don’t plan on giving up any time soon.

Ahoy!

Posted on by
Reply
Reading time ~ < 1 minutes

Ahoy Me Hearties!

Having mortgaged my soul to Davey Jones’ BBC Model B long before the dot com Boom & Bust, the Millenium Bug, the introduction of the Euro and the demise of Altavista; 2011 is the 15th year of my commercial softwarefaring exploits and roughly the 25th year since my voyaging began in Basic with Usborne books, the “Welcome Tape” and early forays into the online ocean via Prestel.

Herewith begins my testimony of daring exploits, shores travelled, cultures & rituals observed and occasional ramblings associated with bad bread.

Before I commence it is important to clarify that these musings represent a manifestation of my inner monologue and must not be associated with those of any of my current or past employers.

With this short introduction, I bid you good day.

C