Why to build all Features all at once

One of the questions I ask a candidate while interviewing them for a product manager role is about their experience in managing software projects and what lean means to them in that context. It is about knowing if they will be using the resources in an intelligent way while executing projects and delivering products, not using them until they know they actually have to, which lean mindset is actually all about. It is also about getting them to talk about their day to day project management experience and if they’ve followed any structures such as scrum or kanban which I believe are some of the essential skills needed by product managers in the software industry.

I was interviewing a candidate with a good deal of product management experience a few weeks ago. While discussing his experience in managing projects, at one point he commented he couldn’t believe that he still saw some software companies that didn’t adopt “agile”. It was an interesting comment and my follow-up question to him was if there could be any software project that we wouldn’t need to commit necessarily in small batches but design, plan and build all the features before releasing to the public. He couldn’t think of any reason why a software company would do that or follow a different framework anything than agile if they would already know what agile was for.

The purpose of my question was not to discuss agile over other frameworks but to understand what his approach would be to manage a project before jumping into a conclusion and forming a framework for his team to follow and lead it whether it is scrum or kanban or the mix of the two. His view was that agile frameworks like scrum or kanban were the best out there, if not the only ways, to software development in any given organization and project.

Years of experience doesn’t always correspond to being good at software development or prevent a tunnel vision on it as there is a continuous change in software industry as a whole, how developers work, and how new tools and environments emerging everyday allow developers to work better and faster. Many could also probably think the same about managing a software project as this candidate did without given it a second thought. In the end, there is so much buzz (rightfully) and benefit around being agile that it almost feels like its scrum or kanban or the mix of the two are the only ways to go if a company wants to manage a software project nowadays.

So, why wouldn’t you then follow scrum or Kanban? Would there be any software development project that you don’t follow agile and build all features all at once to have a working product?

There are some software projects big plans ahead of time might make more sense and the software is shipped with all the features needed before it is released to the public instead of building it with the few important features and validating it with the market first in response to feedback. Here are some of these projects I can think of:

• A large company that doesn’t want to miss a big trend in its industry with one of their product lines. These companies tend to be more concerned about opportunity cost and their brand value while resources are not being a hard constraint for them. They usually have a high tolerance for risk to over commit and release and figure out the market doesn’t want it. That’s why Google’s many projects fail but they are totally fine with it.
• Mission or safety critical software applications where safety, security or reliability matters the most for what the software is used for. OS in a device, ABS in an automobile, or engine control systems in aviation must never fail. The software in life-critical systems must be bug-free when released to the public otherwise might cause serious damage or even result in deadly circumstances.
• Investors or executives sometimes play a big role where the product should go and they influence the functionalities a product needs to have. It is usually to compete with the company’s competitors which have those functionalities, assuming that they will not go bankrupt, and such functionalities are released with all features desired.
• In sales people-driven companies, salespeople might sell a new feature to a customer that you haven’t built yet. If you do it, most of the time it brings you a huge sum of money (assuming that the customer will not go bankrupt) which can justify why you build and release all features a customer needs. This can be the case for many SaaS companies.
• This last example is sad but true. When new business opportunities do not emerge anymore, some companies keep their teams busy initiating projects where teams release features whether there will be a chance to validate it with the market or not. This actually doesn’t fit any project management structure but still, it is over-committing.

All these projects and how you build them don’t really coincide with what you traditionally would be concerned with agile frameworks where you usually design, build and release the most important features of a software first and go to market with them to see what the user feedback is before going ahead and building other features.