Still Alive!

Share

First of all, I’m flat-out at work right now on recruitment and running a challenging project so here’s a plug for some jobs…

We’re looking for 3 amazing Agile PMs here at Red Gate. If you think you’ve got what we need and fancy working with me, please dive in and apply.

[edit] – actually we’re hiring for more than a dozen different roles you might expect in a software company! – Take a look at the rest too.

Second. I’m currently supporting part of the SQL Source Control development team here on a rather challenging technology refresh project. We’re planning to ship an Alpha soon to validate our technology decisions and them press ahead with completion and new features. I can’t say much more about this at the moment but despite being relatively small by most company standards, it’s one of the trickiest projects I’ve ever inherited. Once we’re successful, I hope to write more.

Finally – back to the title…

Forgive the Portal reference but for the last few months I’ve been using my spare time coding a game.

If you’re of a certain age (like me), you may fondly remember hours of bashing away trying to solve puzzles and guess verbs in black and white (or green screen) dungeon/text adventure games.Minimum viable text adventure game screen

I grew up coding on a BBC micro and developed an early love for interactive fiction. It’s now a pretty niche area with some amazing games.

Whenever I want to learn something new, I need a goal – something concrete. So I decided to write my own but using slightly more modern technology. If you’re interested in why, see my last post.

Progress has gone really well and I think the results so far have some promise. There’s a few unique aspects of the game in comparison to the more old-fashioned equivalents. Essentially, the games characters and scoring are somewhat more dynamic and based much more on the actions of you as a player. I won’t spoil it but if you have the patience, give it a shot at: http://mvta.herokuapp.com/

Whilst not “finished”, it is live and that’s an achievement in itself.

I reconnected my developer empathy circuit, thoroughly enjoyed going back to coding and managed to learn some new skills on the way.

A few nerdy highlights…

  • I’m really impressed with Heroku as a hosting platform. I managed to go form zero knowledge to live and running in under 2 hours – including restructuring the codebase and packaging in order to support heroku deployment.
  • I had to get to grips with NoSQL  much sooner than expected. The original saved game data was filesystem-based but Heroku offers no filesystem support so games are now saved in a hosted Redis data store. This also gave me the benefit of painfully relearning use of binary data streams and debugging third-party libraries (developing on Windows vs production on Linux). It turned out that by default, the nodeJS Redis library is somewhat buggy on Windows as it drops back to a javascript parser. On Linux it uses a C library.
  • I’ve come to love Github for source control and got to grips with a modern IDE (Visual Studio) having last used Eclipse back in around 2007!
  • I’ve learned to value real user testing and usage reporting. A large part of the game usability came from observing the attempted and failed actions of users playing the game.
  • I’ve really boosted my nodeJS and javascript skills although the JS itself is still largely poor OO rather than dynamic.
  • I still prefer writing business logic over coding the “plumbing” but did occasionally have to drop back to some old-school computer-sciency work to achieve what I wanted.

Most importantly, whilst it’s a well-tested and working game and engine, I built a nasty legacy codebase that forces me to resort to writing tests and reworking/refactoring whenever I want to add something new and facing the pain of missing tests and regressions as I go.

I’ll continue updating the content over time but please dive in, have a play and waste a few hours.

Oh… and post comments here if you need “guess the verb” type hints or clues!

Cheers for reading!

Simon

 

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.