Ownership: Requirements

One of the key indicators of a successful tech company is that the development team have a lot of ownership. It's something that Scrum requires, by the way - but as I've noted previously the state of agile development practice across the industry isn't great.

Ownership is a difficult idea, because a lot of people assume it means "total control". In the context of software, it really doesn't. Ownership here is about the ability to make and carry out decisions without interference, combined with the responsibility to consider and listen to those affected before doing so. At work, I refer to it as a courage/trust relationship: courage to do the right thing, trust from others that you will do that right thing.

Here are some things development teams should own, but in my experience often don't:

• The architecture and technology stack of their products.
• The ability to proactively address technical debt and legacy code.
• The stories, epics and priority order thereof of the product backlog.

The last one is often the most problematic, partly because the need for it isn't as self-evident, and partly because of that ownership/control confusion. The problem with that is the requirements for a piece of software are inherently a part of the creation process. When development teams don't own them, you end up with a vast schism - in which the developers aren't getting the requirements they need to build the software, while the team in charge of requirements don't understand what they're being asked to provide and have no idea why development is always so angry. Territorial lines start being drawn, and then it gets petty. (Refusing to change a spelling mistake because, "it's not their spelling mistake to notice" petty. It's not pleasant to watch.)

I think this is because people misunderstand what requirements are. The word sounds final, immutably cast in stone. And that's an entirely wrong assumption - requirements in software are part of a two-way dialogue between developers and stakeholders. Think of them as like a blueprint for a house. You wouldn't hand your architect one you've drawn in crayon yourself; you'd talk about the things you want, then the architect would sketch a blueprint for approval. If you'd asked for something impractical or inappropriate, like turrets and an archery tower on a two-bedroom suburban semi, then your architect as a designated expert would probably start a discussion about having something more sensible. Maybe if the initial blueprint was too far off you'd create another.

Development is pretty much the same. Your housing architect owns the blueprints because he or she knows what a blueprint needs to contain through years of experience making them. Your developers own the requirements because they know what they need to contain. It's not a power, but a responsibility - the development team is ensuring the builders have everything they need when they arrive on site. If they don't have enough ownership to delay picking up the story until they find out what happens when the user clicks the "foo" button, then things will end badly - just like trying to put in the second-story turrets before the foundation has been laid.

The other important thing is that the developers know about what needs to happen under the surface. Again, it's responsibility - anyone can add a bathroom to a floorplan, but it takes an expert to work out what impact that has on the plumbing and how to integrate that change. This is why I use that word "ownership" rather than "control", and also why the housing analogy is so appropriate. You wouldn't expect an architect to veto a second bathroom outright, but you would expect them to tell you if it's going to add cost or compromise the rest of your house. And the development team should be the same. Collaborating to create an accurate, honest plan of the software that is to be built.