When you want to be Agile, it requires change in mindset from Defined to Empirical process. It also requires product mindset (read more here) as Scrum Framework and Scaled Agile Frameworks (SAFe) are for product development. Learn about Product ownership and advanced product management practices with our CSPO, POPM and A-CSPO trainings. As per Scrum Guide 2020, “Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials”. So, is there a Project in scrum, yes, “Each Sprint may be considered a short project”. Scaled Agile Framework (SAFe) allows you to extend Scrum to multiple teams, team of teams and scale within large organizations.
There are many different types of projects; some may be simple and predictable while others may be complex and well-defined. Planning and decision-making techniques can be used in projects when the outcome can be estimated, and a more thorough product roadmap or planning can be carried out.
Before the project starts, the team can schedule meetings to plan the measures they will take to accomplish their goal. These projects could include building a new structure or carrying out any other task that requires careful planning and execution.
Other items, including software development, can undoubtedly not be processed properly utilizing the specified process. The processes involved in creating software are intricate and involve significant volatility due to development changes. Since the market also plays a significant part in this process, a predictable approach would not ensure the success of the development process.
In most software product development, we used to spend months gathering requirements, create couple of hundreds of pages of documentation, get few signatures, and freeze the scope. Reflect on your waterfall defined projects and be realistic about what happened. If you think that’s working for you, then keep wasting your time and money. Most importantly you lose trust with your customers when you cannot deliver real customer needs. In addition to that you are over budget, over worked, and quality of your product is questionable.
The empirical process approach makes a lot more sense in this situation since it enables product developers to build things in short iterations while gathering experience from their prior knowledge. This article goes into detail regarding the distinctions between specified process and empirical process, which will aid professionals in understanding both ideas. I hope you will share this article with your friends and fellow team members who needs help in empirical mindset.
What is a Defined process?
A specified process consists of a clearly defined series of stages that must be taken to accomplish the signed of scope. A well-defined process has predictable low volatility and consistently provides the same results. Because there are no modifications that arise during development, planning is made simpler. It is common knowledge that a defined process is repeatable and predictable.
The waterfall methodology is one of the most well-known software development techniques that followed a set process. This approach to software development requires months of planning before any work is done. There is a project manager who is aware of the procedure and provides the developers with a minimal quantity of information. The project manager is solely responsible for the project. I am a PMP certified, and I know from my real-life experience, in most cases project managers are responsible and accountable without much of an authority on key constraints like, budget, scope, and timeline. Usually, in real life Project Managers are fancy scapegoat when project fails.
The team schedules all the project’s specifics for the future months or even multi-year plan and completes all the development phases throughout those months.
In a well-defined procedure, the project manager oversees all the developers and gives them instructions on the kind of work they must perform. This is a command-and-control style of leadership. There is limited room for adjustment in this procedure because the team follows the plan regardless of market fluctuations. In fact, Scope change of any kind is frown upon in waterfall defined method.
The team employs change control when drastic modifications are needed for the project because making the actual change is expensive. The project has a fixed set of requirements that must be met during the planning process. The project’s duration is determined by how extensive the requirements are and how long it will take the developers to finish it. The reality is that customers don’t know everything want, so that leads to analysis paralysis syndrome. The project manager and the developers would decide on a specific date by which the project would be finished. Or even worse, Deadline is defined upfront with little or no information about the scope at some off-site meeting or at a golf course by senior executive that may lead to Death march projects. We could have mandated end date due to compliance or regulatory requirements.
Why is Defined process no longer relevant?
Defined process worked when the world was moving slower. In today’s fast paced world, you need framework and mindset that allows you to meet customer demands faster and support market changes.
Numerous adjustments could be made in the field of software development depending on the feedback from the consumers, the level of market demand, or any other factor. When necessary, all these changes in the product should be accommodated via an efficient software approach. The traditional software method, which is a defined procedure, forbids any modifications to the plan developed for the product. The team must also make all first assumptions while developing the project strategy based on information obtained from other businesses.
This presumption is used to fix the requirements, which is a less-than-effective method. The deadline for completion also changes because of the product’s shifting requirements. To ensure that the customer is satisfied, the team must honor the date that was provided to them. As a result, the team experiences a crisis and loses control of the project.
The requirements in the software development world are always changing. The market has become fluctuating as ever before. There may be features that were popular yesterday but are not being used today as there are better features than the one’s present yesterday. Hence, when a product is given for development by a customer, they would have given certain specifications which take time to plan and develop. Supposing it took months to deliver the final product, the finished product may not be relevant to the market as there would be more features that became popular when the product was being developed. Hence, the time to market is poor in the defined process.
What is an Empirical Process?
An Agile-driven process called an empirical process is one where the team anticipates the unexpected. In a clearly defined process, the team would plan every aspect of the product with the presumption that doing so is necessary for the product to succeed.
In contrast, the development activity is carried out in an empirical approach like Scrum based on the experimentation and observation of the prior sprint. The work in Scrum is divided into sprints, which have predefined durations like two to four weeks, as opposed to the established method. Based on the demands and fundamental requirements of the consumers and users, the team creates a minimal viable product and introduces it to the market.
Users discover several flaws and other characteristics that are necessary for a smooth user experience as they begin to use the product increment every sprint. For creating any feature for the product, the empirical process makes use of facts, prior experience, real life feedback from actual users and hard evidence.
The customer receives incremental product updates, such as bug fixes, tickets, enhancements, or new features that were originally user stories, when using an empirical approach. Scrum is also well known for accepting the idea of product updates since it recognizes that software development is a constantly changing process.
Agile-driven empirical processes have shorter timeboxed sprints so even you fail, your failure risk is lower. Again, this runs counter to the established process, which requires the consumer to wait months before receiving the finished item.
The Scrum process also reduces the product’s time to market and return on investment. Customers provide insightful feedback on features created during a sprint that is merged with the following sprint. When the team plans next sprint, they also consider user feedback.
Characteristics of Empirical Approach
- Learn as you go: This strategy holds that the needs of the final product cannot be taken for granted. As the product is being developed, it must be learned. Based on market trends, user and customer input, and other factors, the Scrum team gains more knowledge about the product they need to develop. For complex, global, multi-scrum team product development may require initial discovery, high level architecture, infrastructure readiness, creating initial product backlog, and can be done as your first sprint to reduce long-term risk.
- Expecting and embracing change: Any software development process involves changes. The empirical method promotes change and is constantly prepared to adjust the product to any form of modification in accordance with the current necessity.
- Performing inspection and adaptation using brief development cycles: Scrum uses short, fixed cycles, referred to as sprints, to bring value to the product. By reviewing and modifying the prior data, facts, and supporting proof, this value is provided.
- Estimates are simply indicative and may not be accurate: The estimates made during the empirical procedure could differ from one another. It just serves as a guide as to the direction the team must take to generate additional ideas and values for the final product. Whenever I hear we want accurate estimates it’s like oxymoron to me. Too much time wasted on perfect estimation is unnecessary. Read more at: https://ronjeffries.com/articles/018-01ff/no-estimates-logic/
Three Pillars of Empirical Process?
“Scrum combines four formal events for inspection and adaptation within a containing event, the Sprint. These events work because they implement the empirical Scrum pillars of transparency, inspection, and adaptation.” (Source: Scrum Guide 2020)
Transparency
In Scrum Framework, any product features or modifications or defects, or non-functional requirements must be visible to all stakeholders. Everybody’s viewpoint must be considered while making important judgements. Any changes to the product that are not transparent could result in choices that raise risk of rejection and reduce value. Transparency in the process makes it possible for the Inspection pillar, the following pillar, to function. When the process is transparent, it enables the next pillar to be functional i.e., Inspection.
Inspection
The team must determine whether the goals for the sprint or the product would be successful before setting them. Analyzing the established objectives and finding unfavorable deviations or problems is the process of inspection. Scrum provides five events that the team can use to evaluate the sprint’s progress. These include the Sprint, Sprint Planning, Daily Scrum, the Sprint Review, and the Sprint Retrospective. Remember as per scrum guide, Product Backlog Refinement – also referred as grooming is not an event however it is an ongoing activity throughout the product lifecycle. These occurrences aid in the team’s productivity as well as the discovery of product flaws early and often. When you learn something new from inspection, it enables the next pillar to be functional i.e., Adaption.
Adaptation
The team must adjust to the changes necessary to improve the product after examining its flaws and problems. When a Scrum team discovers any modifications or mistakes through inspection, they are expected to adjust to the changes right away.
Agile vs Waterfall – Define vs Empirical Process
Check out our article ‘Start Lean Portfolio’ and SAFe Lean Portfolio Management (LPM) Training for Executives.
Conclusion
An empirical approach to software development, however, seems to be a superior choice for any software development firm given the unexpected nature of the world we live in today. You may consider using the scrum and Kanban approach for non-IT and infrastructure projects – Check out the ScrumBan article (Need to add link). You might implement Scrum on a wider scale and advance to other Agile methodologies by realizing how much of a difference it could make to the company’s business value, ROI, and income.
Defined Process |
Empirical Process |
| Big upfront planning | The planning takes place as the team progresses throughout the product lifecycle. |
| The entire project is completed within a single cycle which may take months. | The entire product backlog is broken down into smaller backlog items and sprint is completed in short cycles where it is reviewed after each cycle. |
| The project manager knows most of the information of the project. | Everyone involved have a great visibility and transparency. |
| There is a command-and-control type of leadership among the manager and the developers. | The Scrum or Agile team is self-organizing and have the liberty to ask questions and share their opinions. |
| The accountability of the project is on the project manager. | The accountability of the product is on everyone who is creating and delivering the product. Product Owner is ultimately accountable for maximizing value. |
| The time to market and return on investment takes longer. | Improves time to market drastically. |
| The developers are told how and what they must create and there is no scope of creativity or freedom. | The developers are given product goal and sprint goal where the scrum team could employ any techniques or software and deliver outcome every sprint. |
Partner with DailyAgile and let us help you accelerate business agility. Check out our upcoming workshops at: https://dailyagile.com/courses/. Contact us, if you are looking for free 1 hour webinar or agile questions and answer session with your agile leaders. We wish you best of luck in your agile journey. By Kiran Thakkar and Team DailyAgile, 1.800.758.AGILE(2445) or email us at: info@dailyagile.com
