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 a product manager 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 frameworks. It was an interesting comment and my follow-up question to him as if there could be any software product that we wouldn’t need to commit necessarily in small batches and build all the features defined at the beginning of the project 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 whether agile was good or bad but to understand what his approach would be to manage a project before jumping into the conclusion and forming a framework for teams 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 product management or prevent a tunnel vision and many could also probably think the same about managing a software project as this candidate 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 would you then not follow scrum or Kanban? Would there be any software development project that you don’t follow agile and build all features all at once?
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. Here are some of those projects I can think of:
- If 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 critical software applications where the security matters the most for what the software is used for. ABS in a car or engine power control software in an airliner must never fail when released to the public and be 100% bug-free otherwise cause 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-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 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.
My opinion on the project management structures is that there is no predefined framework or guideline that will fit every organization or project flawlessly. I believe every organization should find its own organizational way to produce a software that will get the job done for the customer whether the way is scrum or kanban or the other. But keeping in mind that agile frameworks are not always the best ones and sometimes don’t fit certain software projects, will be helpful to avoid tunnel vision on them before executing a project.
Source link https://uxdesign.cc/why-to-build-all-features-all-at-once-7bbd10dfdb41?source=rss—-138adf9c44c—4