Articles

Scrum Practices encompass a set of structured procedures and principles aimed at delivering projects more efficiently and effectively. These practices include defining roles such as Product Owner, Scrum Master, and Development Team, conducting regular events like Sprints, Sprint Planning, Daily Standups, Sprint Reviews, and Retrospectives, and utilizing artifacts such as Product Backlog, Sprint Backlog, and Increment. The SBOK™ Guide provides a comprehensive framework that ensures continuous improvement, collaboration, and iterative progress, fostering a productive environment for delivering high-quality products that meet customer needs.

The six domains of Agile are:

• Value-driven delivery
• Stakeholder engagement
• Boosting team performance
• Adaptive planning
• Problem detection and resolution
• Continuous improvement

Let’s discuss each domain in more detail.

Value-driven delivery

Creating value is at the core of any project, and Agile methods are designed with the core objective of delivering value on a knowledge worker project. While maximizing value, Agile also has tools and techniques to minimize risks that can erode value. Agile methods also place importance on the customer’s priorities and is designed to deliver elements that have the highest value to the customer first.

Assessing value –.

Planning value – We create a charter detailing the scope, objective, and other attributes of the project. We then use tools such as customer-valued prioritization, relative prioritization, and risk adjusted backlog while preparing the priority list. Which planning value, we also assess the contracting costs of the project.

Delivering value – After planning how we are going to deliver value, we focus on eliminating all activities that do not add value. We can use task and Kanban boards to schedule the backlog. Limiting the Work in Progress (WIP) reduces the potential for reworking and keeps the project going smoothly.

Confirming value – We have executed tasks and created value but is this what the customer wanted? We have to confirm the value we are delivering to know this. We demonstrate prototypes, simulate functionalities to help the customer test the product and see how they work.

Tracking and reporting value – It is not enough that we just deliver value. It is important that we regularly track the rate of delivery of value so that it can be communicated to business stakeholders. Cumulative flow diagrams and burn down graphs are an easy and informative way through which we can assess the development of the project.

Stakeholder engagement

Stakeholders in a project can be anybody who can negatively or positively impact a project. They can be business representatives, customers, the project manager, the development team, or external vendors contributing directly or indirectly to the project. Stakeholder engagement becomes important, because software development involves creating intangible products and the team must have a precise understanding of customer requirements.

Agile projects are subject to constant change which makes it essential that a clear and steady channel of communication is established. All stakeholders must be involved in the project to ensure that it stays on the right track. Teams can use tools such as wireframes, user stories, a user story backlog, and personas to verify their understanding of customer requirements.

Face-to-face communication is the most preferred method of communication on agile projects. They provide the maximum amount of information in the least amount of time. Information radiators such as burn down charts, cumulative flow diagrams, and velocity tracking charts allow us to determine progress of the project, which can be communicated to all the stakeholders.

Soft skills play an important role while engaging with stakeholders. Soft skills such as negotiating and active listening are necessary while dealing with customers. It is also essential that we be familiar with implementing soft skills such as facilitation methods, participatory decision models, and conflict resolution that are primarily concerned with managing teams.

When we talk of managing teams, our leadership skills play a crucial role. Servant leadership is an extremely effective way of leading teams. A servant leader encourages the team to excel by removing any obstacles, motivate and reward the team’s performance.

Boosting team performance

The third domain in Agile deals with boosting team performance practices. In software development, “people factors” incur the highest cost. Therefore, it is extremely important that we obtain the highest return on performance.

The process of forming a team is one of the determinants of success on a project. Building a team goes through the stages of forming (identifying potential team members and bringing them together), storming (the team collaborates and comes up with ideas), norming (teams form rules and normalize their working patterns), and performing (the team works together). During each of these phases, it is important for a leader to know when to play a supporting or directing role. For example, during the storming phase, conflicts can be frequent and the leader will have to step in to help the team members develop methodologies to resolve them.

To get the best out of a team, it should be self-organizing and self-directing. Allowing teams to be self-organizing and self-directing enables team members to manage complex tasks by themselves and figure out the best way to complete the tasks. This capitalizes on the team’s combined expertise and talent.

There are several activities that can help a team boost their performance on Agile projects. Daily stand-up meetings are a quick way to communicate the team’s performance status and identify present and potential issues. To overcome issues and improve continuously, teams might need to be mentored at different stages. During events such as iteration planning meetings or retrospectives, teams might need to be coached at a group level and mentoring can be provided for individual team members when the iteration is underway.

Brainstorming sessions can be used by teams to resolve issues, improve, and innovate processes. Because face-to-face communication is the ideal way to communicate on Agile projects, it is important that the team be located in a common area with space for whiteboards and other information radiators.

Adaptive Planning

Because extensive planning before the project is undertaken can be cumbersome and often does not add any real value, Agile calls for an adaptive approach to planning. Adaptive planning involves creating a basic plan and updating it as the project gets underway. Adaptive planning requires practitioners to maintain close collaboration with the customer to understand his or her requirements more accurately. Collaborative games such as remember the future, prune the product tree, buy a feature, and bang-for-the-buck can be used to help the development team understand customer requirements better.

To make timely deliveries, team members should calculate their estimates as accurately as possible factoring in all diversions and constraints. Wideband Delphi and Ideal Time are some of the techniques which can help teams arrive at an accurate estimate. While estimating the cost of the project, the figures should be presented in ranges as they seem more credible than pin-point figures that can have an air of false confidence.

Iteration and release planning is a vital part of adaptive planning. Releases are bundles of functionality that can be delivered to a customer. While planning a release, the Product Owner/manager, development team, and Agile Expert can use a velocity chart to determine how many features can be completed by the team in a given time.  While planning iterations, it important to have a fixed priority list at the beginning of the planning session. Team members have the final say on how much work can be completed, while the product owner gets the final say on the priority of the items included for the iteration. Availability of team members needs to be factored in while planning iterations.

Problem Detection and Resolution

A common saying is, “A stitch in time saves nine,” and this couldn’t be more apt to explain how Agile methods deal with problems. If ignored, problems can have a devastating effect on the project as they not only increase the burden of rework; they make the team fall behind in its plans. It is a double whammy for the team when this happens as it takes twice the resources. Agile practices aids in detecting problems as early as possible and fixing them while they are still small.

Detecting problems is the first step to resolving them. Daily stand-up meetings are an excellent way to identify any issues that team members are facing.  Teams can also track issues by calculating cycle times for tasks. If the cycle time is too high, it might indicate a potential problem or that the team has undertaken more work than it can complete. Limiting work in progress can help monitor the project timeline better and track problems more easily. Despite our best efforts, some defects may make their way through to the final product. Escaped defects are the most expensive to fix. Teams can track escaped defects on a graph to analyze trends. This can help refine quality control processes.

Alistair Cockburn describes “failure modes and alternatives,” that are related to the human aspect of performance. Cockburn says that people fail because they can be inconsistent at following a technique, are creatures of habit and prefer to invent new ways than modify existing reliable methods. To counter “failure modes” Cockburn advises that teams should inculcate discipline, receive feedback regularly, and assign work based on personalities of individual team members.

Resolving issues that are identified is the next step. Continuous integration of new code, as and when it is developed, in a repository can help overcome the issues that we find with integration. Validating progress at frequent intervals and at different levels can help us be confident that our work is error-free.

In software development, commonly used techniques are Test-Driven Development (TDD) and Acceptance Test-Driven Development (ATDD). These methods primarily involve writing the tests before any code is written. The codes are written until they pass the tests. Codes might then be “refactored” if necessary, which involves refining the design without altering its behavior.

Continuous Improvement

New insights and learning gained on a traditional project is typically gathered at the end of the project cycle. These insights might not be of much help on the next project unless the two are very similar. That learning could have had more value, if it had been used on the project in which it was learned. Agile methodology seeks to continuously improve throughout the project and encourage applying lessons to the development process as and when we learn it. Retrospectives at the end of each iteration makes the lessons learned available for the very next iteration.

A retrospective typically lasts for about two hours during which time the team gathers data about the different challenges that it faced and the various lessons learned while solving them. The learning is analyzed to see if there exists underlying patterns or any insights. Armed with these patterns and insights, the team plans the next iteration.

As part of continuous improvement, team members should be encouraged to share knowledge they acquire, with other team members. One of the reasons colocation is stressed in Agile projects is because it provides a platform for knowledge sharing through face-to-face communication. To encourage knowledge sharing, team velocity can be tracked at a team level rather than measuring it at an individual level, so that team members are motivated to help each other.

We might be required to tailor agile practices to suit our needs; however, one must careful while doing so. Agile practices have been crafted into a delicate web of interdependent practices and disturbing one can affect other practices. We should be adept at using agile practices before we make any modifications. It might be tempting at times to blame the tools if our work is not going accordingly when the real problem lies in us. We should carefully examine our motives to change practices before we make any alterations.