What, How, When: The separation of duties in Software Development.
I've been at the Software game for a while now. Sometime in the 90's I decided this would be a great career and I never looked back. In those years I've used many different methodologies to go from concept to working product: No process at all, XP, Waterfall, and variations of Agile. The ultimate problem is: How do we balance creating "Good" enough software that meets our customer's needs without too many bells and whistles and isn't over engineered. In my opinion its not just the process you run but the people who are assigned the responsibilities of: "What", "How" and "When"
Regardless of your choice in methodology there are certain constants that must be true in order to consistently provide value to your end users. Someone must define their needs (the "Whats"). Someone must define the technical approach (the "Hows") and someone must keep everything in check so it's delivered within a given time-frame (the "When").
"What" - This belongs (in Scrum vernacular) to the Product Owner. "Whats" should be defined as the "Needs" of the customer or the business. Keep the "Hows" out of it unless the "What" cannot be explained without it. "Whats" are best expressed as User Stories but they might just be a list of features that the user or business is getting with this new product.
"How" - This belongs to an architect or lead engineer. Once the "Whats" have been defined the lead should create technical tasks (or stories) to complete them. This effort should be sized using whatever methodology / sizing system your organization prescribes to.
"When" - This belongs to the manager. The manager is ultimately responsible for the successful release of the product and (for my definition) that means that it is done within a given time-frame. If the "Hows" are sized the manager should have a decent idea of "When" his group will deliver the product.
Why the separation? My answer is: because it creates a healthy balance. The manager should push back on anything that changes scope and is ultimately affecting "When" the product will be done. The Product owner should keep in mind "what" is needed for an initial release but when a feature is missing "Push" to get it in. Finally, the lead may discover (through a failed technical assumption or new requirements) that the "How" has to change and should push to keep the architecture manageable.
What about deadlocks? Sure, its possible that there is a stalemate between the three but if you find yourself in that situation ask yourself, why? Who is being obstinate and how can we convince one another of the benefits of staying the course or changing because it's necessary. It may be that your organization is depending on you delivering by a certain date, use that as a factor. It may be that you need the "right" product in the field, use that as a factor. It may be that the product just won't scale, use that as a factor. Eventually the right answer will emerge as long as there is a discussion.
What if someone on the team is owning more than one responsibility in your triangle? That is where the problem starts and balance gets out of whack. Think about the scenarios for a minute. Someone owns "What" and "When" for instance. My experience here is that they'll opt for one point of the triangle over the other. Someone who only cares about features ("What") will never get anything done because the project will be heaped with one feature after another. Someone who only cares about "When" will skip features and deliver something mediocre or just not what anyone wants. You can play this game with any two of the three or worst case, someone owns all three. The more ownership heaped on one person the less likely the project will hit its desired mark.
Can this be done with limited resources? It takes three people who are responsible for these duties and they can belong to any of the development team's participants. I've outlined who I think should have these roles but regardless of who they are assigned as long as each person understands their responsibility then you should be able to strike that balance.
In conclusion, balance is something that we all seek even if its not necessarily in the forefront of our thinking. Sometimes the problems we are facing overwhelm our senses and because we own too many responsibilities we fail to see where they are coming from. My hope is that by separating out "What", "How" and "When" and sharing those triangle points with different people the development team as a whole can knock out one useful project after another that is: The right solution with the right architecture and right on time.
