Articles

Confirming Benefits, the Scrum Way!

It is not the delivery of project’s outputs that determines the success or failure of a project but the delivery of the project’s benefits. In this piece of writing, let’s try to understand Scrum’s approach to realization and confirmation of expected benefits of a project.

Throughout a project, it is important to verify whether benefits are being realized. Whether the products of a Scrum project are tangible or intangible, appropriate benefit realization planning and verification techniques are required to confirm that the project deliverables with benefits and value are being created by the Scrum team members. So a well-structured benefit realization plan helps the teams map benefits of individual projects to the overall programme and corporate strategic objectives.

This also helps in tracking the identified benefits even after completion of Scrum project and handover of deliverables.

At the beginning of the project, all the project outputs, outcomes and benefits expected by the user groups and other key Business stakeholders should be identified and documented. And a means of measuring benefits, key responsibilities and accountabilities associated with benefits, time of benefit realization, etc. should also be agreed. At pre-determined intervals, the team should review the benefit realization plan to assess the status of expected benefits and to incorporate any changes in the forecast of realization of benefits.

Now, let’s look at some of the ways of confirming benefits. Some useful techniques are use of prototypes, simulations, workshops, demonstrations etc. Demonstrating prototypes to customers and simulating their functionalities are commonly used techniques for confirming value.

Often,after using the features or having them demonstrated, customers can more clearly determine whether the features are adequate and suitable for their needs. They might realize a need for additional features, or may decide to modify previously defined feature requirements. In product development, this customer experience has come to be known as IKIWISI (I’ll Know It When I See It).

Through demonstrations or access to early iterations, customers can also evaluate to what degree the team has successfully interpreted their requirements and met their expectations.

To some degree we all live with uncertainty. We have no control over the future. Yet we carry on, we persevere, because, I guess, it’s the way we’re made.” – Karen Walker Thompson

When many of us think of risks, we think of a child’s roller skate left on the front doorstep or the possibility of a hover board catching fire under one’s feet. As serious as these two examples are, businesses often face risks that impact many more people.

Risk is defined as an uncertain event—or set of events—that can affect the objectives of a project and may contribute to its success or failure, according to A Guide to the Scrum Body of Knowledge (SBOK™). In business and project management, risks can be positive or negative. Risks that are likely to have a positive impact on the project are referred to as opportunities whereas those that could affect the project in a negative manner are called threats.

Opportunities can turn negative over time—sometimes faster than one would think. Sean Connery, the actor famous as the quintessential James Bond, had the opportunity to play the role of Gandalf in Peter Jackson’s The Lord of the Rings trilogy. He passed on the role that earned Ian McKellen an Academy Award nomination. Likewise, Will Smith avoided an uncertain event by turning down the role of Neo in The Matrix. Keanu Reeves took it on and remained in the role as it became a modern Hollywood franchise. As Joel Barker points out, Swiss watch makers in the 1980s snubbed the opportunity to go to quartz and missed out on the largest expansion of the watch market in history. This ability of missed opportunities to represent lost benefits is probably what puts them in the risk category.

Managing risk must be done proactively, and in Scrum it is an iterative process that should begin at project initiation and continue throughout the project’s lifecycle. The process of managing risks should follow some standardized steps to ensure that risks are identified, evaluated and a proper course of action is determined and acted upon accordingly.

Standardized Risk Management typically consists of five steps:

1. Risk identification
2. Risk assessment
3. Risk prioritization
4. Risk mitigation
5. Risk communication

The SBOK™ says that risks should be identified, assessed and responded to based on two factors: the probability of each risk’s occurrence and the possible impact in the event of such occurrence. Risks with a high probability and impact value should be addressed before those with a relatively lower value. In general, once a risk is identified it is important to understand its probable causes and the potential effects if it occurs.

In a Scrum environment, risks are generally minimized, largely due to the work being done in Sprints whereby a continuous series of deliverables is produced in very short cycles. The deliverables are compared to expectations in the Sprint Review meeting, and the Product Owner—who is responsible for seeing that the project delivers real business value—is actively engaged throughout each Sprint and the entire project.

Even in the simplest of projects, things can go wrong. So it is important to have a strategy to identify and manage risks and keep your feet out of the fire.

Scrum framework requires a change in mindset from traditional methods. The central focus has moved from the scope in Waterfall methods to achieving maximum business value in Scrum. While in Waterfall, cost and schedule are altered to ensure the desired scope is achieved, in Scrum, quality, and constraints can be altered to achieve the main objective of attaining maximum business value.

The Waterfall model is suitable for ordered and predictable projects in which all the requirements are clearly defined and can be estimated accurately, and in most industries, such projects are dwindling. Changing requirements from customers have led to increased pressure on businesses to adapt and change their delivery methods.

Scrum methods are more successful in the current market, which is marked by unpredictability and volatility. Scrum methods are based on inspect-adapt cycles as opposed to the command and control structures of the Waterfall method.

Scrum projects are completed in an iterative manner wherein the functionalities with the highest business value are completed first. Various cross-functional teams work in parallel across Sprints to deliver potentially shippable solutions at the end of every Sprint.

Because each iteration results in a shippable solution (which is a part of the overall product), there is a measurable objective that the team has to accomplish. This ensures that the team is progressing and the project will be completed on time. Traditional methods do not present such timely checks and, therefore, result in situations in which the team might get off schedule and end up with a lot of work toward the end.

As the customer regularly interacts with the team, the work completed is regularly reviewed; thus, there is assurance that the progress is per customer specifications. However, in Waterfall, there is no such interaction as the work is carried out in silos, and there is no presentable functionality until the end of the project.

In complex projects, where the customer is unclear about what they want in an end product and functionality requirements keep changing, the iterative model is more flexible in ensuring that these changes can be included before the project is complete.

However, when completing simple projects with well-defined functionalities, and when the team has previous experience completing such projects (therefore, estimation would be accurate), the Waterfall method can be successful.

Given below is a table to get a better idea about the differences between Scrum and Waterfall.

If you have heard of Agile, then you have probably also heard of DSDM, or Dynamic System Development Method. These project management methodologies have a lot in common.

But what is DSDM? To answer this question, we will need to talk about birds. I know that may sound silly, but I promise I am not getting off track here.

DSDM is often associated with the Arctic Tern. An Arctic Tern is a seabird known for its migration between the north and south poles. True to its behavioural traits, the Arctic Tern is a symbol of free movement, unyielding energy, adaptability and collaboration. That is probably why one of the most widely used Agile project development frameworks is named after this bird.

DSDM is known for providing best practices for in-budget and on-time delivery of working software.  DSDM was first conceived in 1994 as a more structured and disciplined approach than its predecessor, Rapid Application Development, or RAD. RAD is an iterative software development approach that uses minimum planning in favor of rapid prototyping. However, this approach was highly unstructured and chaotic. This is because there was no fixed definition of processes and techniques. As such, everyone had different interpretations of the system. So, software professionals from various companies came together and formed the DSDM Consortium with the aim of developing a development approach that could serve as a possible replacement for the unstructured RAD. Combining industry-acknowledged best practices, the group introduced DSDM, which embodies an iterative and incremental development approach. Euro Truck Simulator 2 Mac

Now, what does “iterative and incremental development” mean?

In the simplest terms, the entire project plan is broken down into small chunks of work known as features or jobs. The team will create features based on business value and priority. Each feature is developed one by one following pre-planned developmental activities such as designing, coding, testing, and integrating. After a feature is delivered to the actual production scene, it is evaluated by the client. Based on the client’s impression of the feature coupled with the latest business demands and requirements, the client provides feedback. This feedback is taken into account when planning the next developmental cycle. In this way, software is developed in time-boxed iterations. Then, the software is refined with each iteration, because additional features get incorporated into the overall software. In this manner, the team is able to develop features that are functional and relevant.

Does following an iterative and incremental development model benefit both the team and the client?

DSDM is defined as a developer-centric development framework for both on-time and in-budget delivery of user-valued and quality-controlled project features. Based on this definition, DSDM is also client friendly. This is because DSDM encourages active user involvement and close collaboration between stakeholders and the technical team. Business Stakeholders possess a better picture of the functional purpose of the software, so they impart this knowledge to the technical team members who are experts in developing software. DSDM suggests different ways to promote cooperation between the two groups. First, stakeholders and technical team members should meet to discuss requirements and functionalities to enhance mutual understanding. Second, project review meetings are held at the end of each iteration in which stakeholders provide feedback and inform the development team of any new requirements or business demands. Based on this feedback, the development team plans the next iterations.

Being an Agile development approach, DSDM doesn’t define tools and processes at the start of the project, but does set parameters such as cost, quality and time. The project deliverables are adapted to fulfill the set criteria. This is done by prioritizing the deliverables following the MoSCoW technique; that is, must haves, should haves, could haves and won’t haves. This is both developer and client friendly, because the client gets features developed according to value and priority, and the developers are free to mould the process to deliver software that is both technically innovative and fit for the business’s purpose.

The development teams are self-organizing, empowered and highly coordinated. DSDM encourages open communication among team members so that there is free exchange of information. And, DSDM believes in building teams that can make quick decisions, because software development is an ever-changing industry.

These principles are good, but who puts them in action?

DSDM defines 15 specific roles. The main roles are executive sponsor, visionary, ambassador user, advisor user, project manager, technical coordinator, team leader, developers, designers, programmers, testers and analysts.

In conclusion, it can be said that DSDM is a relevant and effective approach to managing software development projects.

Technical debt — also referred to as design debt or code debt—refers to the work that teams prioritize lower, omit, or do not complete as they work toward creating the primary deliverables associated with the project’s product. Technical debt accrues and must be paid in the future.

Some causes of technical debt can include the following:

• Quick-fix and building deliverables that do not comply with standards for quality, security, long-term architecture goals, etc.
• Inadequate or incomplete testing
• Improper or incomplete documentation
• Lack of coordination among different team members, or if different Scrum Teams start working in isolation, with less focus on final integration of components required to make a project or program successful
• Poor sharing of business knowledge and process knowledge among the business stakeholders and project teams
• Too much focus on short-term project goals instead of the long-term objectives of the organization. This oversight can result in poor-quality Working Deliverables that incur significant maintenance and upgrade costs.

This oversight can result in poor-quality Working Deliverables that incur significant maintenance and upgrade costs. IIn Scrum projects, any technical debt is not carried over beyond a Sprint, because there should be clearly defined Acceptance and Done Criteria. The functionality must satisfy these criteria to be considered Done. As the Prioritized Product Backlog is refined and User Stories are prioritized, the team creates Working Deliverables regularly, preventing the accumulation of significant technical debt. The Scrum Guidance Body may also include documentation and definition of processes which help in decreasing technical debt.

To maintain a minimal amount of technical debt, it is important to define the product required from a Sprint and the project along with the Acceptance Criteria, any development methods to be followed, and the key responsibilities of Scrum Team members in regards to quality. Defining Acceptance Criteria is an important part of quality planning and it allows for effective quality control to be carried out during the project.

Technical debt is a very big challenge with some traditional project management techniques where development, testing, documentation, and so on are done sequentially and often-times by different persons, with no one person being responsible for any particular Working Deliverable. As a result, technical debt accrues, leading to significantly higher maintenance, integration, and product release costs in the final stages of a project’s release. Also, the cost of changes is very high in such circumstances as problems surface in later stages of the project. Scrum framework prevents the issues related to technical debt by ensuring that Done deliverables with Acceptance Criteria are defined as part of the Sprint Backlog and key tasks including development, testing, and documentation are done as part of the same Sprint and by the same Scrum Team.

Recently Scrum has gained immense popularity and attention among the management and development methodologies. So let us see what a Scrum Project is all about.

A Scrum project involves a collaborative effort to create a new product, service, or other result as defined in the Project Vision Statement. Projects are impacted by constraints of time, cost, scope, quality, resources, organizational capabilities, and other limitations that make them difficult to plan, execute, manage, and ultimately succeed. However, successful implementation of the results of a finished project provides significant business benefits to an organization. It is therefore important for organizations to select and practice an appropriate project management approach.

Scrum is one of the most popular Agile frameworks. It is an adaptive, iterative, fast, flexible, and effective framework designed to deliver significant value quickly and throughout a project. Although, the Scrum framework as defined in the SBOK® Guide is primarily used to deliver projects and create products, Scrum may also be used to manage the continuous maintenance of products and services, to track issues, and to manage changes. Scrum ensures transparency in communication and creates an environment of collective accountability and continuous progress. The Scrum framework, as defined in the SBOK® Guide, is structured in such a way that it supports product and service development in all types of industries and in any type of project, irrespective of its complexity

A key strength of Scrum lies in its use of cross-functional, self-organized, and empowered teams who divide their work into short, concentrated work cycles called Sprints. Figure 1-1 provides an overview of a Scrum project’s flow.

The Scrum cycle begins with a Stakeholder Meeting, during which the Project Vision is created. The Product Owner then develops a Prioritized Product Backlog which contains a prioritized list of business and project requirements written in the form of User Stories. Each Sprint begins with a Sprint Planning Meeting during which high priority User Stories are considered for inclusion in the Sprint. A Sprint generally lasts between one and four weeks and involves the Scrum Team working to create potentially shippable deliverables or product increments. During the Sprint, short, highly focused Daily Standup Meetings are conducted where team members discuss daily progress. The Product Owner can assess completed deliverables during the Sprint and can accept the deliverables that meet the predefined Acceptance Criteria. Toward the end of the Sprint, a Sprint Review Meeting is held during which the Product Owner and relevant business stakeholders are provided a demonstration of the deliverables. The Sprint cycle ends with a Retrospect Sprint Meeting where the team members discuss ways they can improve the way they work and their performance as they move forward into the subsequent Sprint.

At the program or portfolio level, there is normally a smaller number of requirements/user stories than at the project level. The percentage of user stories with a very tangible value/business need/user impact is normally much lower than on project level. That means that the selection of techniques that are useful at a program or portfolio level will be smaller. For example, Kano analysis has limitations because there won’t be any dis-satisfiers or exciters. Without a significant number of stakeholders, especially users, the 100-point method has limited value. The MoSCoW technique also has limitations because there won’t be any “nice to have” or “Won’t have” features at program and portfolio levels.

Some techniques used to prioritize the User Stories or requirements in the Prioritized Product Backlog, on the basis of business value are presented below:

• MoSCoW Prioritization scheme—The MoSCoW prioritization scheme derives its name from the first letters of the phrases “Must have,” “Should have,” “Could have,” and “Won’t have”. This prioritization method is generally more effective than simple schemes. The labels are in decreasing order of priority with “Must have” User Stories being those without which the product will have no value and “Won’t have” User Stories being those that, although they would be nice to have, are not necessary to be included.

• Paired Comparison—In this technique, a list of all the User Stories in the Prioritized Product Backlog is prepared. Next, each User Story is taken individually and compared with the other User Stories in the list, one at a time. Each time two User Stories are compared, a decision is made regarding which of the two is more important. Through this process, a prioritized list of User Stories can be generated.

• 100-Point Method—The 100-Point Method was developed by Dean Leffingwell and Don Widrig (2003). It involves giving the customer 100 points they can use to vote for the User Stories that are most important. The objective is to give more weight to the User Stories that are of higher priority when compared to the other available User Stories. Each group member allocates points to the various User Stories, giving more points to those they feel are more important. On completion of the voting process, prioritization is determined by calculating the total points allocated to each User Story.

• Kano Analysis – The Kano analysis was developed by Noriaki Kano (1984) and involves classifying features or requirements into four categories based on customer preferences:

1. Exciters/Delighters: Features that are new, or of high value to the customer
2. Satisfiers: Features that offer value to the customer
3. Dissatisfiers: Features which, if not present, are likely to cause a customer to dislike the product, but do not affect the level of satisfaction if they are present
4. Indifferent: Features that will not affect the customer in any way and should be eliminated

Interestingly, features usually move down the classification list over time; customers will come to expect features (e.g., cameras on phones) and these features will move from being exciters/delighters to satisfiers and eventually to dissatisfiers.

At the program or portfolio level, there is normally a smaller number of requirements/user stories than at the project level. The percentage of user stories with a very tangible value/business need/user impact is normally much lower than on project level. That means that the selection of techniques that are useful at a program or portfolio level will be smaller.

How is the Retrospect Sprint Meeting related to the ‘inspect-adapt’ aspect of Scrum? The Retrospect Sprint Meeting is an important element of the ‘inspect-adapt’ Scrum framework and it is the final step in a Sprint. All Scrum Team members attend the meeting, which is facilitated or moderated by the Scrum Master. It is recommended, but not required for the Product Owner to attend. One team member acts as the scribe and documents discussions and items for future action. It is essential to hold this meeting in an open and relaxed environment to encourage full participation by all team members. Discussions in the Retrospect Sprint Meeting encompass both what went wrong and what went right.

The primary objectives of the meeting are to identify three specific things:

1. Things the team needs to keep doing: best practices
2. Things the team needs to begin doing: process improvements
3. Things the team needs to stop doing: process problems and bottlenecks
4. These areas are discussed and a list of Agreed Actionable Improvements is created.

Other tools used in the Process of Retrospect Sprint are:

1. ESVP
2. Speed Boat
3. Metrics and Measuring Techniques
4. Scrum Guidance Body Expertise

The outputs of the Retrospect Sprint are:

1. Agreed Actionable Improvements
2. Assigned Action Items and Due Dates
3. Proposed Non-Functional Items for Prioritized Product Backlog
4. Retrospect Sprint Log(s)
5. Scrum Team Lessons Learned
6. Updated Scrum Guidance Body Recommendations

Scrum treats time as one of the most important constraints in managing a project. To address the constraint of time, Scrum introduces a concept called ‘Time-boxing’ which proposes fixing a certain amount of time for each process and activity in a Scrum project. This ensures that Scrum Team members do not take up too much or too little work for a particular period of time and do not expend their time and energy on work for which they have little clarity.

Some of the advantages of Time-boxing are as follows:

• Efficient development process
• Less overheads
• High velocity for teams

Time-boxing can be utilized in many Scrum processes, for example, in the Conduct Daily Standup process, the duration of the Daily Standup Meeting is Time-boxed. At times, Time-boxing may be used to avoid excessive improvement of an item (i.e., gold-plating).

Time-boxing is a critical practice in Scrum and should be applied with care. Arbitrary Time-boxing can lead to de-motivation of the team and may have the consequence of creating an apprehensive environment, so it should be used appropriately.

A Cumulative Flow Diagram (CFD) is a useful tool for reporting and tracking project performance. It provides a simple, visual representation of project progress at a particular point in time. It is usually used to provide a higher level status of the overall project and not daily updates for individual Sprints.

The figure above is an example of a CFD for a large project. It shows how many User Stories are yet to be created, in process of being created, and have been created. As customer requirements change, there is a change in the Cumulative User Stories which have to be delivered. Change points 1 and 2 are where the Product Owner removed existing user Stories in the Risk Adjusted Prioritized Product Backlog and Change points 3 and 4 are where the Product Owner added new User Stories in the Risk Adjusted Prioritized Product Backlog

This type of diagram can be a great tool for identifying roadblocks and bottlenecks within processes. For example, if the diagram shows one band becoming narrower while the previous band is becoming wider over time, there may be a bottleneck and changes may be needed to increase efficiency and/or improve project performance.