Principles of Scrum: A Brief Introduction

Principles of Scrum: A Brief Introduction

“I love those who can smile in trouble, who can gather strength from distress, and grow brave by reflection.’Tis the business of little minds to shrink, but they whose heart is firm, and whose conscience approves their conduct, will pursue their principles unto death.” – Leonardo da Vinci, famous artist, sculptor, architect, anatomist and botanist.

Principles have no real force except when one is well-fed. – Mark Twain, American author

Just as persons achieve their goals in life because of following their principles to the core, similarly, SCRUM also focuses on its core set of principles which is firmly based on its framework to get the positive outcome. One of the biggest advantages of implementing SCRUM is that it can be theoretically and practically implemented in any kind of project or organization and all the principles should have been mandatorily adapted in order to confirm the correct application of SCRUM.

Although Scrum processes can be suitably modified in order to meet the requirements of the project, or that of the organization which uses principles of SCRUM, it must be understood that the principles are non-negotiable and must be applied as per the guidelines. The reason for maintaining the principles and using them as per the required standards are that it gives confidence to the user.

 The Principles of SCRUM are applied for the below mentioned aspects:

  • Programs, portfolios and/or projects in industries or organizations (any type)
  • Products, services or any other results that have to be delivered to stakeholders (customers, users)
  • Projects that are irrelevant of size/ or having complex issues (a project can range from one with short duration or that has few number of team members to large projects with challenging issues and few hundred team members)

The Principles of SCRUM can be divided into:

Roles Guide: This part mainly focuses on the type of section/subsection which is suited for any of the core SCRUM roles of Product Owner, Scrum Master and the Scrum Team.

Empirical Process Control: This part is important as it defines the first principle of SCRUM and the three important ideas of transparency, inspection and adaptation.

Self-organization: This part is important as it focuses on the second principle of SCRUM highlighting on the staff members who can offer higher productivity in services when they are properly organized by means of team spirit and self-ownership of a project. This mainly focuses on the new and artistic, ingenious environment which is more favorable for growth.

Collaboration: The third part which focuses mainly on product development as a shared value-creation process. For this process to be successful, all the stakeholders should work and interact together in order to deliver the greatest value.

Value-based Prioritization: Known as the fourth section in the principles of SCRUM, it mainly concentrates on the framework of SCRUM in order to provide the optimum business value in the least possible time.

Time-Boxing: after the four principles of SCRUM, this section treats time as a limited constraint.

The other two principles are Iterative Development and SCRUM vs. Traditional Project Management

Self-organizing and meddling Stakeholders

Self-organizing and meddling Stakeholders

Any Scrum Master worth his Scrum Master certification believes that all humans are enthusiastic and seek to receive greater duty. So, they deliver much greater value when self-organized. This self-organization is what created us from single celled beings. A Scrum Master brings working deliverables sooner and makes available more precise predictions of timetable and budget compared to traditional waterfall Project Managers. Under Scrum, if we plan a ten-month project and divide the effort into twenty, fortnight sprints;  at the end of sprint #5 (25 % into the project), we would have completed five iterations of development. In the equivalent period a waterfall project would have generated a stack of specifications and authorization forms, and Scrum would have created five packages of confirmed, shippable deliverable. All this is majorly because the Scrum team feels empowered.

One important aspect that no scrum master certification training deals with. It is about managing the Stakeholder participation. External stakeholders have a completely valid interest in the success of a project and conversely, the project team cannot work effectively without their contributions. Even if Scrum team members know how to outline and deliver project features, useful deliverables cannot be developed without the involvement of the executives, managers, and the other stakeholders that the team serves. The irony is that most senior folk, especially in our country are overeager to “leave their mark”. In their over eagerness, the following behavior is exhibited.

  • Statements like “This is how we do it Here!” are heard
  • External stakeholders talk in the daily standup meetings
  • Status information demanded outside Sprint Planning Meetings
  • Scrum Masters, Product Owners or Project Sponsors receive requests from their superiors to “Correctly” guide the Scrum team

Because of this distraction, the Scrum Master is not concentrating 100 percent on team and organizational obstructions and processes. Product backlog wastes away and/or is passed over. If the product owner is coerced by these stakeholders, features get selected or priorities substituted outside of sprint planning meetings ignoring the backlog. The Product Owner may start imposing improper assessments regarding risk.

While inappropriate outside influence can be exerted at any point in a sprint, it is most visible when external stakeholders over participate in daily project activities, especially the daily standup meetings. This is also the place where the Scrum master can most effectively stage an intervention by consistently putting into effect the “Silence rule” for external Stakeholders: Undeniably, there may be that one justified remark that gets lost. But it will lead to others and then there will be no easy place to draw the line. Again, we should remember that we are dealing with superiors who have learnt to intimidate subordinates to get their obedience. Scrum masters can also Conduct Scrum training to External Stakeholders in part start of a project and try to convince the Stakeholders why their comments would be counterproductive.

Quality in Scrum

Quality in Scrum

Quality control refers to the execution of the planned quality activities by the Scrum Team in the process of creating deliverables that are potentially shippable. It also includes learning from each set of completed activities in order to achieve continuous improvement. Within the cross-functional team, it is important to have the skills necessary to perform quality control activities. During the Sprint Retrospect Meeting, team members discuss lessons learned. These lessons act as inputs into continuous improvement and contribute to the improvement of ongoing quality control.

Quality is required not only in products, but also in processes. Quality assurance refers to the evaluation of processes and standards that govern quality management in a project to ensure that they continue to be relevant. Quality assurance activities are carried out as part of the work. In fact, quality assurance is a significant factor of the definition of the done. The deliverable isn’t complete if appropriate quality assurance has not been conducted. Often, quality assurance is demonstrated during the Sprint Review Meeting.

Product Owners for respective projects, programs and portfolios can monitor and evaluate quality assurance activities to ensure each team continues to agree and comply with the quality standards that have been set. End-to-end quality assurance may be addressed during final testing of the product, a Release, or a Sprint. A comparison of the number of issues encountered versus the number of User Stories completed can be done. The product components that have defects can be incorporated as Prioritized Product Backlog Items (PBIs), which can be worked upon by either the team or by one person at certain times during the Sprint, depending on the number of defects.

At times, the Scrum Guidance Body can define the process and documents that can be referred to by the Scrum Teams when doing their projects to ensure that uniform quality norms are followed by all projects within the company.

Roles of Scrum Developers in Scrum Project

Roles of Scrum Developers in Scrum Project

Scrum developers, also referred to as the development team or Scrum team, are responsible for developing the product and they possess all the essential skills required to carry out the work of the project. They have a high level of collaboration to maximize productivity, so that minimal coordination is required to get things done. To minimize dependency, team members are experts in chosen domain, but also possess basic knowledge and skills about other domains.

Some of the key responsibilities of Scrum developers which they are required to fulfill in any Scrum project are:

  1. Provides inputs for creation of the Collaboration Plan and the Team Building Plan
  2. Ensures a clear understanding of Epic(s) and Personas
  3. Understands the User Stories in the Prioritized Product Backlog
  4. Agrees with other Scrum Core Team members on the Length of Sprint
  5. Seeks clarification on new products or changes in the existing products, if any, in the refined Prioritized Product Backlog
  6. Provides inputs to the Product Owner on creation of User Stories
  7. Estimates User Stories approved by the Product Owner
  8. Commit User Stories to be done in a Sprint
  9. Develops Task List based on agreed User Stories and dependencies
  10. Estimates effort for tasks identified and if necessary, updates the Task List
  11. Develops the Sprint Backlog and the Sprint Burndown Chart
  12. Creates Deliverables
  13. Identifies risks and implements risk mitigation actions, if any
  14. Updates Impediment Log and dependencies
  15. Updates Burndown Chart, Scrumboard, and Impediment Log
  16. Discusses issues faced by individual members and seeks solutions to motivate the team
  17. Identifies risks, if any
  18. Submits Change Requests, if required
  19. Participates in Prioritized Product Backlog Review Meetings
  20. Provides inputs to Scrum Master for Scrum of Scrums Meetings
  21. Demonstrates completed deliverables to the Product Owner for approval
  22. Identifies improvement opportunities, if any, from the current Sprint and agrees on any actionable improvements for the next Sprint
  23. Participates in the Retrospect Project Meeting

Leadership Style

Leadership Style

Leadership style vary depending on the organization, the situation, and even the specific individuals and objective of the Scrum project. Some common leadership styles are as follows – Autocratic, Democratic, Laissez-faire, Transactional, Task oriented, Assertive, servant leadership.

Autocratic: This kind of leaders maintain strict, close control on followers by keeping close regulation of policy’s. They believe in direct supervision is the key in maintaining a successful environment. This kind of leadership is used in rare occasions.

Democratic: Leaders falling under this category share the decision-making abilities with group members. This is done by promoting the interests of the group members and by practicing social equality. This leadership incorporates discussion, debate and sharing of ideas and reassurance of people to feel good about their involvement. As per many research this leadership style is one of the most effective and creates higher efficiency, better contributions from group members and increased group morale. This leadership style could lead to better ideas and more creative solutions to problems because the group members are encouraged to share their thoughts and ideas. Though democratic leadership is considered as one of the most effective leadership styles, it does have some disadvantage. It is not suitable in situations where roles are unclear or time is of the essence, as this kind of leadership can lead to communication failures and uncompleted projects. Democratic leadership is most suited in situations where group members are skilled and eager to share their knowledge.

Laissez-faire: Under this leadership style all are provided with the rights and power to make decisions. i.e. the decision making power is fully given to the workers. The laissez-faire style is also called as a “hands off” leadership style because the leader delegates the tasks to their followers while providing little or no direction to the followers. These kinds of leaders let followers to have complete freedom to make decisions with regards to the completion of their work. It enables followers a high degree of autonomy and self-rule and also  offering guidance and support when requested. The laissez-faire leader using guided freedom provides the followers with all materials necessary to accomplish their goals, but does not directly participate in decision making unless the followers request their assistance.  This style is not advised to be used when

a)      the followers feel apprehensive at the inaccessibility of a leader

b)      when the leader  do not provide steady feedback to their followers

Ther four leadership styles are Transactional, Task oriented, Assertive, servant leadership.

Transactional: This leadership style was first described by Max Weber in 1947 and later in 1981 it was described by Bernard Bass. This is mainly used by the management.  This kind of leaders focuses their leadership on motivating their employees through rewards and punishments system. There are two factors in this system: 1) Contingent Reward and 2) management-by-exception.

Contingent Reward: This kind of rewards could be materialistic or psychological, to recognizes the good performance of the employee(s).

Management-by-Exception: allows the leader to maintain the status quo. The leader comes in action when the employee(s) do not meet the benchmark.

Task oriented:  Task-oriented leaders enforce task completion and adherence to deadlines.  These leaders are typically less concerned about the employees, but  more with finding the step-by-step solution to reach goals. The advantage for having this kind of leader is that it ensures that the jobs are completed on time.

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

Servant leadership: Servant leaders use listening, empathy, and insight while sharing power and authority with team members.  Traditional leadership style is based of power by one at the “top of the pyramid.” So whoever is on the top has the control or the decision making power.

The term servant leadership was actually created by Robert K. Greenleaf.  The Characteristics of being a servant leader are as follows:

Listening: A servant leader should show importance on listening to others.

Empathy: He should understand others’ feelings and point of view.

Healing: A servant leader encourages each person’s emotional and spiritual health and wholeness.

Awareness: A servant leader understands his or her own values, feelings, strengths and weaknesses.

Persuasion: A servant leader influences others through their expression.

Conceptualization: A servant leader should have the ability to integrate between the present realities and the future possibilities.

Foresight: A servant leader should have a great instinct about how the past, present, and future are connected.

Commitment to the growth of people: A servant leader should not think about his personal growth in the organization, he or she is equally responsible for serving the need of others too.

Building community: A servant leader is to help create a sense of community among people.

How to conduct effective daily scrum

The Ideal Daily Scrum

The Scrum Master enables the Daily Scrum meeting. His work is to gather the team and Product Owner together, and derive from each team member three pieces of information:

• Tasks done since previous Daily Scrum
• Tasks planned to be done before the next Daily Scrum
• What are the hurdles faced which requires assistance?

The purpose of this meeting is not to solve issues but to familiarise the team with the current situation in the project and also to request for collaboration to handle the issues. Resolving issues would be discussed after the meeting, when the team involved in the project are brought together for this purpose.

The Daily scrum meeting is time boxed to 15 minutes.

Daily Scrum Meetings for Distributed Teams

These daily scrum meetings are very tedious to arrange when team members are not located in the same place. In such cases, meetings can be arranged using teleconference facilities, web conference and video conference.

Coping with Time-Zone Differences

Teams that stay in different time zones have more difficulty in arranging for a Scrum Daily stand up meeting. Below are few useful ways of handling a scrum daily stand up in different time zones:

• Arrange for daily stand ups such as selecting one site with fewest members which face some inconvenience with the time.
• You can try daily scrum for different sites which the Scrum Master records.
• Instead of short scrum meetings, you can have a weekly twice meetings.

The above mentioned methods do have their pros and cons. But again there is no one suitable way of collaborating with people who work in different time zones. It would be better to find a common ground between teams located in different time zones.

Coping with Language Differences

When teams are working across many geographies, having daily scrum maybe difficult when they don’t share any common language.

Tips for handling language differences include:
• Hiring a local facilitator who speaks both languages who can also guide or interpret as necessary
• All team members submitting their information by writing in advance, for review and discussion at the meeting
Above discussed methods help in conducting the daily scrum in a widely distributed world.

Preparing the pilot team

In addition to providing mentoring to the pilot team during the project, you also need to prepare the team in other ways. You need to train the pilot team on agile practices and principles, and provide a method for feedback during the pilot.

Ensure everyone is trained on agile

The untrained pilot-team members go through a process similar to that followed by the core team. They need an overview of why the company is pursuing agile, training on the agile principles, and an understanding of the process they’re to use on the pilot. If possible, have your agile coach provide the pilot team’s training, with core-team members contributing to the discussions. This process training takes one or two days and is slightly different for the pilot team. In addition to the fundamental principles and practices of agile, they also need training on how the core team has represented those principles in the custom methodology. For example, they need to see how the core team’s new process supports the agile principle of customers and developers working together daily. If core-team members are attending the fundamentals training with the pilot team, they can show the pilot team how the principles are reflected in the custom methodology. You should expect the untrained team members to have some cynicism and negativity related to using the new process. Their concerns usually relate to the following:

■ A misunderstanding of agile principles.

■ A belief that the current process works fine —Project team members may be unaware of the issues that the new methodology addresses.

■ Lack of detail in the agile process —In the past, you may have prescribed every step in the development process. Now, the team is asked to participate in selecting the processes that add the most value, and that can be a shock. If your environment has been controlling in the past, the last item will take time to resolve. Agile doesn’t assign employee A to do step B; it tells the employee to deliver value to the customer as quickly as possible and provides tools and processes to reach that goal. The team works together to determine logical steps and assignments during the project. No matter what the feedback is, listen to the pilot team with an open mind. Where applicable, show them how the new design takes their concerns into account. You may receive enough feedback from pilot-team members to tempt you to make another update to the methodology. But unless the feedback identifies a showstopper, we suggest holding off on any changes—the pilot will provide plenty of feedback, and you can incorporate the pilot-team feedback when the pilot project is complete.

Providing a mechanism for feedback

When the pilot project kicks off, you need to provide a way to gather feedback from the pilot team. The best way to do this is to invite them to the weekly core-team meetings and give them the floor. The core team can listen, see how the methodology is working, and provide guidance to the pilot team. You should expect some apprehension from the pilot team during the first few meetings. The pilot team knows they’re providing feedback to the group that customized the methodology. Do your best to create an environment where egos are checked at the door and the pilot team feels comfortable sharing their feelings.