Why is Empirical Process Control So Important in Scrum Projects?

Why is Empirical Process Control So Important in Scrum Projects?

In the traditional Waterfall model, all the planning needs to be done before any execution and the customer does not review product components till the end of the entire project. Although the PMBOK may write eloquent poems about how elegantly this works, in the real world things go down completely haywire. This method presents huge risks to the project and it is far more likely to significantly impact project delivery and customer acceptance.

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.

This is why Empirical Process Control is very important and why Scrum is the winning horse people should put their money on. 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.

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.

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.

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.

Don’t be a Scrumbut

Don’t be a Scrumbut

Do you really use Scrum, do you follow Scrum as it is or you use Scrum, but you do a few things differently?

This is a new term which has made its entry in the past few years. If you ask anyone if they have ever used scrum for their organization or project.You will hear the response, yes, we use scrum, But we don't have Daily Standup as every team member is not available all days. Or let’s say this sprint was 2 week and the next sprint was for 5 weeks.

Or I hear, that the development team reports its status to the Scrum Master. Or in your retrospective, you are more worried about who rather than what, went wrong.

Scrumbut means, one who uses the word "but" when answering the question "Do you do Scrum?"

You will not be a scrumbut, if you pass this 12 point Scrum test:

1. Use short iterations; fix the sprint size to two to four weeks

2. Appoint a Scrum Master who will remove impediments

3. Have an ordered sprint backlog, before thesprint which will include 100% inventory of all work: be it feature, defects and all tasks

4. make sure that the entire team is jointly accountable for the success of the project.

5. Have a Sprint Planning workshop where the team commits to sprint goals and fine-grain features and get ready to start the sprint

6. Fine-grain features are broken into tiny tasks. If any task estimates are over 4 hours, break them down further.

7. Do Daily scrum meetings: and answer the questions what did you do, what are you going to do, what may be blocking you from completing your work and what do you need from other team members

8. Do not do anything that is not estimated and is not in the sprint backlog

9. Establish the Done Criteria, publish it to the team and Meet the Done Criteria for each story and the Sprint.

10. Track Sprint Backlog by using Burn-down chart or the Burn-up chart on a daily basis

11. Keep the product owner in the loop at all times.

12. Hold Sprint Review and Sprint Retrospective at the end of each sprint and work on what you can improve rather than fault finding.

Scrumbuts are the reasons why many scrum teams cannot take the full benefits of product development using Scrum.

Risk mitigation in Scrum

Risk Mitigation In Scrum

Scrum is a light-weight framework for project management which is used for complex product development in volatile market conditions. With high competition, companies have to develop products fast and innovatively always adding value and greater customer satisfaction. Quick decision-making and prioritization help mitigate risks in a project. The constant flow of new information changes requirements which Scrum is tailored to handle well and risks are turned into valuable deliverables.

The ProductOwner starts the Scrum cycle with identifying requirements of the client through a Stakeholder Meeting. It is up to the Product Owner to clearly outline the customer needs and place them in a Prioritized Product Backlog. Here risk plays a crucial role as it becomes essential to determine high risk elements and place them high in the backlog. The sooner these elements are identified and dealt with in early Sprints the better for the success of the project as the possibility of mitigating larger risks diminish with the progress of the project. Here the Product Owner plays a significant role in discussing various elements with the Scrum team and clarifying doubts. Thus the Product Owner gets a great deal of help from the Scrum Team in prioritizing requirements which the team in turn breaks down into definite User Stories and further into tasks.

The involvement of various stakeholders in the project with the technical personnel makes a mark in risk mitigation in Scrum. The “input-development-feedback” mechanism which is continuous in Scrum keeps everything transparent and pitfalls are readily visible. The Prioritized Product backlog is constantly groomed, i.e. it is analyzed and revaluated all the time as requirements change and/or issues crop up as development of a feature leads to finding a new element which demands immediate attention. Scrum as an Agile framework lets you do exactly that – be agile and incorporate changes in short notices. Scrum’s core principle of Empirical Process Control is thus practiced and upheld. In Scrum, planning is seen as an ongoing process and is represented by grooming of the Product Backlog and the Sprint Planning Meeting at the beginning of every Sprint. Unlike traditional waterfall methodologies where planning is detailed and upfront, this Scrum practice zeroes in on the risk factor. Yet, it is not to be taken for granted as active participation is required by the Product Owner, the Scrum master, and the Scrum Team to keep the mechanism running smoothly. Issues not addressed for long durations may turn into potential risks and take up more time and effort to resolve as time passes.

Some of the Scrum practices which help in mitigating risks are:

1. Flexibility of adding and modifying requirements

2. Regular feedback through the iterative nature of Scrum

3. Team ownership of Sprint Backlog items

4. Transparency ensures detection of risks and early communication

5. Iterative delivery reduces investment risk

In Scrum, it is important to learn and practice its basic principles which collectively and naturally help in effective management of risk.   

Scrum and Leadership Styles

Scrum and Leadership Styles

Leadership styles vary depending on the organization, the situation, and even the specific individuals and objectives of the Scrum project. The leadership style will determine the work culture of the team and also the behaviour of the Scrum Team members. Some common leadership styles are as follows:

Autocratic: Autocratic leaders do not delegate the powers to others and decision making powers are rested with the leader. They do not take the suggestions from others and compel others to follow their decision or orders. In this style of leadership, employees do not have any freedom to put forth their views.

Democratic: This leadership style is completely opposite of the autocratic style. Here, the leader is the representative of employees and is selected with the consent of all the team members. He takes suggestions, inputs and discuss with the team members before he takes the decision. However, the power remains with the leader and responsibility is delige=ated to the team members.  

Laissez Faire: The leader in this style of leadership is hardly interested in supervising the scrum team’s activity and their performance. The team members are left at large to perform and achieve the goals. In such style of leadership, the impediments faced by the team are not removed and this may lead to failure of the projects.

Servant Leadership—Servant leaders employ listening, empathy, commitment, and insight whilesharing power and authority with team members. Servant leaders are stewards who achieve results by focusing on the needs of the team. This style is the embodiment of the Scrum Master role.

Delegating: These leaders delegate the authority and responsibility to the team members. Team members can make the decisions and take the responsibility of their activities. This is done, when the leader feels that the members are competent enough to the decisions. Leader is invited to involve in the decision making if it is demanded by the situation.

Directing: Directing leaders in scrum team provide instructions to team members on each and every task need to be performed. This some time may reduce the confidence of the team members and they always expect the leader to guide them.

Assertive:Assertive leaders confront issues and display confidence to establish authority with respect.

The Servant Leadership style is the one that should be adopted in the Scrum Teams. This leadership provides enough powers to the Scrum team members to take decisions and also the team is held responsible for the success of scrum projects. This brings ownership to the team members are not restricted it to the leader. 

Scrum in Short

Scrum in short

Scrum is an agile methodology which is different than the traditional project management. It is an iterative approach which is appropriate for projects which are changing and have more emerging requirements. Here the project is worked on iterations wherein the team works with customer to outline the deliverables in each iteration and the whole team is responsible for the delivery of the project. This methodology is more popular in development of projects.

Project Iterations

The project iterations in Scrum can be as long as 4 weeks. At the end of each iteration, a part of the deliverable is completed. In order for successful delivery in iteration, customer feedback is required in every iteration. Scrum also stresses on collaboration within team and also between team and the customer. The attributes of a Scrum team is that they are cross functional and are responsible for the outcome of the iterations and of the project in whole.

Scrum requires the team to conduct Daily Stand up meetings which is time boxed to 15 minutes. The Planning, creating schedules and assigning of responsibilities are all finalized by the team members.

Important Roles – Scrum Master and Product Owner

There are two important roles in Scrum - the ScrumMaster and the Product Owner. The Scrum master can be considered as coach or mentor, enabling the team to use the Scrum process in the project in the most efficient way.

The Scrum Master is not to be mistaken as the project manager or the team lead. Since the team is responsible to make decisions collaboratively, the Scrum Master acts as a counsellor when required.

On the other hand, the Product Owner is not to be mistaken as customer who owns the deliverables when the project is completed. The Product Owner is expected to help the team in the creating the project deliverables as per customer requirements. If required product owner can also be the negotiator between the team and the customer. The Product Owner is also referred to as the voice of the customer.

Scrum for Small or Large Projects

Scrum is appropriate for high instable projects, and usually a typical Scrum teammay have around20 members. Scrum can be applied successfully to projects with a team bigger in size.In cases where the team is large the Project manager is required to coordinate with the team for effective communication. Though Scrum requires the team to be collocated in order to enhance the collaboration and for ease in conducting the daily meetings, it can still be used for teams that are geographically distributed.

Conclusion

Scrum enhances team productivity and collaboration , better customer satisfaction and less bureaucracy as the communication is done in daily scrum meetings individually.