Agile and Lean and DevOps, oh my!
monica914 060000WAY8 Comments (2) Visits (15664)
Themes are percolating in my brain spurred by everything from my Twitter feed, to LinkedIn to hallway conversations with colleagues. There’s a lot of angst about responding to market changes and customer expectations. The techniques we all talk about: Lean, Agile, Continuous Delivery, DevOps, Design Thinking have everyone wondering how to reconcile all of these themes into an action plan to address those expectations.
I keep thinking it doesn’t have to be that complicated. There’s no secret formula that if only someone would explain it, everything would be clear. Because they are all about one thing: making users happy by giving them what they want.
We’ve always wanted to please our users, but when software was hard to build and delivery meant the user had to do an installation, software was naturally not delivered that often. We would talk to specific users, collect requirements, do our best to fix the right defects through hours of triage (i.e. the ones they cared about) and shipped about once a year. Releases were named for the year of delivery. Sometimes even that slipped.
Cloud technology has completely changed the picture with the ability to host software. Does anyone know the version of Gmail or Facebook they are using? Or even know where to find that information?
It’s not just about making revenue through hosting or saving your users from installing and knowing about versions. Equally important is that it has provided an opportunity to really know what customers want. You can learn from all your users, not just the ones willing to do usability tests, participate in betas or answer surveys.
DevOps is the opportunity to get to know your user. All your users. Say goodbye to the squeaky wheel.
The automated pipeline that is the “plumbing” of continuous delivery means delivering (all the way to Ops) in small batches. In terms of a production line (if you haven’t read The Phoenix Project, you might want to) this means less work-in-progress and higher throughput. In turn, this is the engine of Hypothesis Driven Development where you tackle your areas of biggest risk first, craft an experiment and measure the signal through instrumenting the production Ops environment. Voilà – that’s Lean!
My thinking is that it’s all a continuum and each of the techniques listed have a set of ideas and practices that you can pick from, while not exactly à la carte, almost. As long as the focus is on learning from the user as early as possible (fail fast and cheap) that you’re on the right track, well then use a screwdriver when that’s what you need and hammer when you’re hitting a nail. Not all tools are the same and a good toolkit has a selection. Every task is easier with the right tool, so learn a bit about all of the techniques so you have what you need to succeed in delighting your users. Keep the eye on the ball and rejoice in the opportunity to stop guessing what will sell and delivering software that succeeds because users love it.