Stop Trying to Fix Your Weaknesses (Part 1)

Posted on August 1, 2013 by captain

Reading time ~ 4 minutes

Recently I’ve been working on a new approach to personal development plans using a few tricks from lean & agile thinking. Today I wanted to share the foundations of the approach.

It started with a lesson from the same coach who taught me that a leader sets the tone for their team.

As part of a leadership program I attended with one of my previous employers back in 2007 I completed an in-depth 360 degree appraisal to learn more about my behaviors and emotional intelligence.

The assessment required input from 20+ people who knew me.

All direct reports
All immediate team peers
A selection of friends and colleagues across teams
My direct manager
My Manager’s manager
At least 2 Suppliers
At least 2 Customers

Every attendee of the residential programme was given their 360 degree feedback in a 1-1 session and walked through the results in detail. In a couple of alarming cases, the disconnect between how a person saw themselves and how their teams saw them actually required individual counselling.

In my case, I found that everyone but my direct manager was very closely aligned with my self-perception. Given the high standards my manager held for all his team I was happy with this result – he measured the team’s comparative performance against his own exactingly-high standards, it’s why we were both successful but continued to strive for improvement.

The walk-through of the 360 showed each of us what was considered an “acceptable” competence level for each category measured and what was considered “exceptional”.

This is a pretty powerful way of thinking about things. We may all want to be exceptional but I’ll highlight the lesson many people miss with an example…

Usain Bolt may be currently the worlds greatest sprinter but that doesn’t mean he’s the world’s greatest javelin thrower or even marathon runner.

Chances are he’s pretty good at other things – as a world-class professional athlete he’ll have a broad baseline of skills but he knows his strengths, invests in those and doesn’t waste his effort and training on the areas he’s just “ok” at.

He’s part of an Olympic team. In order for his country to be successful he’s surrounded by a high-calibre team with a broad set of skills, specializations and expertise. His team mates will be signficantly better than him in some areas.

By all means address your shortcomings that are actually problematic but recognize which skills you only need to be “OK” at, which you don’t need at all and where you need to excel. If you need excellence across the board, chances are you need a team, not an individual.

Look around you and build a team that complements each others skills, gaps, shortcomings and mediocrity.

Save your precious time & effort (eliminate waste!) to focus on your strengths, find someone else to complement your weaknesses instead.

At my current employer we already seek 360 feedback (but not at quite the depth of the EI appraisal) as part of our monthly staff 1-1s where we discuss performance, status, career direction and well-being. We don’t have annual performance appraisals but we do encourage staff to have personal development plans if possible (note – we only encourage them, they’re not mandatory).

Recently I’ve wanted to improve our uptake of development plans for the team but I know they’re often really hard to work. Let’s consider some of the issues I’ve seen in weak personal development plans over the years:

Management-led

Despite there being a need for the person being developed to “own” the plan, the manager is the one to identify and initiate the process and then draw out the plans and actions. This leaves little ownership, motivation or inspiration for the developee.

Lack of ideas

When a developee first starts on a development plan, they think they “should” improve and move forward (it’s what businesses expect of us) but are unsure on personal direction and their needs. They may be starting with a blank slate.

Driven by identified shortcomings

The concept of a “PDP” is often a remedial measure. Whilst this may be necessary, they focus on getting developees “above the line”. They lack a means to shine and excel.

The “day job” gets in the way

Activities required to significantly level-up in an area may be disconnected from what’s required to simply deliver on a day-to-day basis. Balancing a day job with significant performance improvement is hard.

Behavioral improvements are hard to implement

If a developee isn’t a team player, how do you draw that out and get them to the point where they don’t revert back when the plan is over? Are there alternatives?

Over-commitment

Over-ambitious development plans may feel great when first drawn up but energy and motivation dwindles fast when things are difficult to achieve.

The approach I’m exploring aims to tackle these using lessons from lean, agile and my personal experience from the EI 360. Here’s what I’m trying out…

Collaborative Development

I work with the developee in a one on one workshop-style format. We take over a room for a couple of hours and using a structured, visual, kinesthetic, reflective sequence of steps we gradually fill the walls with thoughts, ideas and actions.

Seeded Options

We’ve developed a list of over 20 concrete “activity types” for generating ideas that work well for developing people in novel ways. By borrowing a 5S tactic – Seiton from Lean we create a placeholder space for each action. We know we’re “done” when each activity type has its single placeholder space filled.

Focus on Strengths

Here we aim to eliminate waste. Instead of looking at weaknesses, we explore 3 areas; “I think I’m good at…”, “I need to improve…”, “I’m happy as I am with…”.

Note the use of first person statements – this is about self reflection, not external direction.

In explaining this area we point out that items “I think I’m good at” are potential strengths that can be developed further. Items “I need to improve” should only be for weaknesses that actually need to be addressed within the context of their team, role and self development. Items “I’m happy as I am with” are areas that even if weak, do not need to be developed further.

Balancing the Day Job

In order to be successful, we need to ensure we have sustainable pace. We achieve this through setting a series of planning horizons and using visual management and physical constraints to define natural WIP limits.

Highlight the Spectrum of Skills

I work collaboratively with the developee to draw out the list the skills they have or may be required for their development needs. We explicitly call out Role-specific skills, additional broader skills and soft skills as 3 categories. We then use simple measurement & rapid feedback to establish both baseline and desired levels for each area.

Iterative planning

After pulling the threads together and building a plan with sustainable pace, we sanity-check the plan. Do we feel what’s there is achievable in the next sprint (for example). We agree the review and follow-up cycle and adjust as we go.

In part 2 you can read though the detailed mechanics of how I’ve been doing this with some of my team, including some minor improvements as a direct result of writing up the details. I’ll post an update on how this is all going in future.

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.

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.

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.

You Are Not A Lathe Operator

Posted on January 23, 2012 by captain

Reading time ~ 3 minutes

This weekend my replacement copy of “The Goal” arrived. (My last copy escaped).

I wrote the following article in mid-2009 – some time before I read Goldratt’s “The Goal”. This was eventually published in 2010 internally at the company I was working with at the time. Today felt like a good day to refresh it and share more widely.

________________________________________

If you haven’t yet done so – read up on the theory of constraints. In fact I recommend that every manager in any size of organization obtain and read a copy of “The Goal” discuss it with your peers & teams and make copies available for your staff.

In Spring 2009 I had the good fortune to attend a training course in Florence, Italy – a hub for European manufacturing training for a large Oil & Gas company.

One of my working team during the week was in the process of implementing a lean production line for the local factory floor. Their layout and travel spaces were all mapped out but the reason for him attending the training was to cover the human aspects of such a radical change.
He had factory floor staff who had been performing the same expert role for 20-30 years or more. Now they were being asked to radically change their working practices and he was feeling the pain.

An operator producing bearings may traditionally be measured on their production volume (and quality). Their single-minded goal is to maximise their own output. The more bearings produced, the better an operator they are. In some cases, particularly where waste is not well managed, volume may even trump quality.

In a production line, operators are contributing not to the production of bearings but to the production of complete working units as part of a team.
They have to look both up and down-stream and assess the state of flow through the entire team. If there’s a bottleneck in the line, they’re expected to adjust or stop their own activity to help out and “level the load” in order to maximize the performance and throughput of the entire assemblies they’re working on in the factory.

The challenge here was that some operators had learned over years of training and measurement to sub-optimize around their own roles and personal output even though the real unit of value was in the whole team’s output.

His challenge was not unique and for this particular company, lean manufacturing was already a major focus. The striking synergies between lean & agile meant I was able to share insights from my own experiences with him.

Now let’s take his example and consider some quotes often heard during software development.

“It’ll be far more efficient if I do all the coding now in one go.”
“Seeing as I’m already doing some surgery here it makes sense to add these few other things that I’m pretty sure we we’ll need”.

Often these are suffixed with “it’ll be ready in when it’s ready”.
I’ll raise my hand and admit to this behavior in the past – particularly when in the midst of a major refactoring exercise.
But…

What about everyone upstream and downstream of my code?
What’s the impact on the testers of me delivering 3 months worth of code over 2 days worth of code?
Do I have people waiting for work downstream?
If I changed my delivery practices would I get feedback sooner?
If I got feedback sooner would those bugs be less of a pain to context switch and fix?
Would the overall throughout of the team be greater?
If requirements change how much of my work would be wasted?

This is where agile and manufacturing meet.

Admittedly in manufacturing, the concept of a multi-skilled operator is far more prevalent than in software however the software industry equivalent is often described as the “Generalizing Specialist” – that is: whilst a member of the team may primarily be role X, they are able to add support and value in role Y – even if that’s not their job title.

This may be a simplification of reality but some skills are exportable or importable across roles and allow us to level the load by having others do the heavy lifting.

It is the responsibility of every member of a development team to consider the entire value-stream, the activities of all skills and roles that contribute to a working product increment and ask questions like:

“Am I working on our top priority item? – if not, should I contribute to it in some way?”
“Could we be delivering more finished work sooner if I helped out elsewhere?”
“I’d really appreciate someone covering these areas around the edges of what I’m working on”
“Here’s a problem that keeps slowing us down, let’s figure out how to remove the bottleneck.”

Think about your current role in a development team.

Are there opportunities for members of the team covering different roles to support each other better?
Is anyone over-producing in comparison to capacity of other areas and causing headaches downstream?
Could some conversations be had sooner, be much shorter and save pain?

Take some time out this week and consider how your teams and individuals could improve their cross-role collaboration, share some of the heavy lifting and deliver as a more cohesive unit?

The Flat-Pack User Experience

Posted on November 17, 2011 by captain

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.

The Hidden Dangers of an Independent Quality Organization

Posted on October 10, 2011 by captain

Reading time ~ 3 minutes

“We need an independent quality organization, to keep the project managers, developers and business honest”

Today I thought I’d let “Bad Captain” take the helm for a few minutes.

In talking about software quality at Agile Cambridge a couple of weeks ago, the audience were invited to share their insights. Mine was to “avoid independent quality hierarchies” – to which I received a small round of applause (likely from those that recognize the dangers). I’ve had this article in the shed for many months and although my context has since changed, there are many in the software world that face this pain and need your support.

We trust our managers and teams with the finances of multi-million dollar projects, we trust them with staff pay and appraisals when those knowledge workers are generating our primary source of income and we trust them to preserve our intellectual property!

OK so in many cases we have reviews but these are within the same organization. Some companies sadly don’t trust their teams with the quality of what they’re delivering in the same way?

What happened to damage or erode the trust?
What’s being done to rebuild it?
Is it beyond redemption?
Who can lead the change?

Most managers I know and most development teams succeed by having a high level of professional pride and integrity and by doing the right things for their team and product. In the situations where a manager or team doesn’t behave in that way it’s incredibly rare that they don’t get called out by their peers.

It’s professional and long-term product suicide to short-change quality, we just don’t do it.

There is no good reason for a manager and team to not set their own high quality standards and meet them.

Beyond “keeping teams honest”, the other argument I heard for an independent quality group was:

“Because it’s a required function further up the management chain, that’s just the way it is”

Don’t get me started on empowerment, continuous improvement and root cause analysis. It seems incredible that in the 21st century, staff in many organizations perpetuate this attitude. The truth is that this is still incredibly common.

Unfortunately I don’t have all the answers today but here’s a couple of thinking tools to present…

Let’s run on the assumption that we really do need an independent quality group. As I see things, that team has 2 options.

Option 1: Set a high quality bar and challenge/encourage teams to meet it. Negotiate down or stand your ground when the project teams challenge the setting of the bar.

We’ve just built a new source of conflict and waste in our organization with a management chain that have a vested interest in their group’s own continued existence. Nice move!

Option 2: Set the bar at a level we think the team can meet.

We’ve just low-balled our quality for the team. Better still, the team working on delivery are not accountable for raising their quality game because that’s been taken away from them!

Now let’s turn things around.

Option 3: Let teams and managers set their own quality bar. Arrange a proper review where the team use their professional pride to challenge the level they set and determine what’s achievable, what they could strive to achieve next and what are the business and engineering benefits of doing so?

Risk: The team low-balls their criteria.

Mitigation: Lead by example, drive a culture where everyone takes personal responsibility. Reward and recognise teams for raising their game.

Funny, for some reason Option 3 doesn’t seem to need independent QA.

Where I work right now doesn’t have an independent QA/QC organization. Our quality is high, as is the level of trust exhibited throughout the company.

This is the simple stuff, don’t break it with vested organizational interests.

Caveat: I understand regulated environments have a necessity for compliance and independent oversight however that compliance environment is either for safety or due to exceptionally high trust-related risk . If that’s not relevant to your organization, why then are you still doing it?

I’ll return the rudder to Captain Crom in future.

Rapunzel’s Ivory Tower

Posted on September 13, 2011 by captain

Reading time ~ 3 minutes

“If the problem exists on the shopfloor then it needs to be understood and solved at the shopfloor” – Wikipedia

Some years ago I took on an agile coaching role at a very large corporation. Like many stereotypical large corporations, they were seen as data-driven, process and documentation-heavy. Management culture was perceived as measurement-focused, command & control and low-trust.

They had a very well established set of Lean practices and managers promoted strong values around empowerment. Despite Lean training for all staff, there was still a very limited “Go See” culture. Above a certain level it was still traditional management-by-numbers and standardization – mostly by apparent necessity through scale.

James Lewis recognized some of these challenges. (but was perhaps more brutal than my insider view)

At the start of the transformation the leaders wanted to know “who’s agile and who isn’t”.

Disturbing as the thought might seem, their motivation was sound. We’d all put our careers on the line to “go agile” in order to turn around a struggling group. The last thing needed was a disaster project with “Agile” being labelled as the cause of failure.

(Nearly 2 years further down the line, we managed to have at least one project fail early and be recognised as saving over a million dollars).

We developed an extensive “agility assessment” in order to teach all those involved that “being agile” wasn’t a binary question and wasn’t just about Scrum practices.

The measurement system for the assessment acknowledged that whilst there may be “good” answers, there are no “right” answers or “best practices” – teams could actually beat the system. (If there were “one true way” of developing software, the industry would be very dull).

Beyond measurement, the big challenge I and my team faced was the pressure to “operationalize” agile. To develop common standards, procedures, work instructions, measurements and tools worldwide. The Quality Management System (QMS) culture from our manufacturing background meant that interpretation of ISO accreditation needs was incredibly stringent and was required in order to do business with many customers.

Ironically that requirement kept us almost entirely away from the teams delivering software!

Operationalization was what our managers were asking for and it was very difficult to say “no”. Traditional corporate culture defined this as the way things should be.

So from stepping into a role where we expected the gloves to come off, where we could get out of the management bubble and start making a real difference with teams; within a few months my entire team found themselves unwittingly captive in an ivory tower.

We saw it coming and felt powerless to stop it but as permanent employees fresh into our very high-profile roles, those painful home-truths could not be comfortably raised.

I and my team spent that first period doing what was asked of us and helping teams out for the odd few days at a time wherever we could.

Fortunately all was not lost. At the same time, we invested in a highly experienced external group to engage on each of our sites and drive some of the changes we needed to achieve from within the teams.

Was the value I’d hoped to add in my role lost? – Actually no.

The managers got what they wanted – heavily seeded with a our own more balanced agile/lean understanding and experience.

We weren’t perfect but made a significant series of improvements. The teams actually delivering products had far more experienced consultants supporting them, who as contractors could take the right risks that permanent staff could not have done at the time.

This 2-tier approach actually gave the delivery teams more air-cover to find their own way whilst we worked on coaching the management.

The teams still had a long way to go but were heading in the right direction and getting progressively better. At the same time, the management team learned that Agile isn’t simply a case of running 2 days Scrum Master training, developing a set of procedural documentation and expecting that everything will show 1,000% improvement.

After the initial bedding in period, I and my team were able to build up sufficient trust with our leaders that we could set future direction ourselves. The kick-start needed on change within the teams had already been made. (far more effectively than we could have achieved alone).

With our leadership trust established, after being holed up in a tower for too long, our coaching team were able to reach the real world again. This time it was entirely within our own control, with the management support we needed and enough credibility remaining with the teams we had interacted with to move forward.

We were free, able to step in, learn more, tune, help out and spend months at a time properly embedded on teams taking them forward – reaching that point of empowerment for our team was a coaching journey in itself.

If you’re in the fortunate position to be an agile coach or in a similar role in a very large or more traditional organization, make sure you recognize that your coaching efforts will often be as much (if not more) necessary in coaching your leaders first.

Where’s My Tools?

Posted on August 8, 2011 by captain

Reading time ~ 3 minutes

The most effective tool in the box

Most of the really big successes and game-changers I’ve seen in my career have been initiated through individuals seeing a problem and fixing it themselves rather than waiting for others.

If you need something done that isn’t already happening, nobody else is going do it for you.

Here’s 4 lessons learned from adopting TDD…

It takes time & effort to get TDD into place

You will have to sacrifice “new code” time in the short term. From my experience, time is probably the biggest barrier to successfully introducing TDD on most teams (closely followed by motivation & accountability). Seeing the pay-off on the other side is notoriously hard to when you’re not there – either starting out or sitting at the bottom of the change curve.

If you’re coaching teams, sometimes you might just need to say “Trust me, I know what I’m doing”

“It can’t be unit-tested”

When you or someone else makes this statement they probably mean one or more of the following:

“I don’t believe I have the time to make this testable”
“Nobody has provided the infrastructure/harness/test data for me”
“I don’t know how to unit test this” (and need some help to figure it out)
“We have some architectural impediment to resolve in order to achieve this”

From these statements, which do you think is least common?

Break this cycle by encouraging accountability for making code testable.

This doesn’t just mean the product code it includes taking ownership of your testing tools and abilities as well.

If you’re struggling…

There’s 2 options for you; “abdicate” or “own”

Option 1 – Abdicate responsibility.

You’ll set the tone for your whole team. The next time someone hits the same problem, the cycle will repeat.
At best, someone better than you may eventually address the issue. (And I hope they make you feel mediocre or inferior).
At worst you may find them saying that you didn’t provide the solution for them.

The “best” case is highly unlikely to happen during your current project – maybe even the one after. Just think how much testing debt can build up over the life of a single project. We should be avoiding that, right?

Someone has to break the cycle. If you’re facing pain, why aren’t you responsible for fixing it?

Option 2 – Take ownership of the problem yourself

Great! You’ve recognized that your accountability is part of the problem.

Nobody else will do this stuff for you!

Establish a Personal strategy for implementing TDD – how are YOU going to solve the problem?
The teams and individuals I’ve seen that are successful with TDD have all got there by taking a personal responsibility to do so.

Just Do It

Here’s some suggested steps to get going – you can either do the first few alone or as part of a team.

(If there’s an accountability gap in your group you’ll probably need to start alone)

Round 1

1. Get a unit test harness and environment in place – there’s plenty online but write one yourself for starters if you have to!

2. If you have a database, break that dependency and channel it through something replaceable.

3. Write your first round of tests and see what hurts – now resolve those pains.

Limit the time spent on this first cycle and determine whether you should ask for time in advance or for forgiveness later – it’ll depend on your local context.

Round 2

4. Educate & support your team on what you’ve provided so far.

5. Get other team members to write their own round of unit tests (treat it “as an experiment” if there’s concerns over the effort required). See what hurts and resolve those pains.

6. Encourage and develop shared long-term ownership of the test harness, test data, stubs and mocks (if used).

Remember you’re setting the tone. If someone needs something that isn’t available, pair up, help them provide it and share the results with the team. Don’t leave them alone but don’t do it for them either.

Round 3

7. Repeat round 2 during development until writing tests is fast, easy and natural. (Don’t give up too soon – this is hard work and takes time!)

8. Capture any “wins” and “losses” during this cycle – what benefits are you seeing and what new pains are coming through?

9. Review the wins & losses. Decide what to do about the losses and how to promote the wins up the management chain and across the team. For example either publicise as you go or use as fuel for your retrospectives.

Think about the positive impact that little bit of extra effort and ownership has on you and your team in leading by example – doing a great job that others will want to share, not just a good job.

Abdication or accountability is a personal choice but it affects everyone around you. What are you doing to help your team?