More on this book
Kindle Notes & Highlights
by
Emrah Yayici
Read between
January 20 - January 22, 2022
According to the cost benefit analysis, the mobile application project had a positive NPV (net present value). It would payback in less than three years. This pay-back period was acceptable for the marketing business unit.
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.
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.
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.
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. 2. “Customer collaboration over contract negotiation” In agile projects the product owner and the development team work at the same location,
...more
“Responding to change over following a plan”:
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.”
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.
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.
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.”
they use quantum formulations to model the behavior of subatomic particles.
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.
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.
User requirements, functional requirements, nonfunctional requirements, and business rules of the product should be defined consistently with business requirements to keep the project on track and ensure the strategic, user, and technical fitness of the product.
To mitigate this risk, business analysts should give highest priority to translating business needs into correct user requirements during requirements-gathering meetings.
They should always keep in mind that “doing the right thing is always more important than doing it right.”
Business analysts should consider conflicts among project stakeholders positively during the requirements-gathering stage. If these conflicts are not discussed and resolved at this early stage of the project, they will later appear as high-cost CRs (change requests) at the development and testing phases. CRs are the main source of waste at PDLC because they
-Realize that innovation cannot be achieved at the technical level. Innovation is a matter of formulating solutions that best meet user needs. -During
“What are customers’ needs and how will the new product meet them?” instead of asking, “What should be the technical features of the new product?”
Balance the level of creative vs. critical thinking at requirement-gathering meetings.
Critical thinking means asking the right, to-the-point questions and verifying them before assuming that they are correct.
Although business analysts and project managers may have enough level of business and technical knowledge, technical teams should still be invited to requirements-gathering meetings to better evaluate the technical feasibility of requirements.
Don’t try to find the answers to why (we need the product), what (the product does), how (the product does), and technically how (the product works) questions during one single meeting.
Don’t listen to the voice of the customers only from product owners and business unit representatives. Elicitation techniques, such as shadowing, should be used to observe customers while using the products or their prototypes. In the lean approach, this is described as “go to the gemba.”
Yes-men are more dangerous than no-men. They are silent and friendly during requirements-gathering meetings but become aggressive and extremely demanding later at user acceptance tests.
In the lean approach, requirements gathered from both perfectionist and overlooking people should be analyzed carefully. Perfectionists usually focus on details of low-priority product features. On the other side, overlookers may mislead the project team by even undermining high-priority product features.
The observer effect in quantum mechanics states that “by the act of watching, the observer affects the observed reality.” Similarly, during requirements-gathering meetings, asking questions in a biased way impacts the objectivity of answers from participants.
Wrong questions mislead the team, generate conflicts, waste project time, and result in failure. Business analysts should prepare simple, objective, and to-the-point questions for these meetings.
The more conflicts resolved at this early stage means fewer CRs during the project.
remember the advice of Henry Ford: “There are no big problems; there are just a lot of little problems.”
“functional decomposition”
“five whys” technique, which is iteratively asking questions as a basis of the next question until finding the root cause of a particular problem.
When a change request is received, analyze its forward and backward impact on all levels of requirements. According to the Butterfly Effect in Chaos Theory, a small change at one place in a complex system can result in large effects elsewhere.
The formation details of a hurricane can be influenced even by the flapping of a butterfly’s wings at a distinct location several weeks earlier. This is also valid for CRs.
Features that customers do not use after the release are a big source of waste. The main reason for this problem is the lack of customer centricity during the traditional product-centric analysis and design approach.
Defining the details of user requirements by employing the “use case” technique in waterfall methodology and the “user story” technique in agile methodology
