The quote, “it’s easy enough if you can figure out what to build” comes out of an on-going discussion about project management that I’ve been having with my wife. Her background is in biomedical engineering and she’s always been a little envious that (as she sees it) software is such a certainty.
In biology and medicine, you might have an idea for something you’d like to build but you have practically *zero* guarantee that that thing can even be done. It might work in a petri dish but not scale up. It might work in mice but not in humans. More likely you just can’t get it to work at all. Considering her PhD research project, she spent literally years trying to get cells to live and grow on certain types of material. For all those years, she had no idea if it would ever work. For many of those years, it wasn’t even close to working.
It’s hard to make biological systems do what you want.
Her view on software is that the majority problems we tackle are entirely do-able. If we’re tasked with building a new HR management system or a web application to manage tax returns or an app to tell you when the next bus is coming, there’s no doubt that it can be described using our programming language of choice. Sure, there might be scalability problems and bugs but it’s rare to be asked to do something and immediately think “that’s impossible.” It’s usually more like “that’s going to be a lot of work.”
It’s an interesting perspective on software and it’s nagged at me for years (like I said, this has been an on-going conversation). She’s basically right. Our technical problems are far, far easier than the problems of biology and medicine.
So, why are so many of our software development projects such unrelenting disasters?
I think it has to do with where the bulk of the complexity is. When I think about troubled software projects that I’ve seen, you frequently see that requirements either 1) shift wildly or 2) are piled up to the sky and beyond. If the requirements keep shifting, the team doesn’t have a clear mission (or has contradictory objectives) and it’s tough to actually deliver anything. If they’re piled up to the sky, you’ve got so much to do that you’ll never be done and it’s tough to get a coherent picture of what you’re really trying to accomplish.
When this dysfunction is in full effect, you’ll usually hear teams saying something like “just tell me what you want me to build and I’ll build it.”
In software, the real complexity is figuring out what to build. Comparing this to my wife’s view that building software is easy, she’s correct if you only consider the “coding the software” activity. Biology and medicine’s big problem is technical -- making it actually work -- while software development’s toughest issue is a people problem -- creating consensus and deciding what to do.
If you want a really high-performance Scrum team, you need to give the team a clear goal and then get out of the way to let them go do it. Defining that clear goal is ultimately the responsibility of the Product Owner. Remember, the team can only have one Product Owner. They need that single person to make the tough calls and decide “build this thing vs. that thing” or to decide the scope of that controversial PBI. The Product Owner is tasked with optimizing the business value of the product and distilling the conflicting views, priorities, and opinions of the vast sea of stakeholders.
In short, the Product Owner needs to decide what to do. That’s the hard part.
-Ben
-- Are you a Product Owner who’s having a hard time deciding what to do? Perhaps you’re wondering how you can make your Scrum team go from ‘good’ to ‘great’? Maybe you want help getting on the Scrum bandwagon? Drop us a line at info@benday.com.
