Decluttered Software Development
I knew Agile was in trouble when it became a proper noun. As an adjective, agile meant a way of approaching problems, a mindset you could apply to something else like planning or programming. As a noun, it transformed into a thing. As a proper noun, it became a brand and a product.
And as we know in software, the way to keep making money off a product year on year is to keep adding more features.
Enough virtual ink has been spilled on this subject that another diatribe would be redundant. But it did set me thinking: what’s the simplest advice I could give to somebody who found themselves leading a development team, faced with a complex landscape that demands you hire an Agile Coach to take you to some Agile Conference to teach you those Agile Tools? Last week, after the office Dungeons and Dragons session and possibly a few too many beers, I came up with this.
Provide goals, not too big, to 2–4 developers.
(The call-out to Michael Pollan’s 2009 nutritional advice—Eat food. Not too much. Mostly plants—is entirely deliberate.)
There, that’s my Methodology, the culmination of twenty years coding, team-leading, architecting and mentoring on projects ranging from so-catastrophic-we-got-sued, to so-successful-I-can-afford-a-house-or-maybe-at-least-a-lot-of-avocado-toast.
Go forth and be productive.
Provide Goals
A goal describes the destination, not the journey. When we load into a game of Overwatch, our goal is to win. How are we going to do that? Well, we know we have to capture the payload then push it to the other side of the map. How are we going to do that? We’re not sure yet. We don’t know what comp our opponents are going to run or what tactics they’ll use. We will use our knowledge of and experience in the game to make those decisions as we go.
A goal is not a task. Being able to sign up a new user is a goal. Creating the database schema for users is not. Would a reasonably non-technical product manager tick it off as something that’s been “finished”? If not, it’s probably not a goal.
A goal can be abstract, if it’s time-boxed. “Spend a week reducing outstanding bugs/making the UI more consistent/deciding if we should switch to Purescript” are all goals.
A common impulse is to pre-split goals into engineering tasks and then apportion those tasks instead. This is especially common when teams feel obliged to perform meticulous accounting, splitting every deliverable into fine-enough-grained pieces that they feel confident committing to some precise, but somehow at the same time utterly arbitrary number of story points.
The first problem with this is that it wastes time. I’ve seen teams spend as much as half a day a week in meetings with euphemistic names like “estimation”, “grooming” and “elaboration” when they all should be called “pre-work”. The work of nutting out precise acceptance criteria, deciding on implementation approaches and dividing the goal into pieces of work can be done just as well, taking up fewer people’s time, once the goal has been accepted by the specific developers committed to delivering it.
The second, and more important problem is that it dilutes responsibility. A truism that has followed me throughout my career is that if something is everyone’s responsibility, it’s nobody’s responsibility. If somebody takes ownership of a complete goal, they feel responsible for delivering it as best they can, even the bits they discover on the way that they didn’t know about when they took responsibility for it.
When you split a goal into tasks, you are redefining “achieve this goal” as “complete this set of tasks”. Developers own their individual tasks, nobody owns the gaps between them, and anything that shows up after that initial split inevitably floats all the way back up into the project-wide planning process for expensive renegotiation and rescheduling.
Often these things that fall between the gaps won’t be noticed until long after the feature is “delivered”, because nobody at the developer level is thinking about the problem as a whole any more, just about the component parts it was split into during some meeting.
Not too big
As human beings writing software, we need to deliver meaningful results at a certain cadence, and suffer if we delay the feedback we would get from doing so. As worker bees, we have a responsibility to give those providing the honey evidence of our progress, and regular feedback on how we are contributing to the goals of the hive.
Your mileage may vary, but for me the sweet spot is one to two weeks work. Bigger than two weeks, and you can usually find a meaningful, smaller goal on the way there. Smaller than one week, and it’s usually not a goal. There are exceptions in both directions, but there are exceptions to every rule. We spent millions of years evolving cerebra, we might as well use them sometimes.
Commercial developers are ultimately responsible to businesses that like to plan in quarters, half- or even full years. By design, “goals, not too big” naturally divides projects into units of work and estimation that are useful all the way up to providing useful estimates for business-level planning, and all the way down to working out how much a team thinks it can get done in the next week.
To 2–4 developers
Never allow anyone to take sole responsibility for any meaningful deliverable.
Developers working alone cut corners they wouldn’t cut, miss important details they wouldn’t miss, and repeatedly check websites they wouldn’t check if there was just one other person working with them on the same problem. And once a goal is reached, you want to avoid there being only one person on the team who understands how it was achieved, or can explain the trade-offs that were made to get there.
With our lower bound set at two, the upper bound is capped by the limits of self-organization. Anyone who has worked in a startup or greenfields project remembers when the team was so small that you didn’t need a team lead, dev manager, or more than the bare minimum of ad-hoc, back-of-the-envelope process. This kind of spontaneous organization is what we want in our short-lived, goal-oriented teams.
My ideal number is two. Two developers can bounce ideas off each other, check each other’s work, and keep each other honest. They can decide between themselves whether they would be better off pairing on some problem, or working on it separately. When in doubt, go with two.
At a stretch, if you need more brains on a single goal and are willing to accept some of that “mythical man month” overhead, you might be able to stretch to groups of as many as five. I’ve gone with four partly to err on the side of caution, and partly to ensure that when they split the work internally, they will still cleanly divide into pairs.
What about the rest?
The team I was on that most successfully stuck to Extreme Programming was the one that didn’t adopt Extreme Programming. We were a small team that felt personally responsible for the quality of the complete features we were asked to deliver, and through experience decided amongst ourselves that daily stand-ups, pairing, pervasive testing, short iterations, continuous integration, “do the simplest thing that could possibly work” and (most of) that other stuff were the ways that best helped us get our jobs done.
Small, self-organising teams given responsibility for reaching complete goals will naturally seek out better ways to reach those goals, share them with their colleagues, and take what they learned when they work on their next goal. Experienced developers can help by example, demonstrating the value of what has worked for them in the past, not by appealing to authority and imposing practices that will only ever be resented through the simple fact of their imposition.
