PremierAgile

Projects are of various kinds; few may be straightforward and predictable and others may be unpredictable and well defined. In projects where the outcome can be estimated, planning and decision making can be applied and a more detailed product roadmap or planning can be done. The team can organize meetings before the project begins and plan the steps through which the team has to walk to achieve the goal. These types of projects could be the construction of a new building or any other project which needs detailed planning and proper execution. However, there are certainly other projects such as software development that cannot be processed effectively using the defined process. The steps in software development are complex and consist of high fluctuations concerning the changes in the development. The market also plays an important role in this process, hence, a predictable approach would not make the development process successful. In this scenario, the concept of the empirical process makes much more sense as this process encourages the developers to build products by gaining experience from their previous knowledge. In this article, we learn in-depth about the differences between defined process and empirical process which will help professionals to have a clear idea about both concepts. 

What is a Defined Process?

A Defined process consists of a well-defined set of steps that need to be followed for the goal to be achieved. A defined process produces the same outcome every time and has low volatility which could be predicted. This makes the process of planning easier as there are no changes that get along the way of development. A defined process is known for its repeatability and predictability. One of the most famous software methods that used a defined process is the waterfall methodology. In this software development method, a product would take months of planning before the actual work for the process starts. There is a project manager who knows about the process and gives a limited amount of information to the developers. The whole responsibility of the project depends on the project manager. The team plans all the details of the project for the next few months and completes all the development processes in the upcoming months. 

There is a command and control type of leadership seen in a defined process where the project manager manages all the developers and orders them the type of work they have to complete. In this process, there is no scope for changes as the team enforces the plan regardless of any changes in the market. If extreme changes are required for the project, the team uses change control as implementing the actual change is expensive. During the planning process, the project has a fixed set of requirements that needs to be fulfilled. The duration of the project depends on how long the requirements are and how long the developers would take to complete it. There would be a certain date that would be fixed by the project manager and the developers by which the project would be completed. This date would be communicated back to the customer. 

Why is the Defined process not a useful approach in software development?

In the world of software development, many changes may take place depending on the feedback of the customers, the demand present in the market, or any other reason. An effective software method should accommodate all these changes in the product as and when needed. The traditional software approach which is the defined process does not allow any changes to take place in the plan created for the product. Also, when the plan for the project is initially created, the team has to assume everything based on the data found from other companies. The requirements are fixed based on this assumption which is not an efficient way of fixing requirements. The product requirement keeps changing which makes the date of completion also change. However, the team has to stick to the date promised to the customers so that the customer is satisfied. This leads to a major crisis in the team and the control of the project is lost. 

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 Empirical Process is an Agile-driven process where the team expects the unexpected. In a defined process the team would plan every detail of the product with the assumption that this is required for the product to become successful. However, in an empirical process such as Scrum, the development work is implemented based on the experimentation and observation of the previous sprint. Unlike the defined process, work in Scrum is split into several periods called sprints which have a fixed time such as two to four weeks. The team builds a minimum viable product based on the needs and basic requirements of the customers and users and launches it in the market. As the users start making use of the product software, they find many bugs and many other features which are required for their experience to be smooth. The empirical process uses facts, previous experience, and evidence for implementing any feature for the product. All of the features that go into the product are discussed, analyzed, inspected, and then adapted to the product. 

In an empirical approach, the customer gets small updates for the product such as bug fixes or new features which were once user stories in a regular period. Also, the concept of changes in the product is widely accepted by Scrum as the process understands that software development is always subjected to changes. The deadlines in Agile-driven empirical processes are also shorter as the sprints are shorter. This is again contrary to the defined process where the customer has to wait for months to get the finished product. The time to market and return of investment for the product is also shorter in the Scrum process. The customers give valuable feedback on the features developed in a sprint that is integrated with the next sprint. The feedback of the users is also taken into account when the team plans the next sprint. 

Characteristics of Empirical Approach

The following are the characteristics of the empirical approach:

• Learning while progressing: This approach believes that the requirements for the product cannot be assumed. It has to be learned as the product development is occurring. The Scrum team learns more about the product they need to build based on the market trends, and customer and user feedback.
• Embracing and expecting change: Changes are the part and parcel of any software development. The empirical approach encourages changes and is always ready to adapt any type of changes to the product according to the current requirement. 
• Using short development cycles to inspect and adapt: Scrum uses short cycles called sprints to deliver value to the product. This value is delivered by inspecting and adapting the previous data, facts, and evidence. 
• Estimates may not be accurate but are only indicative: Estimates done during the empirical process may not be the same. It is only an indicator of which path the team has to follow where the team would get more ideas and values for the product. 

The Three Pillars of Empirical Approach

The empirical approach has three pillars that form the basis of the approach. The three-pillar are:

Transparency

The empirical process makes it mandatory for the project managers and the process to be visible to everyone related to the project. This includes those who are performing the work and those who are receiving the work. Scrum believes that any product features or changes that take place in the product must be communicated to everyone. Important decisions must be taken by considering everyone's opinion. If there are any changes in the project which has low transparency, it could lead to decisions that increase risk and diminish the value. When the process is transparent, it enables the next pillar to be functional i.e. Inspection. 

Inspection

Whenever the goals for the product or the sprint are set, the team needs to inspect whether it would be successful. Inspection is the process of analyzing the agreed goals and detecting undesirable variances or issues. Scrum has five events that help the team inspect the progress of the sprint. These are the Sprint Planning, Sprint Review, Sprint Retrospective, Daily Scrum, and the Sprint. These events help the team to find out errors in the project and also help the team to become productive. 

Adaptation

After inspecting the errors and issues of the project, the team needs to adapt to the changes which would improve the project. If there are any aspects of the project which are not acceptable, the process is adjusted accordingly so that further deviation is reduced. A Scrum team is expected to adapt to the changes the moment they realize any changes or errors through inspection.

Defined Vs Empirical Process

Conclusion

Both defined process and empirical process may work for companies based on their requirements. However, considering the present times where any situation is unpredictable, an empirical approach for software development seems like a better option for any software development organization. If your company is used to using the waterfall model, it is advisable to prefer agile methods and at least give Scrum a try. By understanding how much Scrum could make a difference in the business value, ROI, and revenue of the company, you could apply Scrum on a larger scale and also progress towards other Agile methods.