Software Development Starts with the Product
In my last post, I addressed how effective software development today is very different from the software development of 15 years ago. And that the best way to understand what has changed is to think of software from 15 years ago as being analogous to constructing buildings, and software development today as being a highly iterative process that is based more on development velocity and frequent releases, and less of a sense of a fixed large-scale design that is known before work begins.
However, even if you believe in this vision, if you don’t use the right processes to create designs and build software, you will likely end up in a worse place than you would have with a more traditional, waterfall development project. This is because, with a traditional development project, you are usually targeting a much larger scope that is either going to succeed or fail, usually as a one-time event. You put all of your eggs in the basket of the design, so it is simpler for the technical implementation side to take a lot of time and just build out what has been specified at the beginning. So you plan it, and then you build it, and then you see if you were correct in thinking that this was the thing that should be built.
The Journey Never Ends
But whether a software project — whether it is done traditionally or in a modern way — is going to succeed or fail, is based on two criteria. First, is this thing that we built something that people actually want (e.g., will pay for and/or will use). Second, were we actually able to build it?
These two criteria map to two separate teams within organizations: the product team and the development team. In traditional software development, the product team writes the specifications first and then the technical team figures out how to implement them second.
However, in modern software development, because the development never ends, no one has a complete vision from the beginning. So instead, the product team needs to give the technical team a minimal vision first. We have a lot of terms for this type of thing, like a minimum viable product, but they often get badly distorted, and there is a sense that a minimum viable product is a complete thing or a big event not unlike waterfall release. The reality is that the best modern software development organizations don’t need a complete anything in their initial release. They are releasing something minimal that a user can do something with.
In addition, in modern effective software development, there has to be a lot more back and forth between the product and tech teams then there ordinarily is with waterfall. This is because the tech team can help the product team down scope specifications to get things done more quickly. Additionally, because this product is being built iteratively, the tech team needs to understand a lot more of what the possibilities of the future may be, and why the product team is doing certain things at this point.
In the back-and-forth, the product team is delivering an empathetic and complete view of the user and the user’s problem to the tech team, and there is a collaborative effort to figure out how to down scope of the work so that it can be delivered quickly.
In modern software development, because the development never ends, no one has a complete vision from the beginning.
The most effective product teams will go through a three-stage process before handing work to be implemented to the tech team. First, the product team, through effective interviews (e.g., something like lean customer development), identifies the basic features that will be built. At the end of this first step, the product team has identified a user, a problem, and the rough shape of a solution, combined with a number of questions around a variety of different ways that solution could be done.
The second step is a collaborative back and forth with the product team, the tech team, and any other key team members and stakeholders.
In this back-and-forth, the entire team talks about and understands what the problem is and what the solutions are. Each adds his or her own opinion and expertise on various elements of how this solution might be built. This means that the tech team can explain certain things that are easy to do technically and certain things that are hard. In addition, the product team can adjust their notion of what should be done in the light of the feedback they are getting. You should be able to see that if the scope is too large, this process will take way too long, so it’s critical to have down scoped before you reach this point.
The third step is that the product team takes the information they got from the collaborative meeting and they go back to the customers with a firmer sense of what is likely to be built, and they specify it with high rigor, including full designs and interactions laid out in unambiguous wireframes and or documentation.
This sets up an extremely effective framework to provide the development team with small enough scoped and validated specifications so that the development team can do iterative releases frequently and customers can see meaningful improvements in each release.
Now, not everything that development does needs to be specified in this way. Certainly, bug fixes and small tweaks and even categories of small features can be implemented without this type of rigor. But core features of the application should be implemented this way and then significant improvements or revisions to those features should also be implemented in this way.
If you follow these processes properly, you stand the best chance of delivering software that people actually want to use and pay for. However, we still haven’t talked about the specific technical practices and processes that need to be followed in order to do this kind of high-velocity frequent release develop. And that is for the next post.
Originally published at thenewstack.io on November 28, 2016.
