Scrum Self-Assessment

072516022-assessment-teared-note-paper-p.jpeg

Scrum is simple but not easy. It consists of a set of roles, events, and artifacts that together comprise the Scrum framework. A team’s level of success with Scrum depends on how well the team engages in the Scrum framework and how they inspect, adapt, and improve over time.

To begin this self-assessment, I would like you to imagine where you would like to be in your software delivery capabilities sometime in the future. It does not matter what the details are, but they should include elements of quality, schedule, budget, and predictability. Assign a value of 10 to your desired future state.

Now, assign a value to your current state. For example, you know you want to achieve a 10, but currently you might be a 4. Next, determine what your state was three months ago, six months ago, and nine months ago.

Review that data and see whether you are improving in your journey toward your self-described future state. Perhaps you have been in the same state for some time now and are not improving. Keep your state in mind as you complete the rest of this self-assessment.

This article identifies the key principles of Scrum and allows the reader to rank their Scrum adoption on a scale of 0 to 4. A 0 means no or very low acceptance of the principle. Beyond 0, we have a ranking of 1 to 4, with 1 representing low adoption and 4 representing very high adoption.

This scale can also be used by teams who are new to Scrum. In this case, the ranking would be how open your new team is to implementing the principles in the proper manner. Keep the current culture of your company in mind as you perform the ranking. It will help you understand the consequences of skimping on areas.

Each area of Scrum is covered in this assessment. We start with a short description to provide context as to why it is important and to aid the reader in deciding on a ranking.

Product Owner Engagement

The product owner is a key member of a Scrum team. The product owner should have a passion for the product they are responsible for. They should understand the competitive landscape of the product and engage stakeholders on a regular basis. It is the job of the product owner to ensure that the product meets the needs of the organization and is the single neck to ring if the product’s features are incorrect.

The product owner is responsible for the product backlog. The backlog is a prioritized list of product features knows as user stories.

The product owner ensures the user stories are properly defined, estimated, and prioritized. They schedule backlog grooming meetings at the proper time to ensure the backlog is in the proper condition for sprint planning.

The product owner offers high availability to the Scrum team to answer any questions that arise. They are ready to attend demos and accept user stories as DONE.

The product owner is prepared for and attends all sprint review meetings. They pay close attention to the demos and provide feedback to the team. They also accept user stories as DONE.

A product owner who is not fully engaged causes friction and slows things down. Sprints unfold quickly, and if the product owner is not available to the team, stories will not get DONE in a sprint.

If the product owner does not keep the backlog in order and is lax on the scheduling of grooming meetings, sprint planning suffers.

If the product owner misses sprint review meetings, user stories cannot be approved and set to DONE.

0 | 1 | 2 | 3 | 4

Definition of DONE

One of the twelve principles of the Agile Manifesto is “Working software is the primary measure of progress.”

The definition of DONE expands this idea and defines the exact criteria that allow a user story to be considered DONE. From a delivery perspective, these criteria typically include “fully developed”, “QA-tested,” and “deployable”. They can also include additional elements, such as “unit-tested,” “code-reviewed,” and “stress-tested.” The team identifies the completed criteria together. The final DONE criteria item is accepted by the product owner.

When a well-identified definition of DONE is used, a tremendous amount of risk is eliminated. When a team can truly identify a set of features as DONE, they can move forward and check these items off their list. There are no odds and ends and no “one-line changes” to features that pile up.

I want to emphasize deployable, which was highlighted earlier. A user story is not DONE when it runs on a developer’s machine. It must operate properly in other environments as well, like QA and ultimately production. When a user story is truly deployable, it eliminates the oft-stated quote “It works on my machine”.

The DONE criteria are considered when defining and estimating user stories. The whole team must keep this concept in mind. This point will be emphasized throughout the rest of this article.

The biggest consequence of a poorly followed definition of DONE is risk. There is a risk that things we thought were done are not really DONE. The problem is, we do not know how many of these things there are.

Typically, the launch date looms over the team, and team members work many overtime hours to meet the deadline. When this happens, quality suffers. Over time, after multiple launch cycles, we have a fragile, buggy software product.

0 | 1 | 2 | 3 | 4

User Story Definition

The most efficient Scrum teams define user stories using the INVEST approach. The most important letters from this acronym are I (independent), E (estimable), and S (small). As stories are defined, the definition of DONE must be considered.

When stories are independent of each other, there is much more flexibility in how they can be developed and deployed. Often, proper architecture is required in the product so that components, portions of web pages, and the underlying architecture can operate independently.

We cover estimation in the next section, but it is worth mentioning here since it is part of the INVEST acronym. As the independent stories are defined and prioritized on the backlog, they must be easily estimated, meaning they must be understood by the team.

Small stories are easier to understand and get to a DONE state in the fast-moving sprint execution cycle. At a very minimum, a story must be able to be completed in a sprint.

Microservices are a common way to tackle independent and small stories.

When stories have tight dependencies, friction occurs and stories are harder to deploy to production. When legacy monolithic systems are involved, the dependencies can be treated as technical debt and be prioritized on the backlog like any other user story.

When stories are large, the likelihood of not completing stories in a sprint is higher. Often, these large, incomplete stories move from sprint to sprint, making planning difficult. Large stores may be split into smaller ones. It is better to complete a few of the small stories and have an incomplete small story move to the next sprint instead of one large one.

0 | 1 | 2 | 3 | 4

User Story Relative Size Estimation

To properly plan, we need an estimated backlog. A popular technique is to estimate user stories in a relative manner. The definition of DONE must be considered when estimation is performed.

The most common technique is story points. This technique assigns a point value to each user story using a Fibonacci-like format: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100.

Estimation is done by the team, typically during backlog grooming. Planning poker is a common Scrum game where this occurs. During a planning poker session, each team member votes for their estimate by holding up a card with an estimate value on it. When large discrepancies occur between team members, the story is discussed until a consensus is reached.

A simplified approach known as T-shirt size may be used. This technique is good for new teams. Using this approach, the story point value is assigned by associating it with the size of a T-shirt. (Baby - 1 | Small - 2 | Medium - 4 | Large - 8 | XL - 16).

When teams do not estimate user stories, it is not possible to properly predict delivery dates or budgets. In this situation, the team works hard on user stories with no real idea of when they will be able to ship a release. This often leads to a death march toward the end of the release, when management instructs the team to “do what it takes” to get the product shipped by some arbitrary date.

0 | 1 | 2 | 3 | 4

Backlog Grooming

Backlog grooming is not a formal Scrum event. The goal of backlog grooming is to get the backlog into a state that will allow sprint planning to be successful. The frequency of this type of meeting is up to the team. The product owner conducts the meetings. The following activities should be accomplished:

  • Priority – the priority of the backlog is reviewed and modified as needed. Keep in mind that the stories at the very top of the backlog will be considered for the next sprint.

  • User Story Definition – new or drastically changed stories are explained by the product owner. The team interacts with the product owner and asks any questions necessary for a full understanding.

  • User Story–splitting – when a story is large, it is split into smaller stories.

  • Estimation – stories are estimated using a relative size technique.

Teams with a well-groomed backlog will be well prepared for sprint planning.

When a backlog is not well-groomed, sprint planning is compromised, which causes major disruptions in the Scrum process. The team cannot accurately commit to sprints, and long-term planning becomes nearly impossible.

0 | 1 | 2 | 3 | 4

Stable, Cross-functional Team

A scrum team focuses 100% on the work in a sprint. They do not perform any other work. This is one of the primary reasons that scrum teams can get much more work done than in other frameworks. Scrum teams should be small, typically six to eight people.

A scrum team should have all the skills necessary to complete the sprint. When skills are needed outside of the team, friction and dependencies arise.

Pict1.png

Individual team members should be cross-functional, which is known as T-shaped skills. Broad skills allow individuals to perform a variety of tasks. Deep skills are specialties that only specific team members are qualified to do.

An example of a broad skill is helping author user stories. Most team members have this skill. A deep skill is UX development, which is a specialty specific to a small number of team members.

The makeup of the team should not change and should remain stable. Team members learn how to work together over time and develop a rhythm that improves efficiency.

When teams and individuals are cross-functional and stable, an accurate velocity emerges, which is critical to planning and budgeting.

If team members are often shuffled off the team and if individuals only work on their specialty skills, velocity is all but impossible to utilize for planning purposes.

0 | 1 | 2 | 3 | 4

Sprint Planning

Sprint planning is where the team decides what can be completed in the upcoming sprint. Many of the topics we have discussed come together during the sprint planning. The level of success will depend on how well the team has accomplished these aspects we have already discussed.

In a nutshell, the team reviews the user stories at the top of the backlog one by one and adds them to the sprint until there is no more capacity available in the sprint.

This process is easy when the backlog has been properly groomed. Velocity is used to help determine what stories will fit into a sprint. If your team has a velocity of 75 story points, you simply add stories to the sprint until you reach 75 points. If the team is not stable and cross-functional, the velocity will not be accurate, and planning will be much more difficult.

Some teams use hour estimates to help determine what will fit into a sprint. In this case, individuals estimate in person-hours how long each task necessary to implement a user story will take. The total number of hours is compared to the team’s available hour capacity. When the hour capacity has been consumed, no more stories are added to the sprint.

Sprint-planning meetings are crucial. When this meeting has not been properly executed, the pending sprint is at risk of inefficiency and waste.

0 | 1 | 2 | 3 | 4

Sprint Execution

Once a sprint has begun, it is largely up to the team to self-organize and successfully deliver the user stories agreed upon during the sprint planning.

There is one daily meeting required in the Scrum process. This meeting occurs each day at the same location and is time-boxed to fifteen minutes. It is often called a stand-up meeting because everyone stands, which keeps the meeting short.

In this meeting, each team member discusses what they have worked on since the last meeting and what they plan to complete by the next meeting. They also mention any impediments they are experiencing.

Pict2.png

The team also reviews the progress of the sprint using a burndown chart. This chart compares the initial estimate at the beginning of the sprint to the current daily estimate.

This meeting provides the team with a daily view of the work remaining in the sprint. Based on the data in the chart, action may need to be taken to meet the desired goals.

Since sprint execution takes up most of the time in a sprint, much of the Scrum Master’s work unfolds here. The Scrum Master ensures that Agile principles are followed and removes impediments the team may have.

Sprint execution is where the rubber hits the road. Any deficiencies that occurred are exposed here. Poor sprint planning, an improper definition of DONE, and team deficiencies are exposed.

0 | 1 | 2 | 3 | 4

Sprint Review

The sprint review is where the team demonstrates the user stories that are DONE and awaiting product-owner approval. The team decides who will perform the demonstration. The product owner is a key attendant to the meeting because they must approve the stories for them to be considered DONE.

We do not have to wait until the sprint review to demonstrate stories; they may be demonstrated to the product owner anytime and be approved.

When a user story is considered DONE, the story points associated with the story are added to the team’s velocity. If any of the DONE criteria are incomplete, the story is not DONE and typically moves to the next sprint. No story points are added to the team’s velocity in this case.

If the product owner is not engaged and misses sprint review meetings, stories cannot reach a DONE state. Unapproved stories move to the next sprint and get entangled with the stories that are planned, which causes unnecessary noise and distraction. It also affects the velocity calculation of the team.

0 | 1 | 2 | 3 | 4

Sprint Retrospective

The sprint retrospective is where the team reflects on the sprint that just ended and identifies a few things that went well and a few things that need improvement.

We want to continue doing the things that went well and improve on the things that did not go so well. The team agrees to improve on two or three things in the next sprint.

Teams that embrace the retrospective step improve over time. Teams that skip the retrospective step or take it lightly do not improve and actually degrade over time.

0 | 1 | 2 | 3 | 4

Scrum Master – Servant Leadership

The Scrum Master works with the Scrum team and guides them in their journey to adopt Agile and Scrum principles. The Scrum Master is not a boss or a project manager but rather a servant leader.

Some attributes of a Scrum Master as a servant leader are as follows:

  • Makes observations and asks questions about things that violate Scrum and Agile principles and helps people overcome obstacles on their own.

  • Provides direct and firm feedback.

  • Understands that change is difficult and employs empathy while guiding the team in making the necessary changes in behavior.

  • Acknowledge when things are outside their scope of knowledge and skills and recommends other avenues when appropriate.

  • Builds relationships with the team and becomes a trusted advisor to them.

  • Coaches the team to become self-organizing.

  • Facilitates meetings and encounters, does not directly tell people what to do, and helps people gradually change their own behavior.

The Scrum Master protects the team from outside interferences by coaching the organization on the benefits of Scrum and Agile principles. Using servant leadership techniques, they remind the organization of the benefits of Scrum when they are tempted to return to old habits.

0 | 1 | 2 | 3 | 4

The diagram below depicts each of the areas covered in this assessment. The Product Owner is the single point of contact for the team on things that relate to the product. The Scrum Master is a servant leader in the process and acts like a flashlight shining light on areas that need attention.

Pict3.png

Each of these items are interrelated, and deficiencies in any one ripple into the others. A sprint should not simply be used as a convenient bucket for work.

Assessment Review

If you have a 0 in any of these areas, your Scrum outcome will be very negatively affected. It is important to elevate each of the 0 areas to some non-zero value as soon as possible. If there are many of them, consider pausing delivery for a short period of time and developing an action plan to improve them. Another area to look at is highly inconsistent rankings, which will result in a skewed score.

There are 11 areas in the self-assessment that are ranked from 0 – 4. It is important to understand that regardless of how your ranking came out, you will improve over time as long as you stick to Scrum principles. Think of it like a diet and exercise plan. You could begin out of shape. Exercise is hard, but over time, you get stronger and more fit.

  • 34 - 44 – your team should be feeling quite accomplished in its adoption of Scrum. Here are some things to look into:

    • Do you have a stable velocity? Look at the velocity of the past five sprints and see if it is consistent.

    • How is the quality of your product? If you have too many defects, you may want to add more unit tests and increase the DevOps approach you are taking.

    • Are your customers happy? If you cannot quantify this, consider sending out some questionnaires and ask customers to rate your product.

  • 23 - 33 – you are probably following the mechanics of Scrum but not the true essence of it. Meet as a team and look at one or two of the lowest ranks. Decide as a team how to specifically improve. Put together a roadmap of how you will improve.

  • 11 - 22 – this score indicates that some real work is needed. Do not be discouraged. It is never too late to start. Have a team meeting and a frank discussion about the issues that resulted in a low score. If you find you do not know where to start, you may want to hire an Agile coach to help guide the team down the correct path.

Learn More About It

Below you will find links to a set of excellent videos about Agile. I highly recommend that you take the time to view them.

  • Product Owner In a Nutshell - This is the best single video I have seen on agile. Its title focuses on the product owner but it really covers all of agile delivery.

A PDF version of this article is available here.

Zero Downtime Deployment with a Database - Example

In my previous article, I covered the challenges and design of an application that uses zero downtime deployments with breaking schema changes to a database. In this article, I cover the implementation details.

The current state of our database table is shown below.

Image1.png

We will be renaming the LastName field to SurName.

Image2.png

The user interface will also need to change.

Image3.png

The implementation for the user interface ensures that a value is entered for LastName. This will be implemented for SurName as well.

Implementation Details

We will be using diagrams like the one shown below to step through the implementation. The database version is shown above the database element. We start with 2.0.0.

Under the database element, we see the fields involved. We start with the current database with LastName that does not allow nulls.

Application 2.2.2/Database 2.0.0

The current production version of the application is 2.2.2 and is compatible with database version 2.0.0. The previous version, 2.2.1, is in the staging environment and is also compatible with database version 2.0.0.

Image4.png

Application 2.2.2/Database 2.01

The first thing we need to do is add SurName to the table. It is set to allow nulls so both versions of the application will operate. Remember, the user interface validates the entry of the data. The database reinforces this rule. This brings our database version to 2.0.1.

Image5.png

No application code is changed, but the compatible database version is changed. As new rows that contain LastName are added, null SurName fields will be present. The database change needs to be tested carefully in the QA environment since no easy rollback is available when deployed to production.

Image6.png

Application 2.2.3/Database 2.0.1

Version 2.2.3 of the website implements the SurName field in the user interface. Front-end validation ensures that the SurName field has been entered.

Image7.png

To support a possible rollback, we also need to maintain the LastName field. This application uses the Entity Framework and the Repository Pattern.

A screenshot of the code changes for the SaveCustomer method is shown below.

Image8.png

We need a postdeployment script that updates the SurName field with the LastName values.

Image9.png

Below, we see the implemented SurName field. All of the LastName values are now also in the SurName field. As the user operates the application, the LastName field is also updated.

Image10.png

Rollback - > 2.2.2

If something goes wrong with 2.2.3, we can roll back to 2.2.2. As we are fixing 2.2.3, users will be using 2.2.2. As they do, only the LastName field will be updated. When we deploy the fix to 2.2.3, we need to rerun the postdeployment script.

Application 2.2.4/Database 2.0.2

2.2.4 removes LastName from the application codebase, but we need to keep LastName in the database and change it to allow nulls. As new rows that contain SurName are added, null LastName fields will be present.

Image11.png

Rollback - > 2.2.3

If something goes wrong with 2.2.4, we can roll back to 2.2.3. As we are fixing 2.2.4, users will be using 2.2.3. As they do, the LastName field will still be maintained.

Application 2.2.5/Database 2.0.3

Version 2.2.5 of the application depicts the implementation of some other new feature and the completion of the SurName implementation.

Final database changes are made, and the LastName field is replaced with the SurName field.

Image12.png

Rollback - > 2.2.4

Version 2.2.5 implements some other feature. If something goes wrong, we can roll back to 2.2.4, which contains the final application code for the SurName change.

Closing Thoughts

This trivial change represents a worst-case scenario for a database change. To support rollbacks, we basically need to support both the LastName and SurName fields and gradually remove the LastName field.

In my development cycle, I used a separate local development SportsStore database. This is necessary because I needed to carefully test the database deployments. I also carefully made backup copies of the local database so I could restore and retest the deployments.

In a real-world example, careful thought, planning, and testing need to be completed to achieve true zero downtime deployments with rollback.

If you are interested, you can have a look at the current Production and Staging version of SportsStore.

Zero-Downtime Deployment with a Database – Introduction

sqldevops.png

This is the first part of a two-part article that describes how to implement a Blue/Green deployment of an application when a schema change to a database is made. This schema change will break existing code. I also assume that the amount of data in the database is very large.

We have a Staging and a Production instance of the application. After a production release is performed, we want to be able to roll back to the staging instance.

The application, called Sports Store, is a Microsoft MVC 5 application using a SQL server database. The application uses Azure as the execution environment. Azure Deployment Slots are used to facilitate rollbacks. We also use Azure DevOps as the CI/CD tool, and all aspects of the process are automated.

This is an oversimplified example, but my hope is that it touches all the points a real application would.

Our Challenge

We use a simple Customers table, as shown below. We will be renaming the LastName field to SurName. Remember, this application has been running in production using the LastName field. We also assume that there are 1 million records in the Customer Table.

Image1.png

Our application has a simple way to browse the data and perform CRUD Operations. LastName will be changed to SurName.

Image2.png

Here is the data entry screen. Again, LastName will be changed to SurName.

Image3.png

My implementation is based on the excellent article Zero-Downtime Deployment With a Database.

Design

The biggest design decision I had to make involved the database. I could have a separate database for Production and Staging. This would make the deployments easier, since each environment would have its own isolated database.

However, because of the large amount of data involved, I decided to have a single database shared by both environments. This makes deployments trickier but would not require the movement of vast amounts of data between environments. The diagram below depicts the design I chose.

Image4.png

I also decided to associate a version number with the web application and the database. There is also a configuration setting for the web application to identify the database version it is compatible with.

Image5.png

In the above diagram, we see the database version is 2.0.3. The current production version is 2.2.6, and the stage version is 2.2.5. Both Production and Stage are compatible with database version 2.0.3. As long as Production and Stage are compatible with the same database, we can safely roll back a release. A release is rolled back by changing where the Production IP points to.

Deployment Slots

We use Azure Deployment Slots to implement our Blue/Green Environment. The screenshot below shows our single Sport Store Database. We also see the production instance of the Web application, OcambSSBlueGreenWeb, and the staging instance, Staging (OcambSSBlueGreenWeb/Staging).

Image6.png

Continuous Deployment Pipeline Diagram

We use Azure Devops to deploy artifacts to our Blue/Green Environment. The artifacts are created by the build process and use the codebase in the Master branch.

There is a deployment pipeline, Deploy – BlueGreen Master Database, with a single stage, Production DB, that deploys the database to production. This is a shared database, so great care must be taken when deploying database changes.

Image7.png

The deployment pipeline for the website, Deploy – BlueGreen Master Website, has two stages.

Staging is used to deploy the website to the Staging Slot. Final testing is done to ensure the deployment is acceptable. It is important to understand that prior to this, extensive testing was completed as sprints unfolded.

Production is used to swap the Production IP Address. Once this is completed, the new changes are available to production users. There is also a pipeline to roll back a release.

Continuous Deployment Pipeline – Azure DevOps

The screenshot below shows the release pipeline for the database. The artifacts were built from the Master branch. An approval is required before the artifact is deployed.

Image8.png

The screenshot below shows the release pipeline for the website. The artifacts were built from the Master branch. There are two stages to the deployment. Each stage requires an approval.

The first stage deploys artifacts to the Staging environment. We perform a set of regression tests to ensure we are ready to move the release to Production. During this time, Production is using the current release. Both Production and Staging are compatible with the database, so they can operate side by side.

When we are comfortable with the release, we change the Production IP Pointer to point to the staging environment by approving the Production stage. No code is deployed here; we only change the Production IP Pointer. If something goes wrong in production, we can easily roll back.

Image9.png

The screenshot below shows the release pipeline for a rollback. This only switches the Production IP Pointer to point back to the previous release. There are no artifacts involved in this case.

image10.png

In Conclusion

This article discussed the approach we are taking to implement a zero-downtime deployment of an application when a breaking schema change is made to the database. We discussed the challenges we faced and our design.

We showed how we set up deployment slots in Azure and how we use Azure DevOps to implement a Blue/Green environment with rollback capability.

The next article will dive into the details of how this was implemented.

Agile Transformation Contracts

046327647-contract-signature.jpeg

It can be challenging to get team members new to Agile all on the same page because, often, there are no clear responsibilities defined for the Agile coach and the team.

This Agile Transformation Contract can be used by teams and an Agile coach to define these responsibilities. It should be signed by the coach and each team member. Feel free to download the contract and modify it to your specific needs.

Agile Transformation Contract – Coach

Agile Transformation Contract – Team Member