Lean and Agile - what does that actually mean in practice at DrDoctor?

At DrDoctor there is a very strong belief that the business should be Lean (note the capital 'L'), so we analyse data on how our services are used in order to guide product development.  An important aspect of that is that we need to get features out there in order to see how they're used, which fits neatly with a Scrum-based, Agile approach.  We do favour working software over comprehensive documentation and we aim to deliver that working software every sprint (i.e. every two weeks).  Worse than that, following lean principles, we don't just value responding to change over following a plan we acknowledging that a core strength is our ability to change our plans.  Yes there is a vision, but no, I don't pretend to know for certain what I'll be working on in two months' time.

What does this mean in practice?  At a very high level, it means that we need to be able to release features easily.  Or put another way, having a 'release sprint' (which I've seen in lots of places) means we've failed.  We haven't always succeeded in this, but we're getting there and we are now at the stage where we have decent CI and automated deployment, we can ...

• Push changes to our central code repository
• Which triggers a build on our build server
• Which runs our test suite (unit tests, integration tests that exercise the DB and bigger 'Spec' tests that lean on even more infrastructure)
• We're notified if the build passes or fails
• With 5 button clicks we can deploy the build to our 'smoke test' environment where we can do a full end-to-end test - our product owners get to run through the feature they've asked for
• 5 more button clicks and we've deployed to production

To achieve all of this, we use Git, BitBucket, TeamCity, NUnit, SpecFlow, HipChat and Octopus Deploy and I'll write a post on some of the technical details of how that's set up.

However, the main point isn't about the tools, it's about the mindset.  Lots of companies talk about Lean and Agile but don't deliver (if you've ever sat through a 30 minute "stand-up", you know what I'm talking about), but at DrDoctor the value of delivering software rapidly is understood, which translates into investing time into making delivery easy.  There is a lot more to do, but the whole company agrees that we don't say a story is delivered unless the code is running somewhere.