Convergence & Divergence

Posted on May 17, 2013 by captain

Reading time ~ 8 minutes

It’s been a while since I’ve had time to write but I’m enjoying a brief respite between product releases to collect everything I’ve learned in the last 9 months. I have a few rather significant new ideas I’ve been using that I want to share. This is the first. It’s long, in raw-unedited form and likely makes a few mental leaps so please take your time, digest, think about how all this can apply to your environments and ask clarifying questions. I’d like to get this in a more digestible form someday…

Before I start, a huge thank you to Matthew Dodkins who discovered a brief comment Joh & I made whilst presenting at Agile On The Beach in Cornwall last year was something far more significant than we’d realised…

Complex organisational structures cannot be static, in order to remain healthy they must ebb and flow, centralizing & decentralizing around roles, reporting lines, business needs, good practices and knowledge.

Having brought this observation to a more conscious point, I and my fellow managers at my current employer have put this into active use…

Most experienced facilitators are used to talking about a diverge->converge process as used in moving from brainstorming to actions.

Diverge = generate ideas
Converge = choose the most promising

What I’m talking about here has very little to do with facilitation and is a reversed view (converge, then diverge) however it’s more accurate to view this as a natural continuous tidal cycle.

Theory: The Converge-Diverge Cycle

The Converge-Diverge Cycle applies to organizational structure, behavior, process and even technology.

Although at any single point in time an organizational structure may appear static, many organizations develop natural rhythms of restructuring over time. At General Electric that cycle was roughly every 2-3 years at a wholesale organizational level. At Red Gate it’s closer to 6 monthly but cycles incrementally through divisions and operational functions.

At worst, poorly managed organizational tides are pretty toxic but at best they help re-balance interactions, interpersonal relationships, behaviours and practices across diverging groups.

Here’s the cool bit…

Which direction are you heading?

You’re always in either a convergent or divergent cycle. If you know which way you’re heading you can make an explicit decision to let the tide continue in its current direction or to turn it back. The longer a tide moves in a divergent direction, the longer and more painful the resulting convergence may be. The longer things remain converged, the more constrained your learning, innovation and evolution.

(unnecessary or diminished-value convergence can also occur – think “spork“)

Simply being aware that convergent or divergent cycles exist makes it possible to step back, observe, interpret the current direction of travel and make a conscious choice.

Your Convergence may be my Divergence

In organisational structures, convergence can shift from one position to another, causing divergence in its wake. (I’m getting a bit philosophical so I’ll back this up with some real examples shortly). Think about the age-old “Us vs Them“ mentality. Most often seen between the “business” and “development” or in bad cases between “development” and “testing” or between you and your supplier or customer.

Whilst it’s important to take individual responsibility for increasing the bandwidth of communication from email to phone to face-to-face, it’s really hard to do – particularly in a conflict situation. The more physically and organisationally separated groups or individuals are, the stronger the “Us vs Them” pull may be. Beyond relying on individuals to play nicely, how about changing the structure and dynamic of the groups to foster closer collaborative working.

Equilibrium

So now it gets tricky…

Each “Us” or “Them” has a set of existential goals and motivations. These aren’t necessarily combative but often they aren’t aligned to each other. We know this lack of alignment can cause problems but what happens when we realign?

The best example of this that I frequently see is organisational structures that provide a centralised (converged) service. The centralised service convergence drives common “best practices”, efficiency and greater synchronization across the group that are all trying to provide a similar service to multiple “customers”.

This convergence is often at the cost of quality of service, responsiveness, tailoring and specialisation to the needs of a given customer.

The “Us & Them” conversation is between the service and each of their customers.

From this shared starting point, if we reverse this, diverge and decentralise the group with the service team distributed to directly serve each customer we find that responsiveness improves, tailoring increases and localised “best practices” emerge but it will have its own costs and compromises.

Standardization

I spent some years running an organizational standardization programme and have been involved in many others. I’ve seen the pain and cost of these first-hand. Often the primary benefits are in management reporting and process certification, not improvement. I’m a strong believer in no best practices. Following a “best practice” implies there is nothing better. This mindset will stifle continuous improvement. There are however best known practices for your current context, situation and experience.

Process or tool standardization is not a sensible goal in itself. What is this trying to achieve and is it really the end point or simply a pivoting point between converging and diverging?

Reconsider where you’re standardising today. If these stayed locked-down for a decade and only evolved in a single direction, would this be bad for your teams and your business? If so, what’s your divergence strategy?

Who’s “Us” and who’s “Them”

Initially the ties of a previously converged team remain strong. You benefit from the strength of prior working relationships and team bonds to maintain synchronization.

This only lasts so long. After a surprisingly short period of time – particularly if groups are under pressure – (less than 6 months in my experience), the “Us” vs “Them” returns however this time it’s between groups with diverging and potentially competing approaches. The former ties have weakened and new ones are formed. And this increases over time.

There is no long-term equilibrium. There is always an “Us” and a “Them” somewhere.

Great, we’re doomed to hate each other eventually and our evolution is over – so what do I do?

Deliberate Convergence & Divergence

There’s many existing strategies for forging and retaining ties between groups and a bunch of organisational team-building resources available with a bit of searching. Most of these need time set aside and essentially keep some bonds alive but rarely provide opportunities for continuous evolutionary improvement.

Here’s the cycle that usually happens

We’re heading in the wrong direction.
Someone realises there’s a problem that requires convergence in a different direction.
An organizational change programme is initiated
Time and money are invested in effecting a large organizational change
Productivity and Morale take a beating.
The changes bake in
Rinse & repeat

Here’s the “deliberate” equivalent

As part of a regular review, current direction is assessed.
We determine if we’re converging or diverging on the right things, what’s working well & what’s not.
We make an explicit decision whether to change direction.
We give things a “prod” in the direction we want to go.
We do this regularly enough to stay fresh but slowly enough to be stable.

Here’s a couple of real examples from where I am right now…

In Practice: Organizational Convergence & Divergence

We have a number of teams who are responsible for providing centralised services. HR, Publishing, IS, DevOps, Finance. These groups are co-located teams and interact with their internal customers.

Team 1: HR

Our HR team assessed how they were working and made an explicit decision to diverge.

Each division now has an HR specialist who sits co-located with their customer.

The HR team still get together regularly but they’re now a diverged group.

They’ve structured things so they won’t diverge any further but also know that all decisions are reversible. We may re-centralise them in a year or two’s time in order to put a load of energy into a large centralised change.

Team 2: Dev Ops

Our DevOps team were a centralised group for over a year. They worked closely with IS but provide a service to sales, development and finance (among others).

Because of the nature of projects and changes on the cards we had 2 choices.

Disband DevOps, put skilled DevOps staff in each delivery team and diverge the service
Converge DevOps, Business Intelligence and IS even further to run under a single pillar of the organization.

We chose further convergence. The team have radically altered their processes and have focused on the top priority company-wide priorities. Some other teams will miss out on their requests but in the larger scheme, this was seen as the most effective structure for our current needs.

Team 3: Sales

Our product organization was divided into a number of divisions. Each division had its own sales force co-located with the development teams. This was working great for development but it gives a really bad customer experience when a customer owns products from multiple divisions. We’ve converged the sales team and brought their processes and practices together to give a better customer experience. We’ve sacrificed the closeness of development and had to drop some division-specific process tailoring but we’re having better conversations with our customers.

In all 3 of these cases, I fully expect these changes to cycle in a different direction at some point in the next 2-5 years. As do the teams – it’s simply how we evolve.

Because we know things will change again, we’re less entrenched with the status-quo.

As an aside, we don’t hot-desk here but because our organisation is so fluid, most staff have moved desks 3 or 4 times in the last 18 months. We treat this as normal. We still have our own space, desks, walls & possessions but we stay mobile enough to move ourselves in under an hour’s effort.

This week we’ve asked all our development staff to propose where they each feel they can best contribute for the next 6 months and based on those preferences I’m expecting to see over 20% of our teams move again.

In Practice: Process & Tool Convergence & Divergence

I mentioned earlier that standardization is a directional way-point, not a goal.

I spent nearly 2 years “standardizing” Scrum, Lean & Agile with one employer. At the time it was the right thing to do. Most parts of the software group had never had any form of large-scale convergence. As a result the effort & pain were significant however we took teams who had been working in their own evolutionary islands for 10-20 years and brought increased commonality to them. We reached very close to standardisation but deliberately designed our ISO processes to support limited positive divergence.

At my next employer, my first action as head of project management was to explicitly state that we would not be standardising our project practices. All teams had standardized on Scrum 3 years earlier and had been slowly diverging. Having observed the teams and contexts it was clear we had scope to diverge further whilst still remaining healthy. In fact, it gives us the ability for concurrent parallel learning and improvement. We learn more and we learn faster.

2 years later we’re at the point where I want to introduce some convergence. Rather than a complete standardisation we’ll be developing a playbook of “known good practices”. It won’t be exhaustive, it’ll start with the top 25 things we think are a no-brainer and we’ll work from there. Some of these things won’t be common across the teams when we start. Eventually they will be…

… and then we’ll decide whether to continue converging or to diverge again.

Great, now what?

Review where you currently stand.

Which groups are converging and diverging? – Observe and interpret.
How long have they been moving in that direction?
Are you willing to continue or is it time to adjust? – Make an explicit decision
How large and fast a change is needed? (if any)
How will you push in the direction you need? – Deliberate action
How long do you expect the next cycle to last? – Tidal change
When will you next check?

Whew! That was epic. Thanks for reading to the end. As always, I’d love your feedback.

Kipling and Keogh on Requirements

Posted on February 11, 2013 by captain

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!

Rudyard Kipling

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.

Cracking Big Rocks

Posted on January 26, 2013 by captain

Reading time ~ 3 minutes

Things have been rather busy over the last couple of months. I’ve joined a new division at my current company and have the basis for another dozen articles slowly developing but that’s just the start. I have some really exciting news!

After over a year of development with the exceptionally talented Johanna Hunt (@joh) through field testing, workshops, paper prototypes, conferences, conversations, and peer reviews I’m very pleased to announce the launch of crackingbigrocks.com.

The Concept

In trying to solve problems of our own, we found challenges that we now identify as “Big Rock” problems – those things that when faced alone cause us sleepless nights and illogical stress. The mental load associated with Big Rock problems can be so taxing that every time we go to tackle them we find ourselves procrastinating and avoiding or exhausted through trying. A deep breath, a step back, a few pointers, a second brain and some support can help us get back on track.

We’ve faced these problems in both our personal lives and professional careers. For example the series of articles I wrote on “The Oubliette” describes the multiple strategies I used for reducing a major defect backlog.

(I’ve spent the last 2 weeks reusing the oubliette strategies along with a few new ones to help my new team get our quality back under control and keep the motivation to improve high.)

Simple Patterns & Coaching Cards

Between us we’ve taken the “Simple Patterns” concept and our combined experiences of solving large, difficult problems and developed a set of over 50 simple problem solving patterns. In particular, we’ve captured the essence of big mental hurdles and how these can be overcome in ways that have resonated with almost everyone we’ve shared with. (Of the 150 or so people who’ve explored the concepts so far, only two didn’t find they had “Big Rock” problems of their own.)

We’ve produced a limited first edition set (only 50 decks) of high quality coaching cards containing 45 patterns. (Within a week of the box being delivered, with no marketing at all we’re already down to just 35 decks left!)

As of about June 2013, the first edition has sold out however the expanded second edition is now available on amazon.

It turns out the ideas and concepts we’ve captured and the formats we’ve chosen are significantly more popular than we expected. Back in August 2012 after a weekend of hand-trimming and cutting (causing a few injuries and RSI) we produced nearly 40 paper prototype decks with unedited wording and far fewer patterns. We gave all of these away and left a few attendees disappointed after running a hugely successful workshop to a packed-out room of nearly 80 attendees at Agile 2012. A month later we had to produce a few extras for a re-run at Agile Cambridge (and took the opportunity for some edits whilst we were at it).

We delivered our first bulk-order for nearly 200 decks for attendees at Agile Cambridge in 2013 and ran another packed-out session. Our good friend Olaf regularly takes a few sets out with him to Play4Agile in Germany.

Even whilst developing and trimming the original prototype decks, we actually used the patterns within the decks to “keep rolling” – the idea of having to manually cut out and collate over 1500 paper playing cards is quite a “Big Rock” in itself. We measured our throughput rate, adjusted our cutting process, optimised our flow and working practices, banked our results in suitable sized batches and made sure our pace was (mostly) sustainable!

Here’s a quick preview of what’s in the box…

The majority of patterns in the deck are unique to us but there’s a couple that are better known (such as the “Rubber Duck” shown above). What’s unique here is the format, approach, style and most intriguingly, the community we’re aiming to build. We want to share the ideas and experiences everyone has using these cards as coaching and problem-solving tools.

If you’d like to find out more, head on over to crackingbigrocks.com and take a look.

OK. Marketing over – I generally find selling or marketing what we do a little crass so I hope you as readers don’t mind too much!

So what’s with this Pirate thing anyway?

Posted on December 4, 2012 by captain

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.

Stopping The Line

Posted on November 13, 2012 by captain

Reading time ~ 4 minutes

A few weeks ago the Company I work for celebrated its 13th birthday. As part of the celebrations we were each given the latest copy of the “BoRG” – the company book. On reading through the pages I found one of the teams I’m responsible for received an award.

This isn’t quite as positive as it sounds and I’m pretty sure the incident will become lgendary within the company. The lessons learned, what we did afterward and the forward thinking attitude of our senior management are however truly worth celebrating.

The (rough) Story

Over the summer one of our teams was working on some updates to our product deployment tools (we deploy upwards of 50 new releases across our product portfolio every month). Part of the automated process involves uploading a packaged installer for our software to a download location and updating our web site to point to the update.

Due to a mix-up between environments and configurations, one of our internal tests made it into the outside world. The problem was spotted and resolved fast but something was clearly wrong for this to have been possible.

This alone would have been rather embarrassing however this was about the 6 or 7th significant incident that had come from our operations teams in as many weeks. We’d recently restructured team ownership of parts of the codebase, were making a large number of significant infrastructure, library, test and build changes to our systems – mostly legacy code (code without sufficient tests). Moreover, we added a whole new team onto the codebase with a very different remit in terms of approach and pace, the volume of churn in the code had massively increased.

This was all during the height of holiday and conference season so many of us weren’t fully aware of the inner carnage that had been occurring. Handing over from one manager to the next repeatedly meant we’d not seen the bigger picture.

I returned from Agile 2012 to a couple of mails from my boss (who was now on holiday) to fill me in on what had happened with the (paraphrased) words: “Can I leave this safe in your hands”.

Over the first 2 hours of my return I was briefed by managers and team members on the situation. Everything was sorted, no problems were in the wild but the team’s credibility had taken a beating.

I’d seen similar things happen in other companies and had always been certain of the right course of action. This was the first time I actually felt safe to lead what I knew was right.

I donned my “Lean” hat and started my nemawashi campaign with our senior managers.

I spoke to each manager individually – they were already well aware of the problems which made things much easier. I simply said.

“These problems can’t continue, we’re going to ‘stop the line’. All projects are going to stop until we’re confident that we can progress again safely.”

I went a step further and set expectations on timescales.

We’d be stopping development work for nearly 20 staff for at least a week. We’d monitor progress daily, and approval to continue would be on the condition that we were confident problems would not reoccur.

By lunchtime I had unanimous support. It was described as a “brave” thing to do by our CEO but all agreed it was right.

A side-benefit of Lean is the shared language it provides. In every case when I approached our management team and explained that I wanted to “stop the line” they immediately understood what I meant plus the impact, value and message behind such an action.

Now of course you can’t prevent new problems with hindsight but you can identify patterns of failure and address these. In our case I had a good understanding of what had been going on.

Initially I was strongly against performing a full root-cause analysis. There were half a dozen independent incidents and a strong chance of finger-pointing if we’d gone through these. I was already “pretty sure” where our problems lay. The increased pace had led to a fall in technical discipline coupled with an increased pressure to deliver faster and a lack of sufficient safety net (insufficient smoke tests).

I divided the group into 3 teams to focus on 3 areas.

“before release” – technical practices
“at the point of release” – smoke tests
“after release” – system monitoring

With an initial briefing and idea workshop I stepped back and left the 3 teams to deliver.

The technical practices team developed a team “technical charter”. We brought all participants together for a review, revised and then published this. Individuals have since signed up to follow this charter and we review it regularly to ensure it’s working.

The smoke testing team developed a battery of smoke tests for the most critical customer-facing areas (shopping cart, downloads etc). These are live and running daily.

The monitoring team developed a digital dashboard (that I can still see from my desk every day). This shows the status of the last run of smoke tests (and history), build status, system performance metrics and a series of alerts for key business metrics that would indicate a potential problem with the site – e.g. a tail-off in volume of downloads or invoices.

They also implemented some server-side status monitoring and alerts that we subscribe to via email.

Since these have been in place we *have* had a couple more incidents but in every case we’ve spotted and resolved it early.

Subsequently a couple of the teams have self-selected to perform a root-cause analysis on a couple of issues. This is exactly the behaviour I love to see, it’s not a management push, they simply wanted to ensure we’d pinned things down and done the right thing. Moreover, they published the results to the whole company.

The award…

Project Envisioning with Six Stickies

Posted on October 2, 2012 by captain

Reading time ~ 5 minutes

This is an approach I developed a couple of years ago whilst working with a team in a difficult (but quite common) situation at my previous company.

Bizarrely, about a week after I started drafting this article (a long while ago now), another blogger independently described an almost identical tool and approach, I just wish I could find it.

The Context

The Product Manager for the team I was supporting was responsible for a small portfolio of products of varying age and quality and like many Product Managers I’ve met, he had insufficient budget, time or delivery capacity for “everything”.

One product in particular was causing pain. Commitments had already been made to at least one large customer that a “radically overhauled” version of the product would be delivered to address all their reported complaints.

(You know – the kind of commitment made when you’re on a customer site and they’re tearing you a new one over a multitude of frustrations and you just want to make them happy, right?)

This commitment had been made on the spot prior to any investigation and without consulting the development team.

Sound familiar?

Did I mention how much I now enjoy working for a company that only sells software that already actually exists?

This overhaul wasn’t just being developed for that one customer. They wanted to re-launch the product as an advanced graphical web-client with full multi-user query/read/write/print features. (The original was a read-only system)

When the team started to explore the “product”, they realized just how customized the customer’s version was and how unloved, limited and just plain sick the original was.

The UI sucked
The underlying code was the result of years of consulting engagements strapped together
Consultants has to wire the internals together to make it a running product (Out-of-the-box it didn’t work)

It was basically a collection of disparate tools in a very jumbled toolbox.

Despite all of its ugliness, many customers were actually using it. It was typically thrown in free with most enterprise licenses and was far easier and cheaper to roll out to the majority of users than the seriously advanced thick-client CAD-like system.

The team had their work cut out for them…

All they had to start from was the usual laundry list of features – 1-liners. Fortunately this was enough to be clear already that they were never going to deliver “everything” (or possibly anything) on time.

Fortunately their Product Manager was a great guy. Masses of domain and customer knowledge, supportive, collaborative, made time to be available regularly despite being on the far side of the world and experienced enough with software development to know when to listen to his technical team.

The team highlighted the impending scope & schedule disaster as soon as it reached their shores and within a week the Product Manager was in the UK ready to hit the reset button.

The Goal

We needed to re-frame the project, determine what scope could be cut or postponed, what could be delivered sooner, what was a priority and how the team would approach delivery.

The Process

We arranged 3 days of workshops with the product manager and full development team in the room together.

Background

Before we dived into details, we worked with the product manager to give us the real story on why the product existed from our business perspective:

What revenue did it provide?
How else did it support our sales?
What was the longer term direction for the product?

This was restricted to 1 sticky per question.

We then captured (on 2 stickies) what the users normally did with it – what were the most commonly used functions and what was the frequency and duration of these activities?

Vision

To start things out with the best possible foundation, we spent the first morning on “Envisioning” (or perhaps “Re-Visioning”).

I’m not convinced the Product Manager was particularly sold on the value of the session but he was willing to play ball – he trusted the team and I to do the right thing. (and after all this was just 2 hours of warming up for 3 days of workshops).

As we started it became apparent from team conversations that they were struggling to establish exactly what the product they were working on was really expected to do, why and who for. (pretty fundamental stuff)

I led the team through a series of facilitated discussions around 6 areas of the project/product. The order we approached these and the constraints used for documenting them were a critical part of the process. We constrained the documentation to the smallest, simplest thing that could possibly work. One sticky per conversation theme.

Needs – What top priority business needs is the product/process addressing?
Wants – What do the end users want from the product/process , what specific tasks are they trying to achieve?
Business Process – What business process are we aiming to model, support or improve?
Scope – What’s the explicit planned scope (features & fixes) for this release? (limiting scope to a single sticky is a great way of starting out small!)
Immediate Goals – What is the top priority single goal of this particular project/release?
First User – Who will be the first actual consumer of what we’re delivering and when do they need it?

Scope

We knew the product manager already had an idea of what scope he wanted and that we were going to need some kind of polite reset conversation.

Our approach was to collaboratively define what the “minimum marketable feature set” (MMF)** for this release would be.

**At this company, MMF was loosely defined as “the bare minimum set of functionality that would be added/improved in order to deliver incremental customer value and be worth announcing to the market.”

Through scope exploration, we established the team needed to deliver a lot to make the product viable. We were however able to trim a number of very high complexity/risk items in order to bring things in sooner. Better still we’d had a powerful scoping conversation with the product manager to set clear expectations on what would be highly unlikely to be delivered and had sequentially prioritized every other feature in his original release wish list.

Putting each item on a sticky, and having an explicit MMF marker was a great way of visually defining the backlog. (This also kept the number of items in the backlog small enough to summarise quickly)

Acceptance

The final piece of the puzzle…

Having defined context, scope and vision for the release, we defined what “acceptance” of a new release would entail for the end user. The power of this was that we could correlate current and later scoping conversations around the fundamental user acceptance expectations without our Product Manager getting emotionally attached to the scope we’d originally talked through. Once again, we constrained the acceptance to keep things small and simple. (one sticky was plenty) .

What next?

After this initial few hours, the team spend the remaining 2 and a half days working hard with the product manager to flesh out all the top priority features/epics in sufficient detail that they could start de-risking and developing by the end of the week. They didn’t need my help for those bits 🙂

Note, the quality of writing on this article may not be up to my usual standards. This has been blocking my backlog for quite some time. I needed to get the story written from my rather hazy memory and move on more rapidly than normal. I hope however that it’s still valuable.

Why You Should Stick To Using Whiteboards & Stickies

Posted on June 19, 2012 by captain

Reading time ~ 4 minutes

If you aim to improve, inspect and adapt on a frequent basis in a highly unconstrained way, stick to a whiteboard (as large as possible) and stickies (and possibly scissors, tape, card, paper, pens – did I mention that many Agile coaches I’ve met have an addiction to stationary that stems back to their childhood :)). Your process will adapt to the project significantly faster with a manual board.

As an example, here’s the original board used on my current project (it’s now cleared down as we migrated to a better space) :

: (Thanks to Andrzej for the rather disturbing portrait)

The board was too small and constrained (much like many electronic tools) so we switched to something better. We reused the board layout and approach from a previous project (see 5S your Scrum board) as a kick-start but less than a week later we had already moved forward significantly from where we’d started. Our needs on this project were different enough that we had to adapt.

Here’s what the current board looks like this week:

: (Thanks to Ellie for the donated parrot)

The mass of stickies across the bottom of the board is where we cut scope for this sprint as the result of an over-commitment. This was spotted as soon as we migrated to this board and I started plotting additional information for the team around the edges.

Admittedly what we have here could potentially be implemented electronically as a board and a series of “widgets” but that needs development skills and time – this would slow down our speed of adapting.

In our example, adding avatars was a 15 minute job with scissors & tape, adding a capacity planning check took 2 minutes and adding new charts and graphs took 10 minutes. Better still – an unplanned adjustment – when we have a success story from our users, one of the team will bring the evidence along and tag it to the board in whatever format they wish.

There’s some further changes needed to our process this week. One of the horizontal streams of work is a (roughly) repetitive series of activities so we’re going to start tracking cycle time on these and moving to a Kanban model as we need to start setting expectations to our users for these areas. In parallel, the less predictable work will be continuing Scrum-style for the development team. We’ll be ensuring the board captures these stats for us to see every day.

As soon as you start using electronic tools, there’s an immediate speed barrier to the changes you want to make plus there’s often the constraint of a small screen (or investment in a large one), how to add related information in meaningful ways without underlying data model support, user experience, data entry and the ability for non-technical team members (my current team is 50% sales & marketing staff) to make changes.

Don’t get me wrong, when you have a globally distributed team, you’ll almost certainly need an electronic tool as a single point of truth but it’s just not tactile or flexible enough to support the level of interaction and adjustment that a constantly evolving project and process needs. Many companies adopting electronic tools push for standardisation to keep processes consistent, costs under control and sustain support for reporting aggregation. This really stifles making adjustments to the process to suit project and environment context.

I’m not entirely down on electronic tools. I’m actually quite a fan of Trello at the moment and use this for sharing our bigger picture with the spectrum of stakeholders we have around the business that cannot be co-located. At least it’s a tool aimed at users, (rather than many commercial electronic boards whose capabilities tend to target management reporting instead) however for now Trello is limited to swimlanes, a constrained card format and the need for a screen. It’s not quite tactile or ubiquitous enough. Extending it requires time, technical skills and screen real estate rather than simply a process gap and a creative team member.

In my time at a very large US corporation we did a great job with the constraints we had. We used giant smart boards with virtual card walls, high-spec videoconferencing and large TV screens. At the time it really was state-of-the-art stuff but it still limited our visual management capabilities. We only ever really had a shared basic card wall (the reporting and metrics weren’t particularly visible to the teams). All the other peripheral information you can get from a great board during your standups wasn’t visible.

The teams actually developed and maintained physical boards in each location and ended up using the electronic tools as a synchronization point.

Whilst we could virtually move cards around on a giant touch-screen, changing information on the cards themselves required reverting to a keyboard, detaching from ongoing conversations and manually editing within the tracking tool. It worked but it really was a compromise.

Contrast this to our current board – if something needs adding or updating, the active conversation continues whilst a team member grabs a pen and starts writing. If our process changes, we update the board format the same day.

I just had a passing chat with my colleague David (another of our DevOps team) about electronic vs physical boards. He summed it up brilliantly; “I don’t know why… …but it’s just not the same”.

We also tailed off into the value of an entirely co-located team. A rarity for many these days but a real game-changer in the performance of your teams – I’ll cover this another day.

So in summary, even where you have distributed teams, work with a physical board for as long as possible to allow your processes to adapt and develop to the context and project around you. When you start using electronic tools you’ll find the pace of process improvement will significantly decrease.

If you’re hunting for more whiteboard examples, you may also want to take a look at “A Year of Whiteboard Evolution” and “5S Your Scrum Board”.

Telling Vs Coaching

Posted on June 12, 2012 by captain

Reading time ~ 4 minutes

Before I start, a thanks to @fatherjack for being the first person to request a topic from the backlog. If any of you want more of the same, just shout!

The Story

Up to a certain point in my career, my success was defined largely due to my ability to find creative and often tangential solutions to difficult problems. For anyone that’s completed a Belbin assessment in the past, I’m mostly classified as a “plant“. My major strength has changed very little in 15 years although my complementary strengths and views have all shifted a lot (I might discuss this in more depth another time).

With this strength in mind, I found that when working with others I often jumped past a lot of the detail and rapidly offered solutions and alternatives. The sheer volume of options I can provide means many did stick and work. However, using this approach risked those seeking support or assistance becoming dependent on my problem-solving rather than developing knowledge and learning to solve problems themselves.

When I became responsible for other staff I recognised that many of the strengths that got me to that point were not appropriate to leading or coaching others.

I spent a little time learning basic coaching skills, the GROW model, coaching through questioning and other simple tips. Pat Kua also steered me toward the Dreyfus model of skill acquisition (which in hindsight for me is an important missing link for coaching) but I found that my instinct to solve and help often overrode my learned coaching practices. Coaching others is hard! (or at least it is when you’re normally a problem solver)

Having led a number of teams, managed a full spectrum of technical staff, implemented organizational change programs and most recently being responsible for a company-wide community of practitioners, my coaching skills have become more and more critical to my role. Coaching Dojos have helped significantly – using coaching tools repeatedly as a deliberate practice but there’s still something not quite right. I still have those problem-solving skills going to waste, there must be something I can do with them.

The Lesson

So here’s the thing. Just because you’re coaching doesn’t mean you should only ask questions, it doesn’t mean you shouldn’t direct or tell and it doesn’t mean you shouldn’t get to have the fun of solving problems for (or with) others. You just need to understand more clearly when it’s appropriate to do so and when it’s not.

Learn to spot when you’re “telling” when you should be “coaching” and vice-versa. This can be really tricky to achieve when you have all the answers and ideas.

Fortunately for me, my current employer really invests in their staff. All managers are trained and encouraged in doing just this…

The Tools

The coaching and leadership model we use is “Situational Leadership” – in particular “SLII”. (here’s the explanation of why it’s II)

I can’t cover the full depth of the model in a blog but here’s the basic conceptual framework – this should be plenty to help you recognise when to coach and when to “tell”.

There’s a direct correlation between the style of leadership you (as a coach/leader/mentor/manager/team member/person) use and the development level of the coachee/seeker/mentee/staff/team member/person/team.

Important note – this applies just as much when leading or coaching teams, not just individuals.

We model this as four “Development” levels (D1-D4) and 4 corresponding “Styles” (S1-S4) This might seem a bit jargon-y but putting this into practice really does work (see the diagram below).

The suggested style to use is based on a composite of the motivation of the individual and their competency level.

As an analogy, consider learning to drive a car. Most new drivers are really keen, think this is going to be easy and can’t wait to be out under their own steam (Level D1). As an instructor, you need to let this play out, give them the space to try and succeed (or more often fail) but you do need to be quite prescriptive in what they do for their own safety (and that of others) (Style S1). When things get hard and motivation wanes (Level D2), you continue to tell them what to do but in a coaching style (S2). As competency develops, the trainee becomes more competent (D3) and your style will need to follow. Eventually they will (hopefully) become self-sufficient (D4).

Our regular trainer actually talks us through a lot more than the textbook model. The diagram below is my interpretation of the model with the additional tips we’ve learned.

Extended representation of Situational Leadership II

There’s a few really important points that help us use this as a thinking tool.

The model applies to each specific task. If a person has never performed that specific task before, re-assess their development level. Some complementary skills may apply but don’t assume competence in one area translates directly to the task at hand.
Watch for transitions in motivation as a guide to levels of support to offer. When individual motivation is low, the coach/leader must be more supportive – more guiding and questioning. When motivation is high, less support is needed.
When individual competency in the specific task is low, the coach/leader should be making the decisions on the course of action (even if leading through questioning). When individual competency is high, the coachee makes the decisions but may still occasionally want to validate these with the coach.
A mismatch between leadership style and development level can be harmful. The further apart the difference, the more dissonant the leadership style will be.

Extensions:

There are a couple of important extensions to the model that need consideration.

In many work environments, there are times when a person may have high expertise in an area but not be motivated to actually work in it. Similarly, someone who reached a high level of competence in an area but is ignored may lose motivation. In these instances, they have actually regressed around the model (from D4 to D3). Your leadership style needs to change!

In other situations, you may have someone with little or no motivation to work on a new task and little or no competency. Rather than starting at development level 1 (D1), you’re actually starting at D2. You need to work with the other person to build motivation and competence. At this point they either develop to “D3” or first to “D1” and then back through the cycle.

And Finally

Like all frameworks, this is a tool only. Use with caution. The more you understand how to use this, the better you’ll manage with it. If you’re interested, get trained properly, don’t just rely on what I’ve presented here.

Seeking “Customer” Input

Posted on May 22, 2012 by captain

Reading time ~ 3 minutes

: 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

Posted on April 27, 2012 by captain

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.