Articles

Scrum, a framework within Agile, is rooted in the principles of empirical process control, which emphasizes knowledge derived from experience and decision-making based on what is known. It operates on three main pillars: transparency, inspection, and adaptation. Transparency ensures that all aspects of the process are visible to those responsible for the outcome, fostering a shared understanding. Regular inspection allows the team to frequently check on the progress towards the sprint goals, identifying any variances from the desired outcome. Adaptation enables the team to adjust processes, plans, and practices in response to these inspections, ensuring continuous improvement and alignment with project goals.

In today’s rapidly changing market trends, the customer may imagine an ‘apple’ and the finished product made by the project team may be an ‘orange’. This though is not the main problem. If the customer is aware of what’s cooking from the start he can steer the team to the ‘apple’ side. But in actuality the customer finds out about the ‘orange’ only too late. In other words if inputs and processes are in control and are reliable, we can get reliable outputs (which are generally the case with Waterfall model). The problem arises when inputs and processes cannot be controlled rigidly which generally means that the outputs would be unreliable (the Agile/Scrum scenario). In such circumstances we need to look beyond the waterfall model and focus on Empirical Process Control which simply means you need to look at the outputs more frequently and if it is not as per your liking you go back to inputs and processes and tweak it accordingly.

In Scrum, decisions are made based on observation and experimentation rather than on detailed upfront planning. Empirical process control relies on the three main ideas of transparency, inspection, and adaptation.

Transparency allows all facets of any Scrum process to be observed by anyone. This promotes an easy and transparent flow of information throughout the organization and creates an open work culture. In Scrum we have a Project Vision Statement which can be viewed by all stakeholders and the Scrum Team; an open Product Backlog with prioritized User Stories, both within and outside the Scrum Team; clearly visible Scrumboards, Burndown Charts, and other information radiators; Daily Standup Meetings conducted making sure everyone’s aware of everything; and Sprint Review Meetings in which the Scrum Team demonstrates the potentially shippable Deliverables.

The following figure summarizes the concept of transparency in Scrum

Inspection in Scrum is depicted through the use of a common Scrumboard; collection of feedback from the customer and other stakeholders; review and approval of the Deliverables by the Product Owner and the customer.

The following figure summarizes the concept of inspection in Scrum:

Adaptation happens as the Scrum Core Team and Stakeholders learn through transparency and inspection and then adapt by making improvements in the work they are doing. In Daily Standup Meetings, Scrum Team members openly discuss impediments to completing their tasks and seek help from other team members. Risk identification is performed and iterated throughout the project. Improvements can also result in Change Requests, which are discussed and approved. The Scrum Guidance Body interacts with Scrum Team members during many processes to offer guidance and also provide expertise as required. During the Sprint Retrospective, agreed actionable improvements are determined.

The following figure summarizes the concept of adaptation in Scrum:

These three pillars of Empirical Process Control ensure that the problems which projects face in the Traditional Waterfall way of doing things do not happen in Scrum Projects.

We normally do not associate companies in the private sector with bureaucracy and reserve that criticism mostly for governments and public sector organizations.

But how many times have we waited for a response from a department which never came?

How many times have we felt things have taken twice as long as they should have?

How many times have we faced conflict situations because of poor or inadequate communication?

These issues are not specific to a governmental organization but can happen, and do happen, even in the most modern, multinational companies.

Traditional reactions to such issues involve establishing lengthy processes, assigning responsibilities or scheduling ‘regular’ meetings. But many a times, what happens is that the extra processes and responsibilities just add to the confusion and the ‘regular’ meetings are rarely focused and stop happening after a few weeks.

Scrum, as a framework, focuses on regular communication, singular accountability, flat hierarchy and dedicated team members working to a mutually agreed schedule. In its most simple form, a Scrum team is formed of members who will actually be working on a project, selected and led by the Scrum Master, working on mutually agreed tasks and timelines, meeting on a daily basis to complete deliverables piece by piece.

However, trying to implement Scrum in its most basic form to complex projects or large organizations where tasks are often complicated, rarely works. Numerous examples abound of large teams adopting Scrum only to discard it after a few weeks. The reason is that a framework needs to provide the tools to everyone in the team to perform their tasks and not just stop at a 10,000 feet level.

This is where the Scrum framework, as defined in the Guide to the Scrum Body of Knowledge (SBOK ™ Guide), comes to the rescue. It fleshes out the basic Scrum framework by suggesting practical techniques and processes by which the Scrum team can complete its tasks. Large and complex organizations can benefit from it because it uses familiar techniques but puts them in a highly Agile framework. Thus, a Scrum project initiated to reduce documentation (and consequently red tape), doesn’t just get team members from different parts of the organizations to attend daily meetings, but it empowers them to fulfill their roles by providing them practical methods and techniques. The SBOK™ Guide lays out ways to build the right environment and a key element of that is the buy in of the whole team towards the project vision. Thus, the project team becomes a self-motivated unit and is not just driven by the Scrum Master.

This buy-in supplemented with empowered Scrum team members is what, in the end, removes communication hurdles and makes organizations far more efficient than they would under traditional project management approaches.

Note: The Scrum specific terms used in this article are as per the Guide to the Scrum Body of Knowledge (SBOKTM)

Every project, irrespective of scale and size, is subjected to risk. Even a smallest of project involves some amount of risk. This is one of the unique characteristics of a project. So, when we work on a project, we do risk management side by side. ‘Risk’ often has a negative connotation and we usually think risks are bad. But in project management it is described as “an uncertain event which if happens will have a positive or negative impact on the project objectives.” So, we try to maximize the impact and probability of positive risks (also called ‘Opportunity’) and try to reduce or remove the negative risks (also called ‘Threat’). In project risk management, we do undertake different activities to manage different types of risks based on the probability, proximity, effect and impact of the risks. Let’s focus on the negative risks in this article. Projects are usually riskier at the beginning of the project because of amount of uncertainties involved. Many a times, the customer does not have clear ideas about the requirement which multiplies the uncertainties. ‘Scrum’ framework of managing project is extremely suitable in this scenario. Being an Agile, iterative process, the Scrum framework inherently minimizes risk. The following Scrum practices facilitate the effective management of risk:

1.    Flexibility reduces business-environment-related risk

Risk is largely minimized in Scrum due to the flexibility in adding or modifying requirements at any time in the project lifecycle. This enables the organization to respond to threats or opportunities from the business environment and unforeseen requirements whenever they arise, with low cost of managing such risks.

2.    Regular feedback reduces expectations-related risk

Being iterative, the Scrum framework gives ample opportunities to obtain feedback and set expectations throughout the project lifecycle. This ensures that the project business stakeholders, as well as the team, are not caught off guard by miscommunicated requirements.

3.    Team ownership reduces estimation risk

The Scrum Team estimates and takes ownership of the Sprint Backlog Items, which leads to more accurate estimation and timely delivery of product increments

4.    Transparency reduces non-detection risk

The Scrum principle of transparency around which the framework is built ensures that risks are detected and communicated early, leading to better risk handling and mitigation. . Moreover, when conducting Scrum of Scrum Meetings, Impediments that one team is facing currently can be deemed a risk for other scrum teams in the future, and that should be recognized in the Updated Impediments Log.

5.    Iterative delivery reduces investment risk

Continuous delivery of value throughout the Scrum project lifecycle, as potentially shippable deliverables are created after every Sprint, reduces investment risk for the customer.