Lean Agile Scotland 2012 Recap and Slides

Speaking at Lean Agile Scotland 2012 was a great experience.  I particularly enjoyed the speakers dinner and meeting some of the guys from the Glasgow ruby user group who volunteered to help run the conference.

I got asked (and I promised) to upload the slides, and I’m sorry it took so long!  These slides may not be the best as a standalone, but they should convey the main gist.

Lean_Agile_Scotland_Presentation.pdf

Cynical Optimism: Technical and Business Planning

I thought Rand Fishkin’s recent blog post on “Cynical Optimism” was a nice read.  He talks about how while there are plenty of things to be cynical about when it comes to humanity and our tedencies towards negative things, there is plenty to be optimistic about with regards to our progress as a whole.  The phrase “Cynical Optimism” is one that I really like to use when describing how to attack business plans, budgets, technical roadmaps, or other kinds of planning.

First, Be Optimistic

When setting goals, you definitely want to be an optimist.  Aim high, don’t limit yourself, and always strive for accomplishments that are meaningful and aligned with your values.  This is the classic “CEO” way of looking at the world and deciding where to go – strategy, vision, and confidence are huge assets here.  When goal setting, make sure you show your work!  Define goals in the form of “We’d like to do X because of A, B, and C”.  This provides important context and you’ll find that there are often other cheaper better routes that could be had which your haven’t considered.

Second, Become a Pessimist

Once you’d laid out your goals, make sure you switch hats and cast an incredibly cynical eye over your plans.  You want to identify everything that can, will, or should go wrong.  This is the perspective that a “COO” or “CTO” would take, as they’re the ones seated more firmly in the trenches.  The important thing here is to engage your team and let them know it’s OK to second guess goals in the context of determining how they’ll be achieved.  By critically assesing what it will take to arrive at your destination, you’re ensuring you don’t run off the rails enroute.

Now You’ve Got a Plan

Forcing yourself to wear both hats is hard – it’s often difficult to pull yourself across the chasm if you’re naturally predisposed to one outlook or the other, but if provides the following:

  1. Builds a culture of intellectual honesty.  It’s always easier in a team environment to just go along with the flow and feel like you don’t have any skin in the game.  If your team feels they can object or hone objectives, they’ll perform better.
  2. It can reduce the risk of making major mistakes.  By critically attacking your objectives you’ll anticipate problems and avoid major pitfalls that could have been forseen.  You’ll never know what you don’t know, but often teams drift into problem areas they could have avoided.
  3. In dysfunctional organisations, it’s amazing how almost everyone involved will know (and be able to point out good reasons) how goals won’t be achieved, well ahead of time.  You’ll prevent this kind of “death by politics” syndrome which affects a lot of companies.
  4. Bottom up planning is always the best way to meet top down objectives.  In other words, the high level goals can be set by the product owner, CEO, or visionary, but they’re on the worst vantage point to actually see how to go about achieving these things.  A tip on how to encourage realistic plans – don’t confer time estimates of any kind when setting strategic goals.  Just say “We’d like to do X” and see what comes back!

Lastly, Remain Engaged

Plans sometimes need to change.  You’ll need to react to new things.  As your team engages with the problem the goal-owner will need to remain intimately engaged with the team.  Fine tuning your goals is a necessary part of any meaningful project or endeavor – not fine tuning will just ensure failure.

Simplify Everything

There’s a lot of abstract advice about employing simplicity when building great products or writing great code.  However, life and products (particularly in the Enterprise software market, where I’ve spent most of my career) are complicated.  It’s often hard to gleen concrete examples of what these maxims are trying to communicate.

The other day I was in a pub waiting for a lunch meeting to start and I got to witness the week’s beer delivery.  This is a fairly hard problem to solve efficiently if you’re in a city where parking is difficult (or nonexistent), buildings were constructed hundreds of years before accessibility laws (meaning stairs and tight doorways), kegs are very heavy (over 200 pounds when full), and where a lot of beer is consumed requiring frequent deliveries.

If you or I were designing a solution to this problem, we might come up with this solution:

  • 1 truck
  • 2 employees (1 driver, 1 loader/unloader)
  • 1 automatic lift at the rear or on the side of the truck
  • 1 appliance dolly that can move up or down stairs

We’d be pretty happy with that.  Not the worst solution in the world.  It’s possible we could reduce to one employee but the automatic lift will take enough time setting up and lifting that we’ll probably exceed our very short “stop with flashers on” window.  We’d therefore need to park and have someone stay with the truck, or make several “fly byes” to stay within the unloading time limit.  This will really limit how many delivers we could make in a day, possibly requiring a lot of delivery crews.

Here’s how they actually do it:

  • 1 truck
  • 1 driver / unloader
  • 1 airbag

The driver pulls up, parks the truck right outside the entrance of the pub with the flashers on, whips out his airbag from the passenger seat, rolls up the side of the truck, pulls off the keg and lets it fall right on the airbag.  He then rolls it into the pub (for those with cellar keg storage, they have their own airbag) and after about 20 kegs and less than 5 minutes, he’s out of there.

A lot less cost, a lot faster, and no expensive equipment.  

Simple.

Img_0871

I’m Speaking in Edinburgh on Agile Teams

In September I’m giving a talk at Lean Agile Scotland titled “People, Your Most Agile Ingredient”.

Those who follow MotoGP motorcylce racing will probably be familiar with Chief Engineer Jeremy Burgess.  He has worked with three different world champions including the greatest motorcycle rider in the history of the sport, Valentino Rossi.  His accomplishments as a mechanic are legendary, but he’s also famous for his widely repeated “80/20” theory (not to be confused with Pareto’s Principle) of motorcycle racing.

Motorcycle racing is 80% rider and 20% machine.

– Jeremy Burgess

2005_0408_jeremy_burgessMotogp_rossi_300

Many scoffed at this statement and in the early 2000s it was widely believed within Honda management that even an average rider could win on their machine, the best bike in the field.  Having won 3 straight championships for Honda, Rossi and Burgess both moved to Yamaha, the the very worst bike in the field, where they promptly rattled off two straight championships.

The main thrust of my talk will be exploring the idea that like mortorcyle racing, successful software development and growing a successful technology company is at least 80 percent dependant on your team.

My talk will discuss how to manage teams, grow them, invest in them, support them, and profit with them.  How to determine if you have a good team, fix a bad team, and give you a glimpse into the hallmarks of great teams.

If you’re in Scotland or are interested in attending, you can use the discount code “LASDN12JPP” to register and you’ll receive 10% off (expires on 6th of September).  Hope to see you there!