IDEAMATICS provides custom software development services to companies and organizations.  We developed the I-Agile™ development methodology, which is a tried-and-true approach to producing high-quality code in a short amount of time.  This is accomplished by following an iterative Agile development process while introducing flexibility to integrate vulnerability scanning and Government technical reviews in the Sprint cycle.  As part of this process, we use SCRUM to achieve our customers’ vision.  To learn more about Agile, read our other related blog How Agile Development Has Changed the Software Development World.

Among other projects, we have had a very successful year working on a military case management system, the Air Force Justice Information System (AFJIS).  Our ultimate measure of success is the Contractor Performance Assessment Report (CPAR), which assesses a contractor’s performance and provides a record on a given contract during a specific period.  In June, we received EXCEPTIONAL ratings across the board for our AFJIS Base Year CPARs.  The ratings include assessments on Quality, Schedule, Cost Control, Management, Regulatory Compliance, an Additional/Other.  We use our I-Agile methodology for AFJIS, which puts us in a good position to provide tips for running a successful Scrum team.

Scrum is a framework that was initially created in the early 1990s to help teams manage complex development projects.  Scrum helps people to deliver value incrementally in a collaborative manner by allowing the work to be done in small pieces at a time, with continuous feedback along the way.

Scrum defines what a team should look like, who is responsible for what, and the method to follow to achieve the best results.

A scrum team is a group of individuals who work together in small time iterations, called sprints, to produce a defined goal.  The team is small, usually 10 or fewer members.  The scrum framework helps the team members by providing ways to improve communication so that they can accomplish their goal by adhering to the same rules, by following a common goal and not straying from the recommended path, and by showing respect to each other along the way.

The team consists of one Product Owner, one Scrum Master, and the Development Team.

The Product Owner knows exactly what the customer wants from the product or service being developed or provided.  One of their main duties is to translate the needs and wants of the customer to the team so the team can design the solution that matches those demands.  The Product Owner is also in charge of the Product Backlog, which is the prioritized list of items that the customer desires.

The Scrum Master is responsible for keeping the team members accountable for their commitments to the company for producing the work.  He/She removes obstacles and problems from the road to success to make sure that the development process can be accomplished with peak productivity and performance in as short a time as possible.  The Scrum Master is also in charge of making sure that scope creep does not hinder success.

The Development Team is empowered by the company and is given the autonomy to manage and organize their own work.  This helps the team improve it’s overall effectiveness and efficiency.  This team must be cross-functional so that it can perform all of the work required by the product.  The individual team members may, therefore, have specialized areas of focus and special skills to resolve complex situations.

The Scrum framework defines events and ceremonies that should be followed to achieve maximum  success.  The framework also defines how frequently and how long each of these events should last and which Scrum team members are required to participate.  These are the events or ceremonies, conducted in meetings, that scrum team members participate in:

This event is a short 10-15 minute meeting where each scrum team member can give a short update on what they did the previous day and what they will accomplish before the next daily scrum.  It’s also a time when the team can discuss problems they faced.  The Product Owner doesn’t attend this meeting.

Backlog grooming usually involves all Scrum team members in order to make sure all members are on the same page.  The Product Owner is available to the team to explain prioritizations and what the customer is looking for as well as to receive feedback from the development team on future work.  This allows the team to formulate a strategy to give everyone what they want.

This ceremony allows the team to plan all of the tasks and activities they will perform in the upcoming Sprint. It allows the team members to decide who should work on what, based on their desires and/or skills.  This meeting occurs at the start of each Sprint.

This is the time period in which the team works hard to accomplish the work/goals defined in the Sprint Planning event.  It is usually 2 weeks long, but may vary depending on the work the customer needs to have done.  The Scrum framework advises that this be no longer than a 2 week interval.

This ceremony occurs the end of each Sprint.  It allows the development team to discuss what went well in the Sprint and what could be improved.  Team members are all encouraged to participate to be most effective.

The Merriam-Webster dictionary defines “success” as a “favorable or desired outcome.”  The Cambridge dictionary defines it as “the achieving of the results wanted or hoped for.”  To measure success, there must be a pre-defined goal (outcome or result) and ways to determine if that goal has been met.

Measuring success implies a time period and should allow for measuring over one or multiple time periods.  The Scrum framework, with the Sprint tenet, lends itself well to these concepts.  Each Sprint provides a time period in which the Scrum team can be measured for success.  The hope is that “success” of the team will improve with every Sprint, assuming no blocking factors arise.

According to Fred Wilson, there are certain things that make a Scrum Team successful.  They should be self-organizing, co-located, focused, cross-functional, be small teams, and adhere to rules and regulations.

The team members have clearly defined roles and their combined contribution to the development is crucial for the success of the product.  Everyone shares a unified platform (co-located) and tools to make sure that communication and collaboration are easy to accomplish.  All of the members focus their efforts on a single project at one time in order to achieve better results in the minimum amount of time.

The team must possess all of the skills necessary for the successful development of a product.  The individuals bring their specialized skills to the table and work together to divide the work.  Having a small number of people on the team helps with communication and collaboration.

All team members must follow the rules of the Scrum framework to make sure goals are accomplished on time.

There are numerous blogs and website articles that talk about how to measure Scrum success.   Most talk about tracking metrics and say to use whatever metrics “you would normally use” , such as velocity, improved efficiency, and improved quality.

Although measuring Scrum success is ultimately the responsibility of the Product Owner and the Scrum Master, the entire team should participate in measuring the success of the team.  Each member should be responsible for measuring their individual success, as well, and look for ways to improve performance.

IDEAMATICS relies on CPARs as the ultimate measure of how we performed for a customer.  That said, there are so many tools available to help Scrum Teams adhere to the Scrum framework and those tools usually also have components that can help the team measure their success throughout the development time period.  IDEAMATICS uses Azure DevOps.  The entire team has access to these tools and is constantly aware of how they are during.  These tools are especially helpful for measuring success across multiple sprints.

Azure DevOps includes a Dashboards view which can quickly show the status of the Sprint at any time.  This information is crucial to the Team to measure the progress in the Sprint.  This is an example of how our Dashboards looks:

The Dashboards view show the number of Features, User Stories, and Tasks in a Sprint.  It shows how many User Stories are Closed and if any are Blocked.  It also includes how many work items are ready to be Tested and if any are in a Failed state.  It includes charts for Burn Down, Lead Time, and Cycle Time for the Team.  Also, very importantly, it shows the Team’s Velocity, which is the number of story points completed by the team in one Sprint.

All of these things can be easily measured over time to see if there is improvement or decline for the team.

The Analytics views also help in measuring the teams’ success.  There are queries for various customizable historic data such as Bugs, User Stories, Tasks, and Work Items.  You can query for today,  the last 30 days, 6 months, year, etcetera.  Each team member can also write their own queries for what they want to track.

The Boards view allows the team to quickly find other information for the Sprint, such as Work Items, Boards, Backlogs, Sprints, Queries, and Retrospectives.

The Work Items provides a list of items that is customized by filters set by the team member.

The Boards sub views provide a quick way to see the work in one or more Sprint and the current state.

The Backlogs view shows all the items, filterable, of course, that are in the Backlog.  This view is used primarily in Backlog Grooming events with the Product Owner.

The Sprints view shows all the information for a particular (selectable) Sprint.  It has tabs for Taskboard (work items), Capacity (how many story points are available per team member), and Analytics, including Burndown Trends for customizable units, such as User Stories, Tasks, or Bugs.

The Queries view allows the team member to write custom queries that can remain private or shared by the team.

The Retrospectives view is a used by the team to input information prior to the Sprint Retrospective.  Each team member is encouraged to provide input regarding what went well in a Sprint as well as what can be improved.  This view provides historic data for previous Sprints, as well, and is useful for the team to see if improvements in the process are actually being made over time.  Here’s an example of how’s ours looks:

For IDEAMATICS, we define “success” as:

• Producing software deliverables in a timely manner with a very low defect rate.
• Consistently meeting or exceeding goals defined during Sprint Planning.
• Having a Scrum Team that works together well and where the team members actually like one another.
• Receiving outstanding CPARs at the end of the contract period.
• Having our contracts renewed!

Here are our tips to accomplish this success.

Stick closely to the I-Agile development methodology, including following as much of the Scrum framework, as possible.

• Have one Scrum Master.
• Have one Product Owner.
• Keep the Development Team small, yet diverse.
  • Ensure that cross-functional skills exist.
  • Allow the team to be self-organized and focused.
  • Allow the team to be co-located by ensuring that they have a common toolset and that they each know how to use it to do their work. This will also aid the entire team in monitoring the workload daily.  This is crucial to the success of the team.

Make sure the team performs all of the events .  It is important to consistently do these things for every Sprint to ensure transparency, communication, and collaboration throughout the project.

For our AFJIS project, we do sprint planning, followed by the actual sprint work, including daily scrum standups.   At the end of the Sprint, we also provide a sprint demonstration and participate in a sprint retrospective.  In addition, all team members also participate in weekly backlog reviews.

The Sprint Retrospective allows the team to focus on what went right or wrong, so they can improve performance.

We go one step beyond the traditional Ceremonies by conducting a Hot Wash at the end of each Sprint.  The Hot Wash generally includes the Scrum Team as well as the customer’s stakeholders.  This gives us an opportunity to give them a list of what we found in the Retrospective and to ask for their input – – positive or negative.

This is important.  Team performance grows over time (or declines over time), depending on the happiness of the team over time.  Teams that perceive themselves as overworked or overmanaged will respond accordingly.  Teams that are self-manage, in terms of sizing work and what goes into a sprint, should be happier.

• Allow them to self organize and self manage.
• Allow members to pick tickets/work items, rather than to assign work.
• Allow members to be in remote locations and to provide proper tools to aid in keeping connected.
  • Since the Covid pandemic began in early 2020, most of our meetings are virtual. Many of our team members are no longer physically located in the same geographic area.  This has NOT impacted the team dynamics at all.

Usually, our sprints are 3 weeks, which is probably the longest time recommended by the Scrum Framework.  We have extended some of our sprints to be longer for complex items that the product owner wants completely finished within one sprint.  The maximum length we’ve gone is 6 weeks.

This is not an Agile principal and many would disagree to this approach, but we have found that it works well when all Scrum team members, including, or especially, the product owner, agree.

Teams where the individuals actually like and respect each other will do well.  In this day of mainly remote team work, it’s important to allow team members to get to know one another.  The days of the “water cooler” are long gone.  It’s important to allow the team members to share events happening in their lives – personally, as well as professionally.

There’s a couple of ways that we do this:

• We use an instant messaging tool where group chats can be set up as well as one-on-one messages.
  • Team members can choose to share personal information in either a group chat or privately, with just one person or a smaller subset than the entire Scrum Team.
• Add a little time to the beginning of each event or ceremony to allow participants to share personal information. This has worked very nicely for those wanting to share with the entire team.
• Ask the team to turn on their cameras during remote meetings! It’s nice to see the person behind the voice!

We hope that you find our tips helpful.  There is a lot of information available to learn about the Scrum Framework and how to successfully use it.  If you’d like to learn more, you might be interested in these articles:

“7 Tips to Be a Successful Scrum Master”, 01/27/2021, author unknown.

https://geekbot.com/blog/how-to-be-a-good-scrum-master/

“Become a Successful Scrum Master with These 6 Tips”, 4/29/2021, by Sean Blake at Easy Agile.

https://www.easyagile.com/blog/scrum-master/

“Top 10 Teamwork Tips Custom-Built for 2022”, 02/17/2022, by Sarah Goff-Dupont.

https://www.atlassian.com/blog/teamwork/teamwork-tips-for-2022

“How to Run a Scrum Meeting”, date and author unknown.

https://www.wrike.com/project-management-guide/faq/how-to-run-a-scrum-meeting/

“Seven Tips for Running a Virtual Daily Scrum”, 05/03/2022, by Brian Miller at Mountain Goat Software.

https://www.mountaingoatsoftware.com/blog/seven-tips-for-running-a-virtual-daily-scrum

“How to Measure Agile Team Performance”, date and author unknown.

https://www.wrike.com/agile-guide/faq/how-to-measure-agile-team-performance/

“How Do You Measure Performance in Scrum”, 01/06/2022, by Mona at The Pickled Spruit.

https://thepickledspruit.org/how-do-you-measure-performance-in-scrum/

“Top 3 Recommendations for Measuring Scrum”, 05/14/2020, updated 01/08/2022, by Jacy Ong.

https://agilemania.com/how-to-measure-scrum-success/