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

Share

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

Lots!

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

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

Build & Cycle Time

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

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

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

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

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

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

Agile Staff Development

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

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

Project Manager Skills Map

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

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

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

 Rebuilding my “Developer Empathy”

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

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

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

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

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

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

Suboptimising Around Data

Share

I originally wrote this article back in about 2009/2010 whilst working at a large corporation with a very strong measurement culture.

just some dataAs more teams and companies are adopting lean concepts and with the strong influence of the Lean Startup movement (which to reduce confusion is not the same as lean), this post feels relevant to finally publish publicly…

“Data is of course important in manufacturing, but I place the greatest emphasis on facts.” – Taiichi Ohno

There’s a great lean principle known as “Genchi Genbutsu” – “actual place, actual thing” Generally we interpret this as: “Go and See at the source”

When this critical pillar of lean thinking is eroded by a proxy we open ourselves to some painful problems.

Where organizations become too measurement focused, we risk our proxy for Genchi Genbutsu becoming data.

Lean and agile processes both rely on data but these are indicators only. Particularly in agile, there is a strong emphasis on data being used by the team for internal diagnostics – in fact very little agile material talks about data support for external management and there are good reasons for this.

Even where managers are fully aware that data are not the whole story, external or imposed measurement drives strange behaviors.

Talk to any individual or team that is measured on something that managers at one time or another thought was “reasonable” and chances are there will be a range of emotions from bemusement or cynicism to fear. All these responses will drive negative alterations in behavior. Occasionally there are good measures but they’re pretty rare

You’ll find individuals and teams that are working in the “expected” way will be absolutely fine. But their behavior will now be constrained by the metrics and their capacity to improve will be limited.

Those that are aware of their constraints (and are often limited in what they can actually influence to solve their problems) will at best sub-optimize around their own goals and at worst “game” the system in order to preserve themselves. This is a natural self-preservation response.

I’ve seen the most extreme example of this using game theory in simulated product management (in a session run by Rich Mironov back in 2009).

A team of 4 product managers were each given a personal $1M sales target, a set of delivery resources and a product. Performance against their target was measured on a quarterly basis. In the example, the game was deliberately rigged. It was impossible for all product managers to meet their personal targets with the limited resources they were given. However It was possible to achieve well above the total $4m target if product managers collaborated and in some cases were actually willing to sacrifice their own products, releases and resources in order to fund cycles on better-performing products.

Data may also only tell you how tools are being used. If a team is constantly inspecting and adapting, I would expect their tool usage to change. It may then not reflect expectations or worse, they may not be able to adapt for fear of damaging “the numbers”.

Here’s a great example of this from (of all places) a hair Salon… http://lssacademy.com/2007/08/05/bad-metrics-in-a-hair-salon/

For a closer to home example try this experiment…

If you’re not already doing so, start measuring story cycle time (from commencement of work to acceptance and ideally delivery).

Now try the following:

  1. Measure cycle times without giving feedback to the team. What are you observing in the data? What can you infer from this? What can’t you see?
  2. Continue measuring but start reporting the numbers to the team and discussing observations. Ask the team what they’re observing, what they can infer and what can’t they see. What would they change?
  3. Ask your teams if they’re willing to report their data to “management”. What responses do you get?
  4. If the teams are willing. Start reporting the data to management. Ask them what they’re observing and what they can infer? What Can’t they see? What would they change?
  5. Consider the level of trust in your organization. How would the experiment above change behavior if trust was significantly higher or lower than its current level?

Food for thought.

Iteration Planning With The Captain

Share

Back in 2012 I ran a small workshop at SyncNorwich on iteration planning. It wasn’t one of my best but went down well with the dozen or so participants I had.

During the workshop I asked participants to take a “textbook example” of a sprint planning agenda and adapt it to their own needs. I’ve uploaded the planning worksheet for anyone who fancies experimenting with this for themselves.

If you’re interested, here’s the presentation itself:

Happy new year!

 

A Year of Whiteboard Evolution

Share

Back in December last year I started supporting Red Gate’s .NET Developer Tools Division. As of this month, we’ve restructured the company and from next week, the old division will be no more (although the team are still in place in their new home).

When I joined the team things were going OK but they had the potential to be so much more so I paired up with Dom their project manager and we set to work.

The ANTS Performance Profiler 8.0 project was well under way already and the team had a basic Scrum-like process in place (without retrospectives), a simple whiteboard and a wall for sharing the “big picture”.

I spent the first week on the team simply getting to know everyone, how things worked and observing the board, the standups and the team activities.

We learned some time ago here at Red Gate that when you ask a team to talk you through their whiteboard, they tell the story of their overall process and how it works. Our whiteboards capture a huge amount about what we do and how we do it.

I attempted to document and capture at least some key parts of the journey we’ve have over the year in which we released over a dozen large product updates across our whole suite of tools. This post is picture heavy with quite limited narrative but I hope you’ll enjoy the process voyeurism :) If there’s any specifics you have questions about, please ask and I’ll expand.

Next time, I think I’ll get a fixed camera and take daily photos!

The end result? Multiple releases of all 5 of our .NET tools including a startup and quality overhaul for our 2 most popular products, support for a bunch of new database platforms, full VS2013 support (before VS2013 was publicly released), Windows 8 and 8.1 compatibility and a huge boost for the morale of the team.  See for yourself if you’re interested!

Of course this is just one aspect of what I’ve been up to. You might notice the time between photos over the summer grew a little. See my last post for more insights into what happens at Red Gate Towers.

Busy Times – Personal Development, Organizational Restructuring and Big Rocks

Share

I’ve been quiet on here for a few weeks as I’ve been head-down on some pretty major work at Red Gate and publishing what I and the team have been up to on their freshly launched dev.red-gate.com mini-site.

Here’s a roundup of the highlights:

“Slack” – Exploring how we approach “slack time”. Ensuring slack is available to the right people at the right time and trying to keep it guilt-free.

A Manifesto (of sorts) for personal development – what we expect from each other in developing ourselves and our careers. The outcome of 2 months of Genchi Genbutsu (go see at the source) – asking some really direction questions face to face (individually) with every single member of our development teams.

Top Tips for personal development – 12 Tips on personal development from Red Gate’s development team (plus another 12 linked from this one). These are the tips we use as part of our new personal development plans but are equally useful as prompts to simply “get out and do something”.

Skills Maps - An overview of the skills maps we’re developing at Red Gate for our development team roles (it turns out what we’re trying is pretty unique and developed a bit of a buzz.

Personal Development Plans – A distillation of the “Stop trying to fix your weaknesses” articles posted on here over the last couple of months. We’re still rolling these out but the trials from a dozen managers and staff so far have been resoundingly positive.

Fresh off the press yesterday; Organizational Restructuring – An Insider View – Putting Convergence & Divergence into practice. How Red Gate are performing a complete organizational restructuring to their teams without the usual cloak and dagger HR hell.

Finally, Johanna Hunt and I have paired up again on our “Cracking Big Rocks” cards and workshop. After much editing, re-editing and review we published the second edition of the card deck at the end of September and took them out for a first run at Agile Cambridge. The revised deck includes a few new patterns, rewording of many of the old ones, some basic instructions and some lovely artwork on a few of the cards from our good friend Paul Stapleton.

Enjoy the Friday reading.