Scrum Insight Logo

Objective Scrum coaching advice customized to your team.

Results for Soft Dev

The team Soft Dev had 5 team members reply to the ScrumInsight survey. If the team has more members than this, or if the Product Owner or ScrumMaster did not respond to the questionnaire, there may be significant inaccuracies in this report.

Based on those replies, the following results were found:

Overall Scrum Score

86%

This overall Scrum Score shows how well Soft Dev is applying Scrum.

Scrum Score Card

The Scrum Score Card shows how well Soft Dev is applying aspects of Scrum. The scores here are used to calculate the overall Scrum Score.

Scrum Scores and Explanations

These scores reflect simple averages of how your team responded to each of the survey questions about the Scrum rules. There are six categories that these rules fall into, and their scores are as follows:

General Process: 91%

Category: General Process Icon

The General Process score is a measure of how well the team is applying the process-related rules of Scrum related to meetings, process flow, time boxes, structure and artifacts. This score is an indicator of how well the team is using Scrum as an empirical process.

Product Backlog: 83%

Category: General Process Icon

The Product Backlog score is a measure of how well the team's Product Backlog fits the ideal for that artifact. This score is an indicator of how well the team is using Scrum to deliver value and adapt to changing business conditions.

Team Membership: 93%

Category: General Process Icon

The Team Membership score is a measure of how well people on the team are filling the role of Scrum Team Member. This score is an indicator of how well the team is using Scrum to set the conditions for becoming a high-performance team.

ScrumMastering: 82%

Category: General Process Icon

The ScrumMastering score is a measure of how well the person in the ScrumMaster role is performing their duties. This score is an indicator of how empowered the team is to focus on its work instead of the process (by having the ScrumMaster focus on process).

Product Ownership: 83%

Category: General Process Icon

The Product Owner score is a measure of how well the person in the Product Owner role is performing their duties. This score is an indicator of how empowered the team is to focus on solving business problems (instead of discovering and investigating those problems as the Product Owner does).

Agile Best Practices: 73%

Category: General Process Icon

The Agile Best Practices score is a measure of how well the team is using complementary practices that are often used to support a Scrum team and make it more effective.

Quick Wins

The survey(s) show that these are the rules of Scrum that your team is struggling with. In this Quick Wins section, Scrum Insight has chosen the highest importance, best short-term return-on-investment rules of Scrum for your team to implement or improve. The determination of these Quick Wins is done using the following techniques and information:

Based on the above information, a "Fix Score" is calculated for each of the rules of Scrum. The rules which have the highest Fix Score are then reported here with a detailed description of the rule (for those who may not know what it is and why it is important) and a practical how-to for implementing the rule. Additional online resources may also be referenced for those who want to learn more.

Quick Win 1:

Category: General Process IconCategory: Scrum Master
Your team is struggling with: People outside the team know that it is the Scrum Master's job to shield the team from interruptions

3
Fix Score: 3/5.0

What does this mean?

A Scrum Master is an individual who both guides and protects the Scrum Team. One of the ways that the Scrum Master protects the Scrum Team is by shielding it from interruptions. The interruptions that the Scrum Master cares about stopping are those that are from outside the team when they are in a Sprint. Most interruptions are not related to the team's current work and need to be blocked by the ScrumMaster so that the team will be able to focus on its current goal: the Sprint and its Product Backlog Items. All of the stakeholders of the team need to be aware that the Scrum Master is responsible for blocking these interruptions. This awareness creates a freedom for the Scrum Master to do this very difficult part of the job in a way that is transparent and effective. If the stakeholders are not aware of this part of the job, then they may become upset when interruptions are blocked or find ways around the Scrum Master to get interruptions to specific team members. If the team is not aware that this is the Scrum Master's job, they may feel trapped, may lose hope in the Scrum process, may take on the work themselves (which will be too much for them since they are responsible for the execution of the Sprint goal), feel unsafe which could lead to hiding obstacles (which causes waste and delays), and it may even cause Team Members to accept interruptions as normal which will create an environment where interruptions and unrelated requests become widespread. All of these negatives effects and many more can be solved by the organization knowing that the Scrum Master's job is to shield the team from interruptions.

How do we do it?

The most important part of ensuring this rule is possible is to also ensure that there is a clear, easy mechanism for stakeholders to make requests to the team but in a way that does not break this rule. Normally, this is done by making communication with the Product Owner easy and regular, and making the status of the Product Backlog constantly visible. In some cases, there are other techniques that can work to handle interruptions that can allow a team to make progress to fully adopting this rule. The two most common techniques that are partial implementations of this rule are to allow a very limited amount of time for handling interruptions every Sprint and to use prominent, brightly colored note cards and to make interruptions highly visible then have a public whole-team discussion about trade-offs for the interruption versus the planned work of the Sprint. More details on these two techniques (as well as some other techniques for handling interruptions) can be found in the article Seven Options for Handling Interruptions in Scrum and Other Agile Methods. If the Scrum Master feels confident in the need to block interruptions, the best technique is often to have very direct face-to-face conversations with the people trying to interrupt the team about the consequences of interruptions.

Scrum Guide Reference

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says....
The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product.

Quick Win 2:

Category: General Process IconCategory: Agile Practices
Your team is struggling with: Your Product Owner creates and maintains the team's Product or Release burndown chart

3
Fix Score: 3/5.0

What does this mean?

SAMPLE EXPLANATION REDACTED

How do we do it?

SAMPLE HOW-TO REDACTED

Scrum Guide Reference

Various projective practices upon trending have been used to forecast progress, like burn-downs, burn-ups, or cumulative flows. These have proven useful.

Quick Win 3:

Category: General Process IconCategory: General Process
Your team is struggling with: Team Members answer only three questions at the Daily Scrum (no discussion)

2.6
Fix Score: 2.6/5.0

What does this mean?

SAMPLE EXPLANATION REDACTED

How do we do it?

SAMPLE HOW-TO REDACTED

Scrum Guide Reference

During the meeting, the Development Team members explain:
What did I do yesterday that helped the Development Team meet the Sprint Goal?
What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Quick Win 4:

Category: General Process IconCategory: Product Owner
Your team is struggling with: Your Product Owner has the bandwidth and capacity to respond within minutes to the team's questions

2.4
Fix Score: 2.4/5.0

What does this mean?

SAMPLE EXPLANATION REDACTED

How do we do it?

SAMPLE HOW-TO REDACTED

Quick Win 5:

Category: General Process IconCategory: Product Backlog
Your team is struggling with: The Product Backlog is easily visible to every stakeholder (e.g. cards on a wall or an electronic tool with open access)

2.4
Fix Score: 2.4/5.0

What does this mean?

SAMPLE EXPLANATION REDACTED

How do we do it?

SAMPLE HOW-TO REDACTED

Scrum Guide Reference

Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.
... Product Backlog items usually acquire this degree of transparency...

Overall Team Environment Score:

50%

This overall Team Environment Score shows how well Soft Dev is supported by the environment.

Team Environment Score Card

The Team Environment Score Card shows how well Soft Dev is supported by various aspects of the environment. The scores here are used to calculate the overall Team Environment Score.

Team Environment Scores & Explanations

Roles: 80%

The Team Roles score is a measure of how well the members of the Scrum Team have adopted the Scrum rules (Team Member, ScrumMaster, and Product Owner). This measure reflects both the perception of the team members as well as the actual role definitions in the broader organization.

Proximity: 40%

The Team Proximity score is a measure of how easy it will be for team members to communicate and collaborate efficiently and effectively and work together to solve problems. Proximity has a significant effect on a team's likelihood of reaching a high-performance state.

Sprint Length: 80%

The Sprint Length score is a measure of how close to the ideal Sprint length this team is. Generally speaking, shorter Sprints are better as they allow for faster feedback and learning processes.

Doneness: 20%

The Doneness score is a measure of how well the team is able to deliver valuable work to the stakeholders on a Sprint-by-Sprint basis. Doneness has a significant impact on the team empowering just-in-time business decisions and innovation.

Context: 60%

The Team Context score is a measure of how clear the team's mandate is for the work that they are doing and how few or many distractions there are from that mandate. Team context has a large impact on focus on business concerns vs. technical or bureaucratic concerns.

Team Size: 100%

The Team Size score is a measure of how close this team is to the ideal Scrum team size. Team size has a significant negative effect on performance if it is too large.

Management: 60%

The Management Support score is a measure of how the team members perceive the various levels of management supporting the Scrum Team both to do its work and to use the Scrum process effectively to get that work done.

Team Stage: 20%

The Team Stage score is a measure of how close to being in a high-performance stage of development the team is based on their own perception of the team. The ultimate measure of performance is their actual results.

Long Term Recommendations

The Long Term Recommendations are designed to address the deeper cultural and business transformation that is required to get to high-performance Scrum teams. These Long Term Recommendations are based on a more general analysis of the results of the survey. This general analysis puts higher weight on the survey results for the Team environment questions and only accounts for summary-level results for the Scrum rules questions. In this section, recommendations are based on scoring thresholds. Therefore, if a team has a score below a certain threshold, it triggers the recommendation of a long-term strategy for improving the Scrum team or its environment.

Long Term Recommendation 1

Improve the Readiness of the Product

For the business, the ultimate benefit of properly-done Scrum is that the product being built is completely ready, every single Sprint, for quick release to production, users or clients. This means that all the technical and bureaucratic aspects of the work on a product are completed every Sprint. For example, if a software development team does not do regression testing every Sprint, then their product cannot be said to be ready at the end of every Sprint. Likewise, if the team does not get a release approval every Sprint, then, again, the product cannot be said to be ready at the end of every Sprint. Most organizations take years to reach this stage of development with Scrum.

The true sign of a ready product is that there are absolutely no technical tasks or bureaucratic tasks done outside of the team's Sprints in order to ship the product. The Product Owner can, at the end of the Sprint Review meeting of any Sprint, decide to ship and, effectively, press a button to do so in a fully automated manner so that by time the Sprint Retrospective is complete, the end users of the software are actually using it. The decision to ship is purely, 100% a business decision with no other factors playing a role.

In order to get to this state, an organization must use four approaches to expanding the Team's definition of "done":

Long Term Recommendation 2

Advance the Team's Stage of Development

SAMPLE LONG-TERM RECOMMENDATION TEXT REDACTED

Long Term Recommendation 3

Improve Team Member Proximity

SAMPLE LONG-TERM RECOMMENDATION TEXT REDACTED

Industry Comparison & Ranking

This section provides comparative information with other teams that have used ScrumInsight. So far, 102 teams have used ScrumInsight.

Scrum Rules Comparison

Scrum rules score distribution histogram.

SAMPLE SCRUM RULES SCORE HISTOGRAM REDACTED

Team Environment Comparison

Environment score distribution histogram.

SAMPLE ENVIRONMENT SCORE HISTOGRAM REDACTED

Basic Scrum Education

Sometimes the people on a Scrum team do not understand some of the rules of Scrum. This can cause serious problems in a team trying to do Scrum well. The following is a list of the rules of Scrum that team members identified as items they did not understand. The explanations below should be reviewed by all the members of the team.

As a Team Member I live the values and principles of the Agile Manifesto in my team

The Manifesto for Agile Software Development is the founding document of the Agile movement. It can be found here: agilemanifesto.org. If you haven't read it, it is strongly recommended! Living values and principles is an act of striving for excellence. There are no mechanisms in Scrum to force people to live these specific values and principles. Instead, Scrum relies on individual team members to develop an understanding and practice of Agile values and principles in and of their own volition. If team members do not heed the values and principles of the Manifesto for Agile Software Development then many other things will take priority such as creating complex documentation, multitasking, and excessive up-front planning. If an organization thinks of Scrum merely as a tactical tool they risk becoming disconnected from the intent of the authors of Scrum -- rather than working to change the culture of their organization toward real agility a team might reduce Scrum to a lesser version of itself (Scrumerfall, Scrumbut...etc, wherein Scrum is reduced to nightmarish micromanagement and not at all the intention of Scrum's authors).

Recommended Support for Soft Dev

Contacting Us

ScrumInsight is part of the Real Agility Program, the customized program for achieving incredible results with Agile and Lean methods. If you have any questions about this report or any feedback for us, please contact info@scruminsight.com or phone us at +1-800-215-2314. We would be happy to help you out in any way we can!

Explaining the ScrumInsight Report (FAQ)

What is the "Fix Score"?

The Fix Score is a rating from 0 to 5 which rates the importance of helping a team practice a particular rule of Scrum. This score is based on a number of factors including the impact of the rule, the effort to implement the rule, and the statistics about how the team rated in following the rule. The Fix Score also takes into account modifiers based on the general team context questions. A Fix Score in the range of 3 to 5 indicates something that a team should take on as a very high-priority fix that will have a large impact on the performance of the team. A Fix Score from 1.5 to 3 indicates a medium-priority/medium impact fix. Anything with a Fix Score below 1.5 indicates something that may be useful for fine-tuning the performance of the team.

How are "Quick Wins" determined?

Simple: the 5 Scrum Rules with the highest Fix Scores are selected for the Quick Wins section of the report.

How are "Long Term Recommendations" determined?

The answers to the survey questions in the "Team Characteristics" section are analyzed in the context of the various Scrum rules to pick out the highest-impact long term recommendations. Sometimes the analysis is simple, but often there is a complex relationship between the various factors and how they affect each other.

Can I get the raw data from the questionnaire in order to run my own analysis?

Short answer: "no". Primarily this is a safety issue. Since it is possible that individual team members could be evaluated or worse, punished, based on their responses to the questions, and since there is often enough information to identify an individual team member from their responses, we do not supply the raw data. However, if you wish for a customized report with additional statistics, we would be happy to discuss your needs. Our contact information is at the end of this report.

How are the items in the "Education & Support Items" sections determined?

The items are determined very simply based on a particular rule of Scrum receiving one or more responses of "I don't know what this means." Sometimes that corresponds to a practice that the team is doing poorly, sometimes it doesn't. For example, an item identified for education may not be something that the team needs to adopt urgently relative to the other Quick Wins that are listed, possibly because the team is already doing it well, but at least one team member indicated that they didn't know what the rule means so it was included in the education section. Or it may mean that team members felt they were not following the rule, so it was listed as a Quick Win but as nobody indicated "I don't know what this means" it wasn't listed as an education item. Note: the content of the education items is re-used with the first part of the text for a Quick Win (the "What does this mean" part).

Can we use ScrumInsight again to see how we have changed/progressed?

Absolutely you can! We are currently in our first release of this program which is optimized for single uses... so please contact us (information above) about doing it again. We recommend waiting at least 4 full Sprints before doing it again, and we recommend doing it at least once a quarter and discussing the results in your Retrospective.

Objective Scrum coaching advice customized to your team.