As businesses continue to supercharge their application life-cycle and rapid app development becomes glued to modern IT frameworks, these shifts are disrupting the way that we think about IT contribution. In the past, development and operations have both been measured by the effort that they put forward on a specific project. The more hours and successful code or operations that you bake into a particular project, the more successful you seem. But, can progressive frameworks as agile development survive in this mentality?
This question has been bounced around for a few years. If the goal of modern development frameworks is to spread responsibility and increase collaboration, does it really make sense to standardize success based on individual contributions? Better yet, is the success of an app measured by metrics that track time contributions and individual efficiencies? Or, is it measured by the value of the end product?
While agile shifts the app cycle left, businesses have to adjust the mentality driving their culture to base success on value, not projects. In 2019, we're seeing thousands of companies change their outlook and culture surrounding the software development life-cycle. Here's why companies are switching from project-based development to product-based development.
"There are both business products and IT products. A product is simply something that has a customer base that it delivers value to." - Carmen DeArdo, former DevOps tech director at Nationwide Insurance [InfoQ]
Before we discuss how product vs. project-based design impacts IT managers, who typically are one of the first to on board the new mentality, we need to understand the differences between products and projects (in terms of the dev life-cycle).
A product is something that satisfies a business or market need. So, that latest automated security software — that's a product. One of the main distinctions between products and projects is that products exist in a life-cycle. From inception to market introductions to continuous updates, products typically last until customers no longer have a need for the solution.
A project is a temporal venture that's undertaken to develop a product. So, instead of being viewed from a lens of semi-permanence, projects are purposefully set to a time-frame.
At first, it may seem like products are the spawn of projects. That's completely correct. So, what does it mean to reframe your dev life-cycle to product-focused instead of project-focused if projects created products?
Now that we know what a product and a project are, let's talk about them in terms of the software development life-cycle.
Project-based development involves thinking of the development and operation of an app as temporary. Employees are typically measured by the effort put forward towards a specific project, and each project could use temporary workers, unique processes, and hyper-specific strategies. This means that projects are often ad-hoc.
Product-based development is a more permanent way of thinking about applications. So, employees are judged on their contribution rather than their individual metrics. This means that product-based development can be thought of as a complementary mindset to agile frameworks. In product-based development, apps are viewed from a perspective of whole-life-cycle-development as opposed to temporary app pipelines.
Let's look at why so many businesses are choosing to move towards product-based design.
One of the key benefits of agile frameworks is the ability to use automated practices throughout the software development life-cycle. But, if development cycles are thought of as temporal, finding ways to justify the expense of automation is difficult. What's the point of automation if it isn't really a core part of your life-cycle? If your business is simply using automation ad-hoc to deal with project-by-project needs, the time and costs associated with automation adoption are likely unnecessary.
But, thinking of the development life-cycle as product-based gives you the flexibility to create business-wide processes that lean on automation to eliminate redundancies. Of course, this saves time and money — which was the point in the first place.
When you think about apps in the light of temporary, it's difficult to glue customer-centricity to your Dev and Ops thought processes. The ultimate goal of any good app is to deliver value to the user. But, if the incentives behind the project are based solely on metrics and individual contributions, convincing devs and op managers to focus on value is difficult.
The project-based design makes this easy. Since value is glued to the project-based design framework, providing value is the goal — not the app itself.
Another significant benefit of product-based development is the ability to spread collaboration. Everyone becomes responsible for the entire app, which means that everyone is invested in the success of the whole application, not just "their" part.
With the product-based design, value is placed on collaboration, not employee-by-employee contributions. Trying to build an agile framework under the microscope of project-based design devalues the entire architecture that makes agile so powerful.
Again, responsibility-spread is an intrinsic benefit of product-based design. Remember, value is coming from app success — not employee success. This means that Dev and Ops don't share separate responsibilities, they share the same one. All that matters is how the app satisfies customers. That's the be-all-end-all of product-based design.
Hiring employees by the project forces fractured dev environments. Even further, basing employee performance on specific projects — which often require role-switches and different metrics — creates bubbles in the development cycle. Goals aren't viewed as long-term, because the app is viewed from the perspective of temporary.
With the product-based design, employees are responsible for the app throughout its lifecycle, which includes post-launch continuation. Of course, the product-based design requires a more temporary outlook on employee roles, which means that employees can focus on the roles that they excel at.
One of the most significant challenges facing Dev and Ops teams in the current agile environment is their mentality towards app development. In the past, the software development life-cycle has been thought of as a group of temporary projects that push out applications. Instead, try thinking about apps as more permanent products. Of course, you can still plan projects. This isn't about a specific process or strategy; it's a complete change in mentality and culture.
To be fair, this isn't a new concept (see Apple and Amazon). But, we've witnessed product-based design explode over the last few years due to the necessity of automation and extreme agility.
If you enjoyed this article click through to read our Ebook on Product based vs project based development: IT Manager's guide to product development in 2019 hope you enjoy the read!