As of writing this post, we would be hard pressed to find folks in the Information Technology (IT) industry who have not heard of “Agile” and “Scrum” in some form or fashion. While most IT professionals have heard of these words, not everyone has a clear understanding of what they exactly refer to or has a firm grasp of properly implementing these methodological concepts in practice to achieve success in their projects.
While iterative projects and manufacturing methodologies date back to the 1950s and were applied to software and system development as early as the 1970s, it was the publishing of “The Manifesto for Agile Software Development” in 2001 that took the IT Industry by storm, rapidly transforming the industry worldwide. This book laid out 12 Principles, which some two decades later, still act as a pillar for Agile iterative product development. These rules1 include:
- Customer satisfaction by early and continuous delivery of valuable software
- Welcome changing requirements, even in late development
- Deliver working software frequently (weeks rather than months)
- Close, daily cooperation between business people and developers
- Projects are built around motivated individuals, who should be trusted
- Face-to-face conversation is the best form of communication (co-location)
- Working software is the primary measure of progress
- Sustainable development, able to maintain a constant pace
- Continuous attention to technical excellence and good design
- Simplicity—the art of maximizing the amount of work not done—is essential
- Best architectures, requirements, and designs emerge from self-organizing teams
- Regularly, the team reflects on how to become more effective, and adjusts accordingly
At this point, let’s take a moment to briefly clarify what IT professionals mean by the terms “Agile” and “Scrum.” The aforementioned 12 guiding principles make up the backbone of “Agile.” You can think of this as an overarching philosophy, while “Scrum” is but one process that is used to implement this philosophy in practice. Scrum may be the best-known form of Agile, but it is far from being the only one. This particular process is geared toward simplicity, efficiency, and delivering demonstrable progress in the shortest intervals. While “Scrum” may be the most popular form of Agile, other forms of Agile are also used widely throughout the IT industry. These well-known forms include: Lean Software Development, Kanban, Extreme Programming (XP), Feature Driven Development (FDD), Crystal, as well as others. There is no “right” or “true” form of Agile. Each enterprise implements the form of Agile that best suits its needs. Each “flavor” of Agile is designed to optimize product development, eliminate waste, increase communication, clear out roadblocks, and keep development teams focused on delivering a product on time and in-line with business needs.
As the name implies, the goal of Agile Scrum is to help companies meet complex changing needs, while creating high quality products and services. Scrum works by delivering large projects in smaller chunks—bite-sized product increments that a cross-functional team can begin and complete in one, short timeboxed iteration.2 As Scrum is the most widely implemented form of Agile, let’s use it to explore the best practices of a successful Agile Scrum team. The Scrum framework involves a certain prescribed process contained within time-iterative cycles. Operating in such time-box intervals allow for: Fast feedback, Continuous improvement, Rapid adaptation to change, and Accelerated delivery.3
To understand the best practices of a high functioning team, it is essential to first understand the designated roles and responsibilities of all team members. Essential roles for Scrum include the Product Owner, Scrum Master, and Product Development Team members. At a high level, ideal members perform the following roles and practices:
- The Product Owner takes input from Stakeholders, Customers, End Users, and others to create a “backlog” of necessary product requirements. They are responsible for deciding what needs to be done and when by prioritizing the requirements captured in the form of epic, features, user stories, and tasks, into a general bucket called the “Backlog.” The Product Owner works with the Development Team to clarify requirements, as well as validate the quality of the work produced.
- The Scrum Master, a servant-leader, is responsible for maintaining Scrum process discipline and making sure the team utilized prescribed Agile “ceremonies,” such as the daily Scrums (more on this later). He or She helps to lead reviews of the work that has been produced during the Sprint Review ceremony, and acts within his or her authority to remove project impediments. Throughout the Sprint cycle, working with the Product Owner, the Scrum Master helps to facilitate pulling new tasks into the Sprint in cases where the development teams execute tasks faster than expected.
- The Scrum or Development Team is responsible for helping to determine the scope and level of effort as well as executing tasks designed to create a working deliverable that fulfills the requirements as set forth by the Product Owner. Members of the team are empowered to manage their own work within the agreed-upon parameter of the current Sprint during the Sprint Planning Meeting (See Below). It is their responsibility to update a Sprint’s backlog with the status of the work agreed to be accomplished. If team members are able to produce quality work ahead of the estimated schedule, they are empowered to assist other team members with their assigned tasks or start to work on tasks prioritized for future execution.
All of these team members understanding their roles and collaborating closely are essential for the successful operation of a high functioning Agile Scrum team. Scheduled collaborations between all team members beyond day-to-day activities are baked into the Scrum process itself. One of the most essential concepts to understand about Scrum is that all team activities occur in the aforementioned time-boxed intervals referred to as “Sprints.” Sprints typically occur is 2 – 4-week timeframes. There are certain “ceremonies” or “events” in which whole participation is prescribed for each Sprint.
These Sprint ceremonies include:
- Sprint Planning meetings – A reserved time at the start of each sprint dedicated to determining how many requirements will be worked upon in the upcoming Sprint interval. The ultimate goal of this meeting is to take the highest prioritized items from the Product Backlog and perform an estimation into the complexity, scope, and length of time required for development. If prioritized work is too large in scope to fulfill in one Sprint, the team decides how to break these items down into smaller accomplishable chunks. If all chosen items are able to be executed within the span of a Sprint cycle, these items are then categized into a smaller “Sprint Backlog”(a prioritized list of requirements and/or tasks that are necessary to be accomplished by the end of the current Sprint cycle) that is used to track progress throughout the course Sprint.
- Daily Scrum or Daily Stand Up Meetings – On a daily basis, all team members participate in the daily Scrum meeting. This meeting is designed as a platform to allow all members of the team to speak, one at a time, and discuss what work was accomplished the day before, what plans need to be done today, and whether there are any impediments to accomplishing that day’s or Sprint’s tasks. Daily scrums, (preferably done in-person and solely reserved to answering the questions as previously stated), allow for all team members to have a general understanding of where the team is at any given point in the Sprint cycle, and allow the team to re-adjust tasking as necessary to accomplish the goals as agreed upon during the Sprint Planning meeting.
- Sprint Reviews or Sprint Demos – A meeting happens at the end of each sprint cycle. The team demonstrates what they’ve produced during the finished Sprint to business stakeholders and the Product Owner. Sprint Reviews are an opportunity to provide feedback, and clarify prioritization of what’s next to come.
- Sprint Retrospectives – The Sprint Retrospective is typically the last ceremony in a Sprint cycle. The goal of this meeting is to reflect upon the operational aspects of the completed Sprint. During this meeting questions, such as “What did the team do well?” and “What could the team improve upon in the next Sprint?” This meeting offers team members a platform to comment on and provide suggestions for optimizing team efficiency going forward.
While Agile Scrum can be a fairly straight forward process, undisciplined or inexperienced teams can fall into common process pitfalls that hinder rather than advance project and product development goals. Before getting into specifics, it is important to note that communication is key to the successful implementation of team goals. Team members need to be honest with each other and themselves when it comes to the distribution of roles and responsibilities. Product Owners need to be upfront on product requirements and acceptance criteria. Scrum Masters need to be engaged when facilitating meetings. Development team members need to be honest when estimating how long work will take to complete, the status of development work progress, and, crucially, whether there are any roadblocks to completing work in the current Sprint cycle. The bottom line is that in order for a group of individuals to BE a team, honest communication is key. If all members are frank with each other, team cohesion and efficiency will increase over time. Other commons mistake unseasoned teams make include:
- Skipping Scrum Ceremonies – While it is important to remember the 12 Agile Principles and that successful product development is the primary measure of progress, it is equally important to operate according to prescribed Scrum process and execute all pre-defined Scrum ceremonies. Skipping any of the ceremonies due to any reason (such as unavailability of people, vacation time, holidays) can deter essential team communication.
- Lack of “Whole Team” Mindset – While it is easy to get lost in the weeds of day-to-day tasks that are on your plate, it is important to remember that there is no ‘I’ in team. Just because one team member is done with their assigned tasks for the Sprint, it does not mean their responsibility to the team is over. By not having a “Whole Team” mindset to advance team progress on a daily basis, team members may feel like everyone is not pulling their weight toward the team goals.
- Mid-Sprint Changes – Sprint Planning meetings are key for the team to agree upon the work and tasking for the Sprint ahead. Changing the scope or adding tasking without the consent of the entire team threatens team cohesion, produces misleading metrics, and can hamper future trust between the whole team.
- Unclear goals – It is essential for all team members to have an understanding of project or product short-term, medium-term, and long-term goals. By not having clear communication about team goals, team members are not able to have a firm understanding of what it is they are working toward. This may impact successful product development if these products are built only to meet short-term specifications. This may require further re-work in the medium-term in order to facilitate long-term goals. This reduces efficiency, can increase costs, and can delay the product development timeline.
As we’ve explored, the Agile mindset promotes flexibility. Scrum provides guidelines for quick iterative product development. While many in the IT industry claim to understand Agile Scrum, there are many examples of poor Agile execution, and as a result, unhappy customers, stakeholders and professionals. By faithfully acting in prescribed Scrum roles and by executing under the prescribed guidelines while avoiding some of the common pitfalls, Agile teams can be lean, effective, product producing machines. At the end of the day, as the saying goes, “team work makes the dream work.” Agile Scrum provides a framework and guidance to operating in a team environment to achieve product goals. The more Agile Scrum is understood and faithfully executed, the more collections of individuals can fully function as teams and develop amazing products, which when released to market, ultimately stands to benefit us all.
1. Beck, K., et al. (2001) The Agile Manifesto. Agile Alliance. http://agilemanifesto.org/↩
2. “Benefits of Using Scrum.” How an Agile Framework Like Scrum Works, Scrum Alliance, www.scrumalliance.org/about-scrum/benefits.↩
3. “Overview.” What Is Scrum? www.scrumalliance.org/about-scrum/overview.↩