None of it really matters until you’ve started creating your software
Should we start with Scrum or Kanban? Is it better to have one, two, or four week sprint iterations? Iterations or sprints? Should we use Jira, Trello, VersionOne, or Monday.com? Should we describe work in user stories or jobs-to-be-done? Our tech debt is out of control — will a hardening sprint work? Can we use velocity to measure improvement?
I’ve been asked (or have asked myself) some of these, and other, questions before. I’m sure you’ve encountered exactly the same stories time and again (usually on LinkedIn!) and I’m embarrassed to say it took me a long time to work out that none of that really matters.
I say none of it matters, it does matter, but not really as much as you think and certainly not before you’ve even started creating any software.
The trouble with those kinds of questions is they imply there’s a way to create software that the answers to those questions will help with. They imply that if we could just get our velocity higher, or we could just measure the number of stories per iteration, or we could just understand the user of the system better we’d be able to create a great product or be able to get ourselves out of technical debt or be able to give our stakeholders confidence that we can deliver.
That’s not really true. Those answers won’t help.
You see, all those questions, and others like it, focus on the framework. They focus on the tools of the trade. Answers to these questions seem attractive because they have actual answers that other people can help with. Other people (or, even your previous self) can say “this worked” or “I’ve had a great experience with that”.
Answers to these questions seem attractive, because they have actual answers that other people can help with.
“If I implement these answers,” you think. “I’ll be creating great software” and if you don’t create great software, then you imagine you’re probably not doing Scrum right (or kanban, or user stories or whatever),
Some of the answers to the questions will be useful at some point. They’re just not useful now.
Those questions and their answers focus on the “how to do”. They completely miss the “what to do”.
“But we know what to do!”
You don’t *know*. Not yet anyway. You think you do, but you don’t *really know*.
There are really only two questions you need to answer right now; what do our users need? You can make an educated guess about what your users want. You must have some idea of what they want — you work for, or started a company with a goal in mind — begin there.
So, the really real question is how do we know we’re successfully satisfying that need? and you shouldn’t even pick up a pen until you’ve worked that out (OK, you can pick up a pen to help you work that out).
How will you know when your software is successfully satisfying your customer needs?. There’s some matter of scale here, at some point you can change “software” to “feature”, but if you’ve not got a success metric for your software, having one for features is pointless.
When you’ve had a stab at answering these two questions, then you can start building software. It doesn’t matter if it’s Scrum, kanban, user stories, Jira or cupcakes. Just pick one out of a hat and start building software. If you’re already using a framework and wondering whether you should change to Scrum, or kanban, or start estimating or having longer iterations to get yourself out of a hole, then don’t do anything. Keep doing what you’re doing, but expend the effort you’d spend on frameworks on building software your customer needs instead.
You see, you’ll spend an inordinate amount of time and energy discussing, trying to decide, then setting up, then tweaking an “agile” framework. Time, effort (and money) that you would absolutely be better off spending on making your software satisfy your user’s needs. It makes me miserable to think of all the time and effort that goes into deciding on, or talking about, or rigorously following a framework. Time and effort that would be waaaaaaay better spent on thinking about the users.
You’ll spend an inordinate amount of time and energy discussing, trying to decide, then setting up, then tweaking an “agile” framework. Time, effort (and money) that you would absolutely be better off spending on making your software satisfy your user’s needs.
“But how do we improve our process?”
Incrementally. Whatever you’ve picked first, or however you were doing things in the first place, just incrementally fix that. No one in the entire world is “doing scrum” how Scrum was designed to be done. It’s impossible. Every company, every team, every employee of a piece of software, situation, and delivery infrastructure is different. Just pick one of your problems and fix that. Then pick the next one and fix that. You don’t replace your old heating system by tearing down the house and building a chateaux.
So, quit worrying about whether your framework is right, or whether you’d be more successful using kanban instead of Scrum, or #noEstimates instead of story points and start worrying about whether you’re satisfying your users’ needs.
That way, you’ll be way more successful.
