About The Captain

Captain Crom started programming and debugging games from magazines on his Brother’s BBC as a small boy in the early 1980s. With early qualifications in both computer science & art and a love of live music it became clear he was destined for bad things. His tyrannical ways commenced with a degree in Computing & Informatics at Plymouth and from the mid 1990's a career in the software industry. After formative years as "The Scourge of the Thames Valley" between Reading and Bracknell with occasional raids on the San Francisco Bay area, since 2004 he has been seen sailing stretches of the A10 North and South of the Isle of Ely with the primary source of his raids targeted around Cambridge. Sightings have also been rumored as far afield as Scotland, Norway, India, Nevada, Florida and Georgia. The Captain has served in companies ranging from successful startups and ailing dot-coms to global corporations, spanning roles from IT, consulting, support, development and management through to agile coaching. The common thread in each of his roles is that he has always chosen to join software product groups - usually large-scale enterprise software. His large-scale product and organizational focus differentiates him from the more common textbook agile captains. (Other differentiators include his distinctive hoop earrings and love of spiced rum) The Captain's Agile experience started with a blend of FDD and XP in what he describes as "the most disciplined team he had ever served with". He subsequently moved onto using Scrum and XP blended with Theory Of Constraints, Kanban and Lean philosophies to improve software delivery techniques in other organizations. He believes every member of a delivery team should spend time with customers supporting the product they produced. “Sitting at the dirty end of a product (or cutlass) completely changes the way you think about business processes and write software for the rest of your softwarefaring career!”

A New Chapter…

Reading time ~4 minutes

Photo of book spines for nautical and pirate books

I’ve been quiet on here for quite a long time now. To be honest, I’ve been through the mill quite a bit over the last year or so. I’ll write about some (but not all) of it when I get back into the habit of writing. Consider this me breaking the seal on a long overdue silence.

Some sad news first. As of last September I’ve left Redgate. I had an amazing 5 years in so many different roles and felt like I made a real difference to so many friends and colleagues in my time there.

Note that I say friends first.

I made more close, important, and (hopefully) lifelong friends in my time with Redgate than any other period in the rest of my adult life. They’ve seen me through the best and worst times of the somewhat rollercoaster life I’ve had (and seen me at my best and worst).

I took a couple of months off work towards the end of last Summer to sort out my new flat and recover from being completely burned out.

In hindsight, that time off was one of the best moves of my career so far. It’s the longest break I’ve had in nearly 20 years and gave me time to recharge and decide what about my life and career makes me happy. I’m doing my best to focus on these. My advice – if you’re feeling burned out, take time out – plenty of it (if you can) and if you can’t… get help – and learn to ask for it.

The great news is that as of November last year I’ve taken on a new role (actually I have 2 full-time roles in parallel as of December too!).

Officially my title is now “Agile Transformation Manager” at a large global payment provider with a supporting role across about 90+ teams worldwide. Even my new boss pointed out it’s not the best job title but was the best they could come up with on short notice.

I also have a second full-time job in parallel heading up development for our Cambridge and Romania development teams (about a fifth of our overall dev teams).

So it’s back to the big company stuff again – I’m using the skills I’ve developed throughout my career along with the full range of cross-business experience I picked up with all the commercial side of teams at Redgate.

It’s relentless, exhausting, lots of travel, plenty of time in London but most of all it’s rewarding. In a nutshell, I love to make a positive difference and spend time with people who care and I’m doing exactly that.

The day I joined, every single person I spoke to said “We’re so glad you’re here“, “How soon can you come and help us” and “What can we do to help you“. No territorial behaviour, no negativity, just a desire to make a difference and be better than they already were.

As a result I now have way more work on my plate than I can manage alone and I’m hoping to start building a team of agile mentors/coaches around the world (if I can get funding – I’m back in a big, public company where budgets are important again!).

The thing I appreciate most is that despite the size of the company, they have a great appetite for change, a positive culture, and an acceptance that one size does not fit all.

Over the next few weeks and months I’ll start posting more from the backlog of posts and stories I’ve built up – I’m hoping it’ll be more relevant to you all than the last few posts as I know many of you are in similar mature/large company scenarios.

I’ve decided to just crank this short post out mostly to say “I’m still here” (and still working in the software, product and agile space). I’m just hoping that I have interesting, insightful and useful things to share again (and to solicit your support and input on the journey).

I’m likely to write a few more things about being a human too – I’ve learned a lot in the last year about resilience, mental health, self care and respecting the world and needs of others. These are applicable to both our personal and professional lives.

Suffice to say if you’re in a bad place, I promise you’re not alone. There are people who care and people who want to support all around you. Be open to that support.

And although we’re nearly 5 months in – happy new year. It’s been far too long!

Take care.


Using Every Tool in the Box

Reading time ~5 minutes

At one of my former employers it was mandatory for every engineer and manager to be Lean Six Sigma Certified to at least Green Belt level. Most executive managers also needed to be Black Belt certified.

Don't worry, this Ninja is 'armless

(One of my team on my last project is a real black belt – in Aikido – he finds the copying of terms somewhat problematic. I’m not going to argue with him!)

The company was heavily manufacturing-oriented; producing machinery for oil & gas, jet engines, power station systems, white goods, medical equipment and more. You name it, they probably made it somewhere around the world.

The Lean aspect of the certification was a later addition but made it worthwhile – at least for me. However most of the “engineers” I worked with at my main site were purely software engineers. (A few of our other sites I worked with had software, firmware and hardware for the same products under one roof). The software teams didn’t see the value in a (rather rigorous) mandatory certification – and given the way it was taught and introduced I don’t blame them.

A Green Belt certification requires a week of training, book study, completion of an exam and delivery of a full end-to-end process improvement project following one of the Lean Six Sigma improvement cycles (typically DMAIC – Define, Measure, Analyze, Improve & Control). Beyond this, the DMAIC project has to use a broad selection of statistical process control and measurement tools for each of about 15 steps throughout the project.

Certification candidates had to identify a real (but small enough to be achievable) process improvement project on their site and deliver it through this process. A challenge with our software teams is that many felt they were already following continuous improvement practices and that the overweight nature of the certification projects was entirely unsuitable for the work and improvements they were doing.

In many ways they were right.

The problem was that nobody ever explained why the projects needed to be so rigorous and what eventual value they would see. All they were told was “By becoming Lean Six Sigma certified you can talk with staff and managers across the company at any level using a common language and understanding.”

That’s a great ideal – except that their management chain already spoke the language of software.

As a manager at the site, I too had to run a DMAIC project. It took nearly a year to complete as I had to use “borrowed time” on top of all the other projects and initiatives we were all responsible for. Funnily enough it was only after I left that company that I discovered how valuable the experience was.

Picture working in a garage for a high-end specialist motor vehicle company.

You have an array of tools in front of you. As a novice you don’t know how to use anything but a spanner. You barely recognise what some of the tools even do but as an apprentice, you’re trained up, taught the proper way to use each tool and in what situation and context. (You don’t – after all – use a sledgehammer to crack a nut).

This is where my Six Sigma training and certification failed significantly.

You’re required to prove you can use all the tools in the box but nobody actually explains that once you’ve learned how to use them, you only need you to use the right tools at the right time.

As a result, the indoctrination of Six Sigma churned out a high number of people that believed it was mandatory for every process improvement project to follow the same rigorous steps and use all the tools in the box. (I believe this culture has changed significantly now though)

The problem was exacerbated further by introducing a specific Six Sigma career path. Staff could apply for “Black Belt” roles that were a 2 year rotation through various parts of the business. These were amazing roles focused on delivering rigorous process improvement programs all over the wold however they had some dangerous flaws.

The 2 year rotation was actually the time it took to complete a Black Belt certification. Much like the Green Belt, it required completion of projects. In this case, two major process improvements for a business. Plus teaching and facilitating Six Sigma and Lean events.

Most (but not all) staff in Black Belt roles were not actually certified yet. Their personal goal for the 2 years rotation was to attain their certification such that they could move on to  become a “Lean Leader” or similar roles elsewhere.

Imagine the distortions in behaviour you’d see if the primary motivation for the person leading your major process improvement program was to complete 2 projects in 2 years in order to attain certification.

I personally experienced one particularly bad instance toward the end of a project at my site where a team of unqualified Black Belts were parachuted in to “fix” our out of control defect backlog. On the whole, these people were not experts – but they knew how to work the system.

In this particular case; toward the end of the project when it became clear their original quality target was not physically achievable they actually moved the goalposts.

Rather than a defect fix being declared “done” when shipped and accepted by a customer, “done” was redefined to mean “code complete”. They fast-tracked nearly a thousand bug fixes in 6 months through engineering (and our outsourced partner) with no capacity for test and release resulting in significantly more code churn than our customers were willing to tolerate in the same time frame. The development teams couldn’t actually ship the fixes to customers and at the end of the project, the Black Belt team were hailed as heroes for “fixing” the problem and process.

Statistically, according to their measurement system, they had!

The Irony is, the new process they introduced was great. They used a construction and manufacturing management concept known as “Line of Balance” to plan and deliver fixes according to customer “want dates”. If the team had the freedom to ship specific releases to the right customers and customers had the ability to install them it would have worked amazingly well however their analysis stopped within the building without awareness that those customers generally had many years and millions of dollars worth of product customizations meaning they were unable to take “raw” product releases any more.

They missed the critical context of our customers and users.

Anyway… I digress!

It’s worth learning how to use as many tools and techniques as you can. Understanding the powerful combinations available to you across different theories and practices allows you to combine and apply that knowledge in valuable and novel ways. 

But just because you know how to use all those tools, doesn’t mean you need them all the time – choose the right tool and process for the job at hand and remember to keep things as simple as possible.



A Dream of Project Management

Reading time ~3 minutes

A short post today…

A lesson in seeing the wood for the trees

Last week I had a dream about project management – sad, I know!

I was in a room with 3 other people. The first posed a problem…

“You’re starting a new software company and have decided you want to kit out your new 3 storey office properly. For the sake of simplicity, the 2 key tasks that need completing are decorating and wiring. The wiring cannot start until the decorating is complete. You want to be moved in in a month however decorating takes a week per floor and wiring takes 3 days per floor. Can you do it?”

A project manager stepped up and started talking through the problem

“It’s a simple, sequencing and crashing problem.”

“We can do one floor at a time. A week of decorating and then a week of wiring for each floor.”

“By the end of the month, you’ll have 2 floors ready which should be plenty.”

“If you need to run faster, we could contract in some more resources, run each floor in parallel.”

“There’s still drying time to take into account so each cycle of decorating won’t be able to run any quicker but in theory with enough resources and adding in contingency and risk, I think we could commit to being moved in in 3 weeks.”

The “dream me” smugly stepped up and said

“That could work but where are you going to get all the extra people from and can you afford it.”

“Can’t you see, it’s a theory of constraints problem. For the first week, the wiring team are unoccupied. Let’s have them step in and help the decorators. And when that’s done, let’s have the decorating team help with the wiring.”

“We can have one floor ready in much less than 2 weeks and have them all done within 5”

Obviously the “dream me” had failed to notice that electricians and decorators are different skill sets. And still mentally treated them as “fungible resources”. (Nobody would ever think something like that in the software development world right?!)

Then the “Systems Thinker” stepped up and said.

“You’re starting a new software company in the 21st century…”

“…Why the hell do you need an office at all!”

If you’ve not been watching HBO’s “Silicon Valley” comedy series; I thoroughly recommend it. It’s offensive but is a powerful series of caricatured observations of the software industry. Season 3 includes an episode where a promising startup blows nearly all their funding on plush offices, chefs, a foosball table and all the other trendy office quirks.

So the dream was over-simplistic and flawed in many ways but it did at least encourage me to start writing again.

Don’t just focus on the problem or solution immediately in front of you. When somebody presents you with the solution they want, remember to take some time to figure out what they actually need to achieve and discuss their rationale and motivations.

All too often we want to step in, help, achieve, and deliver.

Stop and think about the context, goals, impacts, and relative value/opportunity trade-offs before starting on that next great solution.

Defeating the Misuse of 5 Whys

Reading time ~2 minutes

I’ve tried using 5 whys techniques on many projects and with teams and individuals in a variety of situations.

It’s generally used for root cause analysis but often (I think) misused for other situations. Something about it has always bothered me.

When you see it described in theory it makes so much sense. But most examples are already solved (and I suspect refactored for post-rationalization). When you use 5 whys techniques in practice it never quite hits the mark.

In most cases where I’d have previously considered a 5 whys line of questioning for understanding cause I’ve been inclined to use an Ishikawa (fishbone) diagram instead. This allows us to dig into multiple lines of questioning and link across related areas.

19th July 2013: Output from the retrospective

But this still only works well in understanding problems, not goals and reasoning.

Thanks to a great session from Paul Field at the Cambridge Agile Coaches Camp last year – I’ve finally been given a 5 whys alternative that actually works properly outside the context of examining root causes.

Paul’s own article goes into the full detail on the lines of questioning and the techniques involved so I strongly encourage you to give this a read.

A large part of the improvement here is in replacing the question “why” with directed alternatives.

“Why” in psychotherapy (and some coaching circles) is seen as a dangerous question. From a purely human perspective it can be confrontational and seen as judgmental. A good therapist or coach will instead ask very specific questions based on context  that encourage consideration and introspection in a safe and well-judged manner.

Much like asking a child “Why did you punch little Davey in the face?”, asking “why” – particularly in challenging, negative, or political situations is unlikely to yield a well-reasoned answer. You’ll get a knee-jerk and/or self-justifying response.

Put another way. Repeatedly asking “Why” is like using a sledgehammer to open a jar of candies.  You’ll open the jar but I wouldn’t recommend putting the results in anyone’s mouth – and you’ll still have to go fishing through the damaged results to find anything of real value afterward.

Next time you’re considering 5 whys, try asking “and what will X get from that?” instead.

9 Success Factors for Working with Remote Teams

Reading time ~6 minutes

Some management archaeology from me this morning…

A photo of a sundial overlooking the sea and a coastal area

When I started managing teams and projects for the first time I used to write down my most significant insights and lessons I’d learned in a little Black & Red A5 notebook.

A couple of months ago I pulled it off of the shelf and thumbed through my old notes. They’re almost all still as relevant today as they were over a decade ago.

Hiding among the notes on capacity planning, estimation, reporting, change management, innovation, reward systems, performance management, situational leadership and even a list of personal “observed best practices” was a single half-page of bullet points that simply read:

“How to ensure offshore teams are successful”

Since not long after I started writing publicly I’ve not needed to use those insights.

I have the rare luxury of working with completely co-located teams (even “the business” sits with the team here). However I know many of you wonderful readers still face challenges with offshore or near-shore collaboration & quality. As Dan noted in the comments below, these apply to any globally diverse team, not just “offshore”.

So that these insights aren’t lost to time, I thought I’d share and expand them here.I’m bound to have missed many others and this is my personal view from being UK-based and working with teams all around the world so I have 2 requests for you as readers…

  • What tips and suggestions would you add to this list?
  • If you’re based in an “offshore” type team, please, please, please share your insights from the “other side” – we don’t hear enough here.

1 – Management & Team Mindset

First – stop thinking “offshore”. You’re a global team. Once you start treating your remote staff/suppliers/contractors as being “on your team” relationships start to build.

Pair team members and managers across locations. You’re working on the same goals, behave like it.

Manage all your team in the same way. Arrange 1-1s, feedback sessions, informal catch-ups, full team training. Have off-sites or outings for every site and share the pictures. Better still, do it together.

Your team includes your customers and suppliers too – involve them in your challenges and be rewarded.

2 – Shared Accountability

We often outsource to reduce effort, overhead, cost and risk. As soon as these become significant motivations, you’re already behaving in a flawed way. You’ll find your offshoring or oursourcing isn’t actively owned or managed.

You own the working relationship. It’s up to you to make it work. Find a counterpart on the other side to pair up with and make it successful.

A remote team will never be successful if your only reason for using them is cost. Figure out the unique strengths, talents and value they bring to you. Invest in partners and locations where you have better access to specialist domain knowledge, broader experience or better delivery capabilities.

A great example of this lies in the domain of one of my former employers – power systems. Power systems engineers are rare people at the best of times. In the US in particular, much of the power systems & networks domain knowledge is being lost through retirement. China on the other hand has a huge number of extraordinarily smart engineers in this space.

3 – Quality of Team

Perhaps it’s purely a capacity thing – staff availability in your home location may be a problem.

It’s a lot harder to hire a dozen amazing developers in Cambridge than it is in San Francisco or Mumbai. But given the size of the talent pool in those locations, it’s also a lot easier to hire mediocre or bad team members. Your bar should be set high wherever you are.

Expect the same from your partners or suppliers. If your supplier is competing on cost alone and not capability you’ll eventually fail – period.

4 – Selection Of Work

Don’t just farm out the dull stuff, the maintenance, support, and bug fixing. This is something very few people enjoy taking personal ownership of or pride in. I’ll admit there are exceptions (I love clearing down a massive bug backlog) but most technical people need a balance. All brown-field work wears people down eventually.

5 – Political Structures & Power Dynamics

Career paths and job titles are important.  The “senior” in someone’s title may even be seen as acceptance to push others around or exclude team members from important conversations.

Halt “pecking order” problems early.

Be inclusive, publicly encourage collaboration, and transparent communication from senior managers and give direct private feedback when you smell a problem.

6 – Management Style

Some countries and companies have a more top-down formal style than others. It may be unacceptable to “question your superiors” despite the fact that nobody can be right 100% of the time.

Learn about how things run. Who’s respected, who’s feared, who helps things happen and who gets in the way.

Encourage questioning. Explain that everyone is making rapid decisions all the time. If someone doesn’t understand, is worried or unsure about a decision, make it safe to call out, ask or correct. This capability may take months to build but it’s worth the slog.

As a tech lead in one company I worked at I used to run a game called “Captain, you’re wrong”. We made calling out errors fun and engaging rather than difficult and negative.

Recognise that career paths, job titles and management styles differ from country to country.

7 – Respect cultural and language differences

I had mentee that would say “I have a doubt” when they had a question or needed support. That’s quite an interesting translation. “Doubt” in English reflects personal uncertainty. Be supportive, take time to explain things clearly and most of all encourage questions and discussion.

Work ethic may varies from place to place and person to person but sometimes you just don’t see what’s going on.

I had a team member in Hyderabad who consistently outperformed everyone else globally. She was truly amazing at everything but more than that she worked relentlessly.

I’d come into work in the morning at 8 and she’d have been in the office for 4 hours. I’d leave at 6 or 7 in the evening and she’d still be working. The irony was that even when working sensible hours she was still smarter, more productive and delivered higher quality output than a lot of our team. The excess hours weren’t healthy.

Having spotted the excess working I’d check daily around 4/5 pm and if she was still Online I’d call her up and just and encourage her to go home and enjoy her evening. (Her home life was great too so I’m pretty sure she wasn’t avoiding going home).

8 – Spend Time Together

Seek ways to bring your whole team together for a day, a week, a month or even longer. If this really isn’t possible, how can you do the same for individuals and managers instead?

Spending time together helps you understand the working environment, the personal subtleties and nuances and communication styles. After you’ve spent quality time face to face with someone, those offline interactions become much easier to understand.

It works both ways. Spend some time (at least a couple of weeks) in the remote environment yourself. Go see what working life’s like over there. I promise you’ll learn something every day you’re out there.

9 – Re-learn how to communicate

A lot of communication on a co-located team happens by osmosis.

If some of your team are remote they won’t get that benefit. Invest in tools like slack and github that support asynchronous collaboration but don’t just use them for “work” – dial up the chatter and small talk so that everyone can feel part of a human team.