At the strategic level, successful enterprise architecture and demand management prevent portfolio-level waste by ensuring that company resources are utilized for the right product development projects that support company strategies.
To prevent waste at tactical and operational levels, resource utilization within the projects should be also optimized. This can be achieved by applying an appropriate methodology in every product development project.
Law of Entropy
As physics theory, everything in the universe has a bias to pass from a well- ordered state to a disordered state due to the law of entropy. This is also valid for product development projects. To prevent disorder and chaos, project teams should apply a methodology.
However, some managers fall into the trap of overstandardization and try to apply the same standard methodology to all of their projects. They even assign showy names such as Xagile, Waterscrum, and Scrumfall to these methodologies.
Since every project has different dynamics, it is better to apply a customized methodology that fits the specific project’s needs instead of a one-size-fits-all approach. At a majority of companies, the most popular methodologies are waterfall and agile.
Waterfall or Agile?
According to the dialectical method in philosophy, “within themselves all things contain internal dialectical contradictions that are the primary cause of motion, change, and development in the world.” Similarly, the internal contradictions and drawbacks of the waterfall methodology have been the driving force behind agile adoption.
The lean approach is usually associated with agile methodologies mainly due to its three manifesto statements:
1. “Working software over comprehensive documentation”
In scrum, a popular agile framework, requirements are defined as short and simple user stories (as a “role,” I want “goal”) on the product backlog by a business unit representative (the product owner). This minimizes the level of documentation and bureaucracy witnessed in waterfall projects.
- “Customer collaboration over contract negotiation”
In agile projects the product owner and the development team work at the same location, which creates a more collaborative product development environment compared to waterfall projects.
3- “Responding to change over following a plan”:
In waterfall projects, development waits for the completion of analysis and design phases. Thus, in a one-year project, it takes at least five to six months on average to get to the working parts of a product. This latency in delivery creates anxiety for business units who are impatient to see “quick” results. On the other hand, the agile team releases a working part of the product in a series of two to three weeklong “sprints” under the coordination of a “scrum master.” The team velocity is adjusted iteratively by analyzing burn-down charts of previous sprints.
Agile projects’ fast delivery of working products, starting from the first iteration, brings confidence to all stakeholders and enables the gathering of early customer feedback.
At dynamic business environments in which change is not the exception but the norm, applying agile methodology is more meaningful, because waterfall has low flexibility for changes on requirements. Any possible change to the requirements has an impact on the overall analysis and design artifacts. In agile environments a change to the requirements has no effect on the parts of the product that have not been analyzed or designed yet.
The product owner and the project team should conduct regular “grooming sessions” in agile projects. The aim of these sessions is to discuss customer feedback from previous sprints and update the product backlog by removing user stories that no longer have a value proposition. This also makes agile a more effective methodology in dynamic business environments.
However, applying agile methodology to every kind of project is not a correct strategy. It is still more appropriate to proceed with waterfall when:
-the product has intensive integration among its components;
-the colocation of project team members is not feasible;
-it is not possible for the team members to work only for a single project at a time; and
-there is high employee turnover, which runs the risk of losing project knowhow in case project team members leave the company.
Agile is iterative by nature. Although waterfall is a sequential methodology, it is still possible to make it more iterative by
-increasing the number of releases,
-benefiting from prototyping and review meetings to get early feedback from customers,
-minimizing the detail level of requirement documents by more effective usage of diagrams, and
-decomposing requirements into right granularity to improve understandability and traceability.
Quantum vs. Deterministic Models
Einstein’s and Heisenberg’s formulations are the most dominant models for explaining the laws of physics. Einstein did not believe in randomness (indeterminism), and he summarized this with his famous quotation, “As I have said so many times, God doesn’t play dice with the world.” On the other hand, Heisenberg’s quantum model is based on the uncertainty principle, which is also called the “principle of indeterminacy.”
Although these two theories are completely different, a physicist can still use both to make accurate calculations for different cases. While they mostly use Einstein’s formulations to model atomic particles moving at velocities close to the speed of light, they use quantum formulations to model the behavior of subatomic particles.
We can associate waterfall methodology with Einstein’s deterministic models and use it for projects that require big design upfront in relatively static business environments. On the other side, we can associate agile methodology with quantum theory’s indeterminism due to its success in dynamic business environments with random business conditions.
Managers should not fall into an “either/or fallacy” by feeling they have to select either waterfall or agile. For some projects, including both static and dynamic conditions, even a hybrid strategy can be formulated that applies both waterfall and agile methodology for different phases within the same project. Waterfall can be applied at the initial phase of the project to release high-priority, core features of a product that has a complex architecture of many integrated components, and agile methodology can be applied in later phases to release remaining medium-and low-priority features.
For the CEC mobile application project, our team applied a similar hybrid methodology. Waterfall was applied at the first phase of the project, which lasted two months. At this phase only high-priority features were developed and released on a core version of the mobile application.
The first phase of the project was delivered on time, within two months, and the following observations were made regarding the initial release of the product:
-A mobile sales channel was launched before competitors.
-The number of people who downloaded the CEC mobile application was more than expected.
-The number of customers who used the mobile application to view and order CEC products was more than projections on the business-case document.
This way, the CEC marketing business unit verified that the mobile application was a good idea. Even with a limited number of features, the product generated high value for CEC customers and satisfied business requirements.
Based on these initial results, the marketing business unit decided to initiate the second phase of the project to implement medium-priority features that were predefined on the business-case document.
In the second phase, the project team applied agile methodology. The project manager started to play the scrum master role. Since the CEC marketing team could not allocate a senior representative, the most experienced business analyst of the team played the role of product owner. The other business analysts became part of the agile team together with developers and software testers.
The medium-priority features of the mobile application were developed and released within two sprints, each of which lasted three weeks.
After analyzing the customer feedback and mobile application usage logs of sprints one and two, the marketing business unit observed that:
-Customers definitely checked other customers’ ratings and reviews before buying a product. This new feature was also very useful for listening to the voice of the customer, which was not possible to get from the dealer channel.
-Instead of contacting the call center, CEC customers were using the mobile application to track their orders. This resulted in extra savings, thanks to the reduction in outsourced call center costs.
CMO was happy to see that newly added features paid back very quickly. After analyzing usage logs and customer journey mapping studies, the marketing business unit decided to add some additional features to further increase the mobile application’s utilization rate.
These new features were also implemented with agile methodology in two more sprints.
After analyzing the customer feedback and mobile application usage logs of sprints three and four, the marketing business unit observed that:
-The product feature that sent coupon codes when customers connected to a CEC product via the CEC mobile application became very popular. Used by a high number of customers, it positively impacted cross-sell opportunities and customer loyalty.
-Customers were not as responsive as expected to the contextual offers sent via the mobile application. This was a disappointment for the marketing business unit. The business unit decided to drop this feature, which was not adding remarkable value.
-The marketing business unit also noticed that some customers were rating the dealer service quality performance very low, and this was negatively impacting other customers’ buying decision. The team decided to fix this problem as follows: Customers would continue to rate dealer service quality via the mobile application, but the customer’s rating would not be visible to other customers. It would only be visible to the CEC dealer management team.
