Back to the Technical Stuff (or “Why so Quiet Cap’n?”)

Reading time ~ 5 minutes

5 months since my last post. What’s been happening?

Lots!

A recent entertaining high point was this photo of Alberto Brandolini‘s (@ziobrando on twitter) lightning talk at XP2014 going viral. Alberto Brandolini at XP2014 (Rome) It’s still doing the rounds on twitter 2 weeks later so if you’re here because of “that photo”, thanks for stopping by and don’t forget to congratulate Alberto! Sadly most of the content on here – whilst hopefully interesting and insightful – probably won’t have the same mass-appeal. Back in the day-job, I have 3 irons in the fire at the moment.

  • Build & cycle time
  • Agile staff development
  • Rebuilding my “developer empathy”

Build & Cycle Time

I’m working with two of the function heads at Red Gate on a project to improve our build and test cycle times. Chris and Jeff are doing all the hard work directly with the teams, I’m just offering support, guidance and occasional prods.

In the last 6 weeks they’ve managed to reduce the amount of processing on our build servers for one of our major products from 56 total hours (requiring a total test run duration of nearly 15 hours) to 10 hours processing, ~30 minutes total run time and a build time reduction from 40 minutes down to 6.

At the same time they managed to get all the tests back to green and fix the hidden bugs they were masking (just 3 luckily). Somewhat embarrassingly, this was a first in over 5 years). This has had an amazing positive effect on team morale and Chris’ visualization of status has really upped the game for all teams in the division. Chris' LED buld lights The team’s best run so far without a broken build or failing tests was a week but this time when things failed, they were fixed and re-tested in under an hour, not left for the next “overnight”.

That’s a major shift in behavior for us and means we can now be much more responsive in turning around customer issues too. The knock-on impact of this on all other projects is probably even greater.

Other teams are benefitting from a build queue that actually has free slots during the day (previously unheard of) and overnight runs that are significantly quicker due to the reduced load on infrastructure.

This is all part of a major push by our team to crank up the effort on our technical issues here. We’ve got agile project processes running to a level where we’re happy and continuous improvement is culturally part of every PMs daily life but we’d not focused on the technical side, XP practices and development culture so much. Until recently our teams had done “pretty well” with brute force and intellect but many hadn’t seen what “really good” looks like for a while. We’re fixing that 🙂

Agile Staff Development

This is where most of my time’s been going. I’ve been working closely with Brian, our head of Tech Comms to roll out training on our new “personal development planning” workshop and tools to all our line managers in development. This is the culmination of the work I wrote about back in September last year following a successful pilot.

We’ve overhauled the skills part of this area as a team with some great design assistance from our head of UX (Marine) resulting in a skills map for each of our main development roles.

Project Manager Skills Map

We’ve developed a half-day training course where participants explore the materials and gain a deep understanding of the concepts, goals and challenges and then actually do the personal development workshop itself as deliberate practice – with one participant leading and one participating – before unleashing their new skills back with their teams. We’re documenting much of our work at http://dev.red-gate.com/skills/  and have made our internal skills maps available under an open source license for others to adapt the concepts for their own use.

We’re now at the point where all development line managers have been trained, about half of our development staff have development plans (and are actively tracking and maintaining them) and we’re now looking at how to both make this scalable, sustainable and expand the next phase of the project to cover non-development roles.

There’s been a real buzz about the skills maps in particular outside Red Gate so we’re hoping to take these concepts out to a couple of conferences toward the end of the year.

 Rebuilding my “Developer Empathy”

Related to our technical push around the build and cycle times, I found that after too many years away from the technical coalface I was becoming somewhat jaded towards what I perceived as a lack of technical discipline from some of our developers. I needed a mental reset. Starting out with the premise that we hire great, motivated people who care, I needed to understand what it was that would make someone with the best of intentions fail to write and maintain unit tests, develop poor quality architecture and allow a codebase to fall into disrepair.

You see when you look at it like that, something else must be amiss.

Rather than simply looking, I’ve decided to do it myself. So in the last few months, in early mornings, lunchtimes and evenings I’ve taken up (simple) coding again. I’ve taken a domain I know well (text adventures) a project I knew I’d enjoy (writing a new game) and started deliberately building up a legacy codebase. Whilst trying to use at least some basic object concepts (in JavaScript), I’ve not used SOLID principles or composition (In my former Java life I generally avoided inheritance in favor of interfaces/composition), I haven’t written tests first and I’ve written some quite complex methods without tests.

3 months later I have a rather neat game and engine, a nasty codebase. 150 tests (all passing) where I should realistically have more than 1500 and amongst the full set of classes, a small number of 1500+ line “god classes”. I found myself repeatedly “play testing” new features rather then writing tests, blurring the boundaries of responsibility across objects and occasionally rushing work so that I could “get home” or switch back to my day-job.

I’ll write about this in much more detail in future (and will try to find somewhere to host the game) but in summary, I’ve reconnected my empathy circuit. There are many reasons why we don’t work at our best on legacy codebases. I don’t always know how we get there in the first place but I can see why we fail to dig ourselves out.

In short, there’s just “too much to do”. And so… Back to the big rocks and the oubliette.

What Are My Needs as a Hiring Manager?

Reading time ~ 5 minutes

Inspired by a twitter conversation with Bob Marshall, Marc Johnson and Nicole Rauch.

What really are my needs when I’m looking to hire someone onto my team or organization?

This article is a great start on interviewing and the goals of doing so. (whether or not you agree or disagree with the content)

In particular, understanding :

  • Can they do the job?
  • Will they be motivated?
  • Would they get along with the team?

I have to admit that’s a good summary of my needs – I’d add “Will they fit with the way we do things as a company?” as well.

What about the needs of the person applying?

Well there’s the whole safety, security Maslow’s hierarchy of needs type stuff for starters. There’s also Dan Pink’s work on Drive
“. Mastery, Autonomy,  Purpose. Jurgen Appelo is doing some amazing stuff around this at the moment too but…

At the end of the day, this is a 2 way relationship. If neither of us will find our needs fulfilled, it’s just not going to work.

Incidentally we’ve found from talking to all of our teams recently that trust, respect, peer recognition, support and self-fulfillment are pretty key.

Chapter 1 of “Love ‘Em or Lose ‘Em” has some great research on what makes people want to stay in a company that’s worth a read.

Before we even get to this point there’s a bunch of work to do though.

At the moment I see hiring as a funnel type of workflow with iterative filtering:

  • Attract Candidates (Advertising, headhunting etc.)
  • Perform an initial filter (CV sifting) to develop a shortlist to invest in further
  • Filter again (Telephone Screen) to get beyond the introduction and get a “feel” for capability, personality and salary/role expectations (both ways)
  • Filter again (1st interview) to check capability
  • Filter a final time (2nd interview) to check motivation & team fit (both ways)
  • Make a decision – offer or reject
  • Nurture to start date
  • On-board with team & company
  • Review progress/probation – is the relationship working out (both ways)

Note, this is just one example – I generally see the hiring process continuing through to being a successful, happy team member with a happy team.

I’m writing this post quite hastily but if we look at that flow, there’s a value stream in terms of effort and cycle time per candidate and also a funnel at which points candidates “drop out”. There’s a lot of effort, a lot of waiting and a lot of waste. I truly think there could be something better but I’ve not tackled the problem yet (and perhaps that’s part of my problem!)

Here’s the first challenge I face…

As a hiring manager, my time is at a premium. I’m usually trying to do at least one other job at the same time as hiring (usually running  a project and team) and often working on other “hidden projects” such as improving the way parts of the organization work (including adjusting and learning from feedback on the hiring process itself and the types of candidates we’re getting through).

On top of that, it’s really hard to attract the “right” people – back to skills, motivation, team & company fit.

Our first port of call in most cases is a covering letter and CV. Sometimes we start with an introduction or conversation but eventually we usually go back to a CV.

We’ve hired most of the people we already know are good that want to work here (location and company-wise), that we can honestly afford and are available. (Being based within an hour’s easy commute of London means competition for good people is tough). So most remaining applications come from strangers.

If someone’s a stranger, how are they able to catch our attention (in a positive way) to make it clear to us they’re worth engaging with, spending our limited time getting to know and developing a positive relationship with? Particularly when there may be dozens (or in my last company, hundreds) of others competing for that same attention. This works both ways – how do I get your attention too?

For my current job, I developed an early relationship through reputation first but at the point we decided to formalize things, I was still happy to present my CV. I’m proud of what I’ve achieved and earlier conversations could have missed things that were relevant and valuable. In my case this was particularly true. I worked on CRM and order management systems early in my career and the conversations I’d been having so far weren’t around this area but it turned out this experience was really valuable to them. We wouldn’t have made that connection without my CV.

If someone approached us without a CV as a total stranger we’d have no idea what to expect it’s a gamble as to whether we’re dealing with someone we really want to know or not and realistically the little time I have for hiring isn’t an area I choose to gamble blind. That initial “Yes/Maybe/No” that I can get from reading a CV is a lot quicker that talking to every single person that applies to figure out what they can offer that’s relevant or valuable.

Similarly, job specs are like CVs – would you apply for a job with no spec? How do you know what’s expected of you and whether you’re a good match?

So, my needs – assuming you’re a stranger…

  • (Without being a stalker) Seek me out, get in touch, say hi, invite me to stuff, find a way to get to know me and start building an interesting professional relationship.

OR

  • Make it easy for me to get you through that first sift of candidates with useful, relevant stuff.
  • Make it clear what your motivations and skills are, how you work and what sort of person you are.  I don’t hire assholes and I’m pretty wary of “Alphas“.
  • Link up what’s on your CV to what I’ve said I’m looking for but please do share the other cool stuff you’ve done – you might have useful experience I’ve not even considered.
  • If you’ve done cool things that are publicly visible and don’t need me to do a mountain of digging, point me at them. If the rest of the CV is interesting, I’ll go and look.
  • I won’t have time to read your twitter stream, blog, Stack Overflow activity, Github check-ins and Linkedin profile unless I’m already interested in you. (I don’t do Facebook) But if you’re interesting, I assure you I’ll look for you on all of these.
  • Don’t over-inflate or lie. It might get you through the CV screen but when I find out you can’t back it up later you’ll just piss me off.
  • Show me real evidence of what you’ve achieved and how. I can’t stand all theory and no results. But if you have a love of the theory, show me how you’ve applied it and made a difference by putting it into action!

I’m sure there’s more but this is plenty for now.

What are your needs when you look for a new job and how do I get your attention?

 

 

 

Back to the Oubliette – How We’re Digging Our Way Out

Reading time ~ 4 minutes

Back in December I moved to a new team. After 18 months on DevOps and email marketing projects I’m back to managing commercial product development. After a week of getting up to speed on the product and project (it was already in flight when I joined) I started looking at the bug backlog in Jira.

One problem with bug backlog tools is that they allow you to create bug backlogs. I considered shutting them all down but knew we’d find value in being more considered in our approach.

For this project I was pairing with another project manager; Dom Smith (yes, pairing isn’t just for developers). The project was a major new release for one of our longstanding successful tools.

This is the second time I’ve pair-led a project and every time the overall outcome and workload is so much better. One day the rest of the industry will realised that having a single PM running multiple projects will always get a suboptimal outcome. In fact another critical project (fixed time, fixed quality, fixed schedule, fixed scope!) elsewhere in the building is also being pair-led right now and is proving to be a great success.

Dom was a technical author in a previous life and is therefore rather good at keeping track of everything a team does over the life of a project. Another team were interested in what we’d done so fortunately Dom managed to capture everything we did to get the oubliette under control. Today’s post is brought to you courtesy of his work.

At the start of our review we had ~1200 open issues, of which about 400 targeted for the “next version”. The backlog had reached a state where nobody wanted to look at it as it was “too big” to resolve.

Fortunately strategies for breaking down big problems is something I tend to specialise in.

If I’d said at the start we were going to spend 4 months doing this, I think we’d have struggled. Looking back, we spent about 50-60 hours of our time and about 100 hours from the development team to get things under control.

We started with just one hour’s “space” and simply said. “OK, what can we achieve in 10 minutes”.  Fortunately bug backlogs have many “seams” to work through. We worked through the smallest easiest first and whenever things slowed down or value started to diminish, we’d move to a fresh seam and started digging again.

We started by setting up an hourly slot once a week to pair up and pull the things we were going to fix into the current version. In the process of this, we found many duplicates we could close. We also ensured that rough priorities (priorities would be clarified later) were set on everything we pulled through, and that they all had components (the functional or technical product area) set.

After a few weeks repeating step one, we started tackling the other end of the list: things that were out-of-date or really not going to get done.

Anything more than 3 years old was checked on a case-by-case basis with the starting assumption that it would be closed as ‘won’t fix’ unless we could argue a reason not to (primarily based on prevalence and customer impact). Pairing made these a sensible conversation rather than a  hasty decision.

“Autobugs” – we have an automated bug reporting system so that when users hit an exception they can choose to report it directly into Jira with no additional effort.

Any autobug raised prior to the last major shipped release that was not seen in the latest live release. We were working on v8.0 so any bugs reported against v6.x with no reports in v7.x, were closed

Any autobug raised only by one our development team on an unreleased build over 6 months old were closed.

After cleaning up the “noise”, we added a weekly, 45-minute meeting with the whole development team to review all the new issues added in the last 7 days, set a clear and appropriate priority, ensured component information was present, and set an explicit release target. (Either “current” (v8.0), “Next Minor” or “Next Major”. This helped contain the quality of new bugs – we “stopped the bleeding“.

We adapted our weekly pairing slot, to tackle the issues assigned to people no longer on the team (the aim being to ensure that they ended up with no issues assigned to them). Many of these could be closed as No Longer Valid, but there were a few which should have been prioritized that they were being sat on.

Again during the weekly pairing, we started working on closing bugs targeted at “improbably releases”. We had placeholder releases called ‘Future – Possible’ and ‘Future – Unlikely’ which, by their very nature, aren’t likely to happen. Again, we ruthlessly reviewed each in turn. Many had already have been fixed, and just needed 5 minutes testing to verifying they were resolved.

We added a further hourly weekly session with our product manager prioritize any issues we’d found through this process that looked more important but needed a product management decision. Having set the impacted component on everything we weren’t closing we’d found clusters of problem-areas that had been previously hidden, that became candidate focus for our next minor release (due to ship imminently).  We also checked any queries coming from the development team’s review of issues from the last 7 days, and the scope of work for the current release to determine ‘Must Fix’ vs ‘High’ vs ‘Would like to fix’.

In parallel to these activities, we worked with our Sales team to ensure CRM references were added to any feature requests in JIRA (both new requests and existing ones that were being asked for repeatedly). This helps our UX specialists and product managers with prioritizing these in the future and gives them direct customer links to follow up on actual needs and problems.

In the space of 4 months we closed over 50% of the backlog issues by not doing any development work –  just investing in three weekly meetings. We fixed another 25% by setting clear priorities, targets and sensible grouping of issues.

We aren’t there yet though. Bugs are still coming in and there’s still two big ugly piles in “Next Minor” and “Next Major” that we have yet to tackle but we’ll continue to put a little effort in on a regular basis to keep improving our position. Better still, the last release we shipped has significantly less bugs and the one we’re about to ship has less again.

We’re digging our way out!

 

Kipling and Keogh on Requirements

Reading time ~ < 1 minutes

A short thought today…

From age 11 to 16, written on the wall of my school sports hall was the following quote.

I keep six honest serving-men (They taught me all I knew);
Their names are What and Why and When
And How and Where and Who.

It wasn’t credited, nobody spoke about it or referenced it. I never really thought about its source, I wasn’t a reader of much classic literature or poetry (preferring fantasy and comics) and I didn’t really consider its value but it stuck with me.

Some years later I looked it up.

Here’s the full version

I keep six honest serving-men (They taught me all I knew); Their names are What and Why and When And How and Where and Who.

I send them over land and sea, I send them east and west; But after they have worked for me, I give them all a rest.
I let them rest from nine till five, For I am busy then, As well as breakfast, lunch, and tea, For they are hungry men.

But different folk have different views; I know a person small- She keeps ten million serving-men, Who get no rest at all!
She sends’em abroad on her own affairs, From the second she opens her eyes-

One million Hows, two million Wheres, And seven million Whys!

 

The next time you’re looking at requirements, use cases, user stories or similar, consider…

Who is wanting to achieve what and why?

Where would they normally do this, when is the right time and how would they do so?

Take this a step further. Ask “why?” just once more.

And if you’re still writing user stories as “In order to … I want… so that…”, then take a read of Liz Keogh’s recent post.

So what’s with this Pirate thing anyway?

Reading time ~ 6 minutes

Over the last year or so I’ve been asked about this story quite a few times so fitting with my model of reuse and generalization and having re-told it about 3 times in relatively quick succession over the Summer, I felt it was time to document it properly.

The Dishevelled Teenager

I’ve never really been one to visually conform. Even at the age of 17 I remember a very polite but direct “talking to” from one of the staff at my school about the health risks of dreadlocks with regard to other students.

Admittedly the dreadlocks are long-gone now but the boots, long hair, beard, beads, rings and large hoop earrings have been with me for nearly 20 years with very little change other than the odd complete head-shave (mostly when working in industrial or hotel kitchens).

In “smart mode” or in customer-facing environments, the earrings sometimes come out, the hair is tidied, the large boots are replaced with something smarter and the woolen jumpers are replaced with a jacket (usually velvet) and shirt but even then there’s something of the pirate persona that lives on.

The Disney Connection

Strangely, Disney seem to have a lot to answer for. In my first couple of years at Oracle in the ’90’s  the “behind-my-back” description of me was “The Lion King”.

In May 2003 I moved to a Tech Lead role in Cambridge working with an exceptional development team. (They were following an incredible level of discipline mostly around XP technical practices in feature-teams). At about the same time, the hype engine was in full-flow for the first “Pirates of the Caribbean” film. And within my first month, the team had seen me in full-flow at the Cambridge Beer Festival.

This rather bizarre collision of events triggered the most early “Pirate” and “Captain” references that I remember. Over the next 3 years, the “Captain” moniker stayed as did the good-natured pirate jibes.

When I left this team we’d just relocated to a new office with a lake outside. My leaving present from them all was a radio-controlled pirate galleon with twin propellers and “real action cannons”. We took it out on the lake before I left and terrorized the aquatic populace. Sadly without a lake of my own, I don’t get to play with it very often any more.

“I Didn’t Think You Were Real!”

I moved on to a senior management role at a large well-known American conglomerate and switched to smarter clothes for a while. Not long after joining, I enjoyed another example of my continued non-standard appearance.  I had the pleasure of meeting a delegation of leaders from the US at our Cambridge office. As introductions were made around the boardroom it reached my turn. I introduced myself politely and was greeted with a burst of laughter from our worldwide head of HR.

 “I’m Sorry” she said “I didn’t think you were real!”…

…”We use your picture for diversity training”

She proceeded to explain that they had a presentation describing senior management diversity and the need to “break the mold” of the traditional polo-shirt, chinos, deck shoes, short back & sides style senior managers.

Apparently there was a photo of a “traditional” senior manager at this company alongside one of me. Saying “less of these” (pointing to the traditional view) and “more of these” pointing to me.

Unfortunately for them, I’m not clone-able yet.

Ninjas & Pirates

Over the first couple of years I was there, only one member of staff ever made any pirate references in front of me. The Six Sigma “Black Belt” for our site would regularly greet me in the mornings with an “Arrr!”

Only when we were some way into our agile journey with this group did the “Agile Pirate” name finally surface.

“Going Agile”

One of my roles as an Engineering Manager was to define, improve and maintain our processes.  As part of “owning” the processes for the site I led two of our early  attempts at “agile adoption” with varying success (We were ISO certified so fitting agile into ISO was one early challenge. We succeeded and passed our certification).

Some time later we decided to “go agile” again (our third attempt). This time we had the real backing of our US leaders…

A (rather long) aside: Making a refit happen in a corporate environment

One of my close colleagues took things into his own hands. He signed trial agreements for electronic whiteboards without formal approval and literally took a screwdriver to the walls of his team’s bay, taking them down and leaving them in a pile (complete with insulation) at the end of the office. He called our site leader down to the “refurbished” areas to show him how much brighter and collaborative it was. The response was

“That looks great…

…don’t do it again”

His direct action combined with an informal photo taken by him demonstrating the trial of our smart boards (a VC rig showing a call running between our UK and India development groups where the remote team stood life-sized in an image on one board, the backlog on a second and a sketchpad on a third) found its way across the Atlantic.

His work became “the vision of the collaboration space of the future”, was widely circulated amongst senior executives and became the catalyst for funding a series of million dollar refits to our sites and the commissioning of an entire “state of the art” new software development site in our HQ city.

Back in Cambridge the refit involved replacing servers, infrastructure,  furniture, providing dedicated “war rooms” (many people hated that name) for each product group,  electronic whiteboards, video conferencing rigs, whiteboards and lots of wall space.

As part of the refit I pushed for “pair programming desks” – these were very large desks, big enough for 2 team members to comfortably pair at all day (each team member still had one of these to themselves so it wasn’t forced).

At this point I need to describe the shape and layout of our office, this will give some context…

It’s an old hospital building in Cambridge (not very old  but architecturally dated). The offices are arranged over 4 floors with 2 long narrow wings (East and West) per floor.  Each of the wings had a series of north and south facing rectangular windows at regular intervals.

The top floor was generally open plan, the next floor down was a rented by a couple of other companies.

The first (second if you’re in the US) floor was particularly “special” – each wing contained a series of “bays” – like old 4-6 bed hospital ward bays plus a selection of meeting rooms, test labs and server rooms it was like a rabbit warren.

The bottom floor was mostly “executive” offices and meeting rooms.

Our budget generally covered the team/meeting rooms and a refurbishment of the top and “special” floors.

Back to the Main Story

An early floor plan of the proposed refit from our architects was accidentally left on the printer one day.

It followed the traditional “architects do dull office design” approach of regimented layout and maximising staff density. Desks were lined in pairs either side of a central corridor in evenly spaced rows. (Joel Spolsky wrote something on a similar experience a while ago but I can’t find it any more)

Unfortunately the placement of desks and windows combined with the shape of the building allowed a particularly creative (subversive) member of the development team to set-to work.

A highly modified copy of the plan was found pinned to the top floor kitchen noticeboard depicting the office as a large galleon with slaves chained to the desks, oars coming out of the windows, assorted better-known office characters caricatured in various roles and a classic “no rudder” joke thrown in for good measure.

Depicted stood at the helm was a “Crazy Agile Pirate” waving a cutlass.

Thus the “Agile Pirate” name was born.

Over the years after the refit, with the joke having been aired and the teams discovering that this wasn’t something new to me, things became more direct and open.

After all, if you have some aspect of yourself that might be used for ridicule, why not simply milk it?

Sadly I don’t have a copy of the original cartoon – I’ve asked and it appears to have been lost to time. I do however have a fabulous treasure map hand-edited by the same cartoonist that was part of my collection of leaving gifts when I moved on from that team.(other gifts included a cardboard play pirate ship, an inflatable parrot and a copy of “Management 3.0“)

Blogging

I’d been blogging internally for my employer for some years, leading the internal team of agile coaches and had developed our worldwide internal agile community to a group of over 1,000 staff across all roles – from delivery team member to CIO.  I felt however that I wanted to share what I was learning and seeing with a wider audience. In order to keep things safe for everyone involved in my experiences I preferred the added safety net of anonymity. (It was generally known and accepted that I was writing these articles but that they were (and still are) my own views and opinions and not affiliated to my then employer).

Since then I’ve moved on and been “outed” a number of times however there’s still a small part of me that enjoys the potential anonymity of this site and that one day, I may choose to quietly hand the anonymous captaincy to others much like the Dread Pirate Roberts.

Thanks for reading.

C

 

 

Seeking “Customer” Input

Reading time ~ 3 minutes
Overgrown statues
The hidden beauty of exploration

Those of you that have been following my posts in the past will have noticed my output has significantly reduced in the last few months. I still have plenty of articles to write but I’ve chosen to spend much more of my spare time outdoors exploring “old places” and enjoying rocks, trees and water and those things that are half-forgotten.

However…

I still want to keep writing and feedback I’ve had is that it’s been worthwhile for you readers so far – so how do I get more focused?

You’ve (hopefully) seen the fairly broad spectrum of things I write about already. Rather than my continuing with random musings as they surface (or mature naturally from my backlog of posts) I’d like your input.

Taking a cue from an article I read a few months ago (I really wish I could remember the site and author) I thought I’d share the headings from my backlog publicly.

If any of the draft titles below spark your interest, please comment and let me know and I’ll prioritise them in my backlog and work on expanding them into full posts.

Similarly, if they inspire something else that you think I could share, just shout.

All the best from the shores of Porta Rossa

Captain

The Captain’s (Back)log

  • Analysis Vs Delivery
  • Why You Should Stick to Using Whiteboards & Stickies
  • Estimates Are Not Commitments
  • Sub-optimizing Around Data
  • User Story Myopia
  • On Average Everything Is Average
  • The Story Point And The Damage Done
  • The Cuckoo’s Egg
  • The Automobile Association (On Setting Customer Expectations)
  • What’s Wrong With Your Picture?
  • The Problem With Big Problems
  • Give Me Something To Critique
  • Using The Pirates Code With Agile
  • Trust or Blame
  • The Management “Middle Tier”
  • Managing The Sushi Bar
  • Using Real Options With Your Suppliers
  • Scale, Supply And Demand
  • It Really Does Depend on Context
  • Stop Trying To Fix Your Weaknesses
  • Dietary Manipulation (Part 6) – Eat Together
  • Dietary Manipulation (Part 5) – Have a Beer
  • Dietary Manipulation (Part 4) – “Do Food”
  • Scrum/Kanban Board Refactoring
  • The Pitfalls of Measuring “Agility”
  • Single Piece Flow and Trading Out Stories
  • My Job is to Make Myself Redundant
  • Escaping The Oubliette (Part 6) – The SWAT Team
  • Escaping The Oubliette (Part 5) – Sponsorship
  • Do No Harm
  • Commitment & Planning Horizons
  • Project Envisioning with Six Stickies
  • Don’t Wait For a Retrospective To Improve
  • Technical Debt – Eating My Own Dog Food
  • Technical Debt (basics)
  • Critical Chain Estimation
  • Thinking Too Big
  • Creativity
  • Pairing, Peer Review and ISO
  • 1,000% Improvement Is a Statistical Outlier
  • Stop The Line
  • Zero Defects
  • What Documents Do Your Projects Produce?
  • Burn Down Chart Patterns
  • Business Cases & Portfolio Management
  • Legacy Code Vs Legacy Product
  • Limited WIP
  • Trust
  • Meeting Commitments or Delivering Value
  • How To Get Buy-in to Agile
  • Product Owner?
  • Inertia
  • Marketing and Follow-Through
  • Telling Vs Coaching
  • Ubiquitous Language Does Not Mean Japanese Jargon
  • Defusing The Politics
  • Why Agile is Harder than Waterfall
  • Don’t Ignore Your Environment
  • The Elephant in the Room
  • Broken Windows
  • 5 Whys
  • 6 Thinking Hats
  • Debunk Sessions
  • Risk & Reward
  • 3 Points are Better than 1
  • Desire Lines
  • The Power of Team Casting
  • Using Stage Gates to Your Advantage

*edit* – my first vote is in already from @fatherjack (thanks!) “Telling Vs Coaching” coming up next.

Another edit: Oct 2012 – thanks everyone for continuing to comment and vote. The top 3 items from the backlog by voting/popularity have now been delivered. I’m likely to write a couple of new ideas up whilst they’re fresh and then get back to the requests again!

Portrait Vs Landscape

Reading time ~ < 1 minutes

I’ve been very busy for the last few months in my new job but will be presenting at a couple of conferences in the Summer. In the meantime, here’s a short thought to share…

When writing, people think in paper shape.

So why is it all our whiteboards are mounted in landscape?

Hang them up them portrait-style and panel them along a wall.

Just try it – portrait mounted whiteboards make a much better tool.

In my time working for a large multinational I led much of the design and layout work for redeveloping the office space at one of our sites to support agile teams. As part of this I reviewed and improved our available wall and whiteboard space.

As an experiment in one of the boardroom style rooms I arrange to have 3 large whiteboards mounted portrait style as 3 connected panels.  They proved significantly more effective than normal boards and became some of the most heavily-used whiteboards in the building. As a result I replicated the same setup across as many other rooms as would accommodate them.

I can’t tell you why others liked them but from my own experience I found working in multiple portrait-format significantly easier than landscape. It allowed focus areas and footnotes in a way that a pair of normal whiteboards in the same space didn’t. This helped me arrange thoughts more cohesively with a natural information flow that landscape boards didn’t offer. They also worked as natural extra-large swim lanes during workshops and allowed multiple team members to work side-by-side on related aspects of a workshop.

It’s hard to remember all the benefits on a Friday afternoon. They just “felt” nicer, different, better.

Give this a try and share your experiences here.

 

Story Points are Only for the Team

Reading time ~ 2 minutes

One manager says to the other…

My team’s doing an amazing job, in 9 months we’ve increased our velocity from 28 points per sprint to 65 by changing our development practices and adopting XP.

Now we do TDD, pair programming and relentless refactoring. Better still, we have story kick-offs and the team swarms around a single story until it’s complete. We all do the scrum-ban can-can to get ready-ready for done-done…

That’s nothing says the other manager, we’ve just increased our velocity by 1000% in one sprint with only one change to our practices!

 

 

We added 3 extra zeroes to every story point estimate.

Believe it or not, this really does happen in some organizations although usually much less extreme and obvious. Story point inflation becomes more common when velocities are compared either across teams or reported through management.

Q: What’s the best way of increasing a team’s velocity?

A: Use it as an external performance measurement.

The same issue holds true for the total number of stories completed.

Q: How do you make your teams complete more stories?

A: Make stories smaller.

It’s a a well-known fallacy that using story points for anything other than a team’s own diagnostic for tracking their progress towards a goal is risky.

Also bear in mind that if you’re using velocity and story points the way many of us have been taught then you’ll be using historic averages rather than ranges. If you examine the probability curves of historic averages, there’s a strong possibility you’ll only hit that forecast velocity 50% of the time. (I’ll expand on this in a more detailed article on estimation)

Do not confuse story points with being anything other than an internal diagnostic to the team and don’t confuse numbers and “data” with meaningful feedback.

If you want to measure the delivery success of the team, focus on what was actually delivered.

Ask stakeholders and customers for feedback – frequently.

Try a simple Net Promoter Score style survey or even better, be lean and “go see”. If you can’t go see, get a video testimonial from the “customer”, play it back to the team and the management.

It’s a lot harder to distort the meaning of a recorded conversation than metrics.

The Flat-Pack User Experience

Reading time ~ 3 minutes

Some things in life cause more stress for me than others.

Building flat-pack furniture is for some reason way up there on my stress-o-meter.
Back in November (when I first drafted this article) I bought myself a new laundry basket, it’s quite a nice wooden box with a flip lid. When I collected it, I discovered it was a flat-pack.

I’ve been confronting a lot of longstanding issues recently (one of many reasons for being so quiet on the writing) – this was the second time in a week I’d had to build furniture.

“What’s this got to do with software?” You may ask.
Everything – not around writing it but around your customer and user experience.

Experience 1: The Charity Shop Bed
I bought a bed from a charity shop, it wasn’t cheap but it was nice. I was expecting it to turn up partially assembled (as a second-hand piece of furniture)
To my mixed surprise and dismay it arrived still completely wrapped but with one box opened.

STRESS ALERT – FLAT PACK BED!

I had to face my fears – get on and build.
I reached about 90% done and discovered an important (but not obvious) piece missing – a central leg.

AAAAAGH – All those stresses and fears were confirmed

Yes, I should probably have checked all the parts were there before starting but I was in “JFDI” mode after building up the momentum to even start!

I called the shop and politely complained.

After 2 days of chasing around, the shop were unable to find the missing piece so they gave me their display model instead.

There’s a couple of mixed experiences here…

First, I hate unfinished jobs. Sitting in my room with a part-made bed with the frustration of the missing parts and the belief I’d bought a cheap secondhand bed didn’t sit well with me. Whilst looking online for replacement parts from the manufacturer I actually found the same bed brand new for £50 less.

I buy furniture from charity shops expecting it to be cheaper and not new. I also expect it to be as seen in the shop (and not have to build it myself). Otherwise I’d have shopped around online. – Beware

Second, I hate complaining, I hate asking for things. This issue put me way out of my comfort zone. The manager of the shop was exceptionally helpful, professional and apologetic. She clearly went way out of her way to spend 2 days with staff trying to track down the parts in their storage warehouse before arranging a replacement. The time lost was frustrating but as I didn’t yet have a mattress I wasn’t too annoyed.

What really made the difference though was her manner, tone on the phone,  complete reassurance and commitment to a successful outcome – the sort of behavior I expect when dealing with a business supplier, not a charity/thrift shop.

Experience 2:  The Laundry Basket
By Contrast, my cheap laundry basket was a joy. I wish I’d taken a picture before it was assembled.  Every part was clearly labelled, bags of components and fixings were grouped independently, packed in easy to open bags. There was even a bag labelled ‘spare parts’

It got better. The instructions were incredibly clear and precise. A paper ruler was provided to aid differentiation of screw sizes (although with the independent bags, this wasn’t a problem). Where there were 2 almost identical parts, an additional note in the instructions indicated exactly how to differentiate the two.

OK so I was alone and it was a dark evening but the exceptional user experience of that small laundry basket really helped finish off what had been a successful day in such a positive way that it even inspired me to start writing again.

Lesson – those small things that give your customer/user a positive experience after you’ve taken their money and when they’re expecting far worse really do stand out.

Post #Agile2011 Playlist

Reading time ~ 2 minutes

An insight I picked up from Jeff Patton during his user story mapping workshop at Agile 2011.

  • Use music to help you facilitate your sessions

Jeff used “Kung-Fu Fighting” as backing/timing music for one of the group exercises.

When I got home I sat at my computer trawling my music collection for perfect facilitation tunes ranging from 3 to 10 minutes long.

I have loads that I’ll unleash on teams over the coming months 🙂

There’s an important trick to these though. They have to be the “right” tempo and style to match the activity and team – generally upbeat and well-known enough that team members can “feel” the end of the tune coming.

In the meantime, in a change from my normal programming I’ll switch to my other passion; music…

If like me it’s been a really intense week and you’re on a post conference come-down (see Doc List’s post on similar here), here’s my recommended selection of music (in this order) to recover to…

If there’s any of these you don’t own, buy them now or cue them up on your favourite online station! I’ve added links to the hardest-to-find tracks.

2011-08-14 All Agiled Out – on Spotify

* playlist heavily influenced by available music selection on the airplane journey home

Note – If you’re not feeling so cheerful, It’s important you don’t stop part-way through.

For anyone who’s a fan of “High Fidelity”, the art of the compilation tape is the journey you’re taken on.  This one will only leave you happy if you make it to the end!