Welcome back to the Ultimate Guide to Agile! In Part 1, we explored the basics of Agile, its principles, and some popular frameworks.
Now, in Part 2, we’ll delve deeper into how agility works on a team level, provide a detailed look at the Scrum Framework, and discuss common approaches and pitfalls when introducing agility to teams.
Agility on a Team Level
Agility at the team level is about fostering an environment where teams can adapt, collaborate, and continuously improve. This involves enhancing communication and collaboration, adapting to change, and focusing on continuous improvement. Let’s break down what this means in practice.
First, cross-functional teams are crucial. These teams are composed of members with different skill sets, ensuring they can deliver a complete product increment with as little as possible external dependencies. For instance, in a team focusing on delivering a software product, this might include developers, testers and UX designers working together.
Iterative and flow-based development are both key elements of Agile. Iterative development involves working in short cycles or iterations, typically ranging from one to four weeks, allowing teams to regularly review their progress, gather feedback, and make necessary adjustments. On the other hand, a flow-based approach, such as Kanban, focuses on a continuous flow of work without fixed iterations. Depending on what brings the most value to the team, the approach is decided upon and pursued.
Empowerment and ownership are also vital. Teams are given the autonomy to make decisions about how they work, which encourages a sense of ownership and accountability. This environment not only improves productivity but also boosts team morale and engagement and enables the team to come up to more innovative and disrupting solutions.
Consider the example of a frontend engineer helping backend engineers during peak times to achieve the goals of the sprint (this is something I experienced myself already multiple times). This cross-functional collaboration helps the team stay on track and meet their commitments, illustrating the power of agility at the team level.
Recap of Agile Frameworks from Part 1
Here’s a quick recap of the agile frameworks we discussed in Part 1:
Frameworks / Methods | Description |
Scrum | Scrum is a framework for Agile project management that emphasizes iterative progress through time-boxed sprints. Teams work in short cycles to deliver functional product increments, with roles such as Scrum Master, Product Owner, and Team Members facilitating the process. |
Kanban | Kanban is a visual workflow management method that uses a Kanban board to visualize work items, limit work-in-progress, and optimize flow. It focuses on continuous delivery without specific time-boxed iterations. |
Extreme Programming (XP) | XP is a software development methodology that aims to improve software quality and responsiveness to changing customer requirements. Practices such as pair programming, test-driven development, and continuous integration are key components of XP. |
Lean | Lean focuses on eliminating waste, optimizing processes, and delivering value to the customer. It emphasizes continuous improvement and respect for people, often incorporating practices such as value stream mapping and just-in-time development. |
Crystal | Crystal is a family of methodologies that focuses on people, interaction, community, skills, and talents. It is designed to be adaptable and considers the size and criticality of the project. |
In this article we will focus mainly on Scrum and provide:
A short introduction about scrum and it’s key components based on the Scrum Guide,
expand beyond the scrum guide and provide you with challenges and common pitfalls we saw in different organizations around scrum and then
move forward to introduce some best practices on how to solve some of the problems we encountered in different organizations on a team level.
Introduction to Scrum
Scrum is a popular Agile framework used primarily for software development, which later on expanded to other fields. It structures work in iterations so-called sprints that last of up to a month. Scrum has some key components that focus on: roles, events and artifacts.
In this section, we will first summarize the Scrum Guide to provide a foundational understanding of Scrum. Then, we’ll expand on this framework with insights and best practices based on our own experiences, as well as common pitfalls observed in various organizations. For a comprehensive overview, the Scrum Guide itself is a highly recommended read as it offers detailed insights in a concise format.
Official Definition by the Scrum Guide: Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
Scrum Pillars
Scrum is built upon three foundational pillars that support the entire framework. These pillars ensure that the process is transparent, that progress is regularly inspected, and that the team adapts based on what they learn.
Transparency: Transparency means that all aspects of the process must be visible to those responsible for the outcome. This includes visibility into the progress of the work, the process being followed, and any issues or obstacles that arise. Artifacts like the Product Backlog, Sprint Backlog, and Increment must be transparent to all stakeholders to ensure common understanding.
Inspection: Regular inspection of Scrum artifacts and progress towards a sprint goal is crucial. Frequent inspection points (e.g., during Daily Scrums, Sprint Reviews, and Retrospectives) allow the team to detect any variances or problems early. This ensures that any issues can be addressed promptly to avoid significant deviations from the expected outcomes.
Adaptation: Adaptation involves adjusting processes and plans based on the findings from inspections. If an inspection reveals that one or more aspects of a process deviate outside acceptable limits, adjustments must be made. This can mean altering the Product Backlog, changing the approach for the next sprint, or addressing team dynamics. The goal is to continually improve and adapt to ensure the best possible outcomes.
Scrum Key Roles
In Scrum, there are three primary roles, each crucial for the framework’s success:
Scrum Master: The Scrum Master is a facilitator and coach responsible for ensuring the Scrum Team adheres to Scrum principles and practices. They help the team remove impediments, facilitate events, and foster an environment for continuous improvement. The Scrum Master is accountable for the team’s effectiveness and ensures that Scrum is understood and implemented properly.
Product Owner: The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. They manage the Product Backlog, ensuring it is visible, transparent, and prioritized according to the business’s needs and goals. The Product Owner collaborates closely with stakeholders to gather requirements and feedback, and with the development team to clarify work items and priorities.
Developers: The Developers, previously known as the Development Team, are a self-organizing group of professionals who do the work of delivering a potentially shippable product increment at the end of each sprint. They are cross-functional, possessing all the necessary skills to create the product increment. Developers are responsible for planning their work during Sprint Planning and for ensuring that their work aligns with the sprint goal.
Sidenote: I like to use instead of “Developers” the word Team Members, to also signal that scrum can be used outside IT.
Scrum Events
Scrum is structured around five events that ensure regularity and minimize the need for additional meetings. These events create a rhythm and provide opportunities for inspection and adaptation.
Sprint: The heart of Scrum is a sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product increment is created. Sprints have consistent durations throughout a development effort.
Sprint Planning: This event marks the beginning of the sprint, where the team collaborates to define the sprint goal, select Product Backlog items to work on, and create a plan for delivering those items. The Product Owner ensures that the backlog is prioritized, and the Developers forecast what they can achieve.
Daily Scrum: A short, time-boxed event of 15 minutes held every day of the sprint. The Daily Scrum is an opportunity for the Developers to synchronize activities and create a plan for the next 24 hours. They discuss what was done the previous day, what will be done today, and identify any impediments.
Sprint Review: Held at the end of the sprint to inspect the increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team presents the results of their work to key stakeholders and discusses progress towards the product goal. It is an opportunity to gather feedback and make informed decisions about the next steps.
Sprint Retrospective: This event provides an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next sprint. The Retrospective focuses on the team’s processes and interactions, seeking ways to enhance efficiency and quality.
Scrum Artifacts
Scrum artifacts provide key information to ensure transparency and provide opportunities for inspection and adaptation.
Product Backlog: An emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
Sprint Backlog: The set of Product Backlog items selected for the sprint, plus a plan for delivering the product increment and achieving the sprint goal. The Sprint Backlog is a highly visible, real-time picture of the work that the Developers plan to accomplish during the sprint, and it belongs solely to the Developers.
Increment: The sum of all Product Backlog items completed during a sprint and the value of the increments of all previous sprints. The increment must be in a usable condition regardless of whether the Product Owner decides to release it. Multiple increments can be created within a sprint.
Expanding on Scrum: Challenges, Application in the Real World and Mythsbusting
Despite its popularity, Scrum, especially the Scrum Guide doesn’t provide answers to a lot of challenges we see in organizations and some of its practices are often misunderstood. Below you can find the most common challenges and myths we saw in organizations when implementing scrum.
Challenge 1: Commitment
Commitment can be a significant challenge in Scrum. Teams may struggle to commit to sprint goals and default back to commit to a list of work items that they can deliver until the end of the sprint. This disables a lot of flexibility in reaching the sprint goal and focuses on a mindset of output instead of outcomes.
The problem arises when teams prioritize completing a predefined set of tasks over achieving the broader sprint goal (if at all one is defined). This can lead to a rigid mindset where the team is more concerned with ticking off items on a list rather than delivering value. As a result, the team may miss opportunities to pivot and adjust their work based on feedback and changing circumstances. This focus on output can undermine the core Agile principle of responding to change over following a plan.
To address this challenge, teams can adopt several strategies!
Clearly Define and Communicate the Sprint Goal: The sprint goal should be a clear and concise statement of what the team aims to achieve by the end of the sprint. It serves as a guiding star for the team, helping them stay focused on delivering value rather than just completing tasks.
Try out: At the beginning (ideally before, to get an alignment with all stakeholders) of each sprint, during Sprint Planning, ensure that the sprint goal is well-defined and understood by all team members. The Product Owner should articulate the goal clearly, and the team should discuss how their planned work contributes to this goal. Regularly revisit the sprint goal during Daily Scrums to keep it at the forefront of everyone’s mind.
Foster a Culture of Outcome-Oriented Thinking: Shifting the team’s mindset from output (completing tasks) to outcomes (delivering value) is crucial for commitment. This means focusing on the results and benefits of their work rather than just the completion of work items.
Try out: Encourage the team to ask themselves how each work item contributes to the sprint goal and the overall value delivered to the customer. Use metrics that measure outcomes, such as customer satisfaction, rather than just output metrics like the number of work items completed. Recognize and reward the achievement of outcomes, not just the completion of tasks.
Promote Flexibility and Adaptability: Flexibility is key to responding to changes and new information that arise during the sprint. A rigid focus on a predefined list of tasks can hinder the team’s ability to adapt and achieve the sprint goal.
Try out: Allow the team to adjust their work items if it better serves the sprint goal. This means being open to reprioritizing tasks, adding new ones, or dropping less critical ones based on the latest feedback and information. Encourage team members to collaborate and support each other in reaching the goal, rather than working in silos on their individual work items.
By clearly defining and communicating the sprint goal, fostering a culture of outcome-oriented thinking, and promoting flexibility and adaptability, teams can overcome the challenge of commitment in Scrum. These strategies help shift the focus from merely completing tasks to delivering real value, ensuring that the team remains agile and responsive to change.
Challenge 2: No Goals or Multiple Goals
In Scrum, having clear and focused goals is crucial for guiding the team’s efforts and measuring their success. However, teams often face the challenge of juggling multiple goals due to varying stakeholder demands. This can lead to conflicting priorities and a lack of clear direction. For instance, teams might be asked to pursue multiple product goals or sprint goals simultaneously. Additionally, they often need to balance these goals with operational tasks or business-as-usual activities, which further complicates their ability to focus.
On the other hand, some teams operate without any defined product or sprint goals. In such cases, commitments are made at the level of individual work items, and the team’s success is measured by whether they complete these items. This approach can result in a lack of cohesion and shared purpose, making it difficult for the team to align their efforts towards a common objective.
Establish Clear and Prioritized Goals: One effective approach is to ensure that teams have clear and prioritized goals. To achieve this you will need to get all your stakeholders on board and explain to them why focus on one product and sprint goal is key.
Try out: Create an understanding that multitasking slows us down and that value is delivered later. You can try to do this via this game in a more fun setting: https://www.crisp.se/gratis-material-och-guider/multitasking-name-game
Try out: Within each sprint, identify a single sprint goal that supports the product goal. This ensures that the team can concentrate their efforts on delivering specific outcomes. Try to convince the scrum team to try it out at least for 2-3 sprints and then review this approach together in one retrospective to ensure to spot the challenges and think about improvements.
Try out: While focusing on goals, ensure that operational tasks and business-as-usual activities are accounted for. You can try to do this in multiple ways. What we saw that works in an okayish manner is:Define “Health Metrics” that represent vital KPIs of your product. Example: A health metric for a Website that promotes cat toys could be “Page Load Speed under 3 seconds”. Whenever this health metric is above the threshold the team need to fix asap as it could lead to losing a high volume of customers. Obviously this would disrupt the sprint and the sprint goal. The idea is that the team looks at those health metrics making sure to keep quality high when pursuing a product goal and sprint goal.Set aside a fixed percentage of the sprint capacity for operational or business-as-usual work items. Here the pitfall can be that teams focus more extensively on delivering output rather than outcomes and it is tricky to reach exatly the capacity within a sprint.What we saw that worked better was to establish for a broader timeframe a guidance on how many operational or business-as-usual work items should be tackled during a quarter. Example: in a quarter each team should work on operational items between 15-20%. This gives the team the flexibility within each sprint to have more or less focus on operational work items and helps them balance between times with high stakes on sprint goals.
Challenge 3: No Product
In Scrum, the primary goal is to deliver a potentially shippable product increment at the end of each sprint. This requires that teams have a clear and well-defined product to work on. However, confusion around what constitutes a product can hinder progress and make it challenging for teams to focus on delivering value. For instance, a team might be responsible for a component that is part of a larger product used by end users. If this component on its own cannot deliver value to the end users, the team may struggle to pursue incremental product development effectively.
When teams are tasked with working on components rather than complete products, they often face several challenges:
Lack of Clear Goals: Without a clear understanding of the product, teams may lack a unified vision and goals, leading to misalignment and inefficiencies.
Difficulty in Delivering Value: Components that do not directly deliver value to end users can make it hard for teams to demonstrate tangible progress and benefits at the end of each sprint.
Fragmented Work: Working on isolated parts can result in fragmented efforts, where teams focus on technical tasks rather than user-centric outcomes.
If this is something you are struggling with, then you can try some of the ideas below.
Try out: Form cross-functional teams that include members with diverse skills required to deliver end-to-end value. This sounds really easy however to make that change a lot needs to happen.
if this doesn’t work, you can try out to move still in a direction even though not ideal by…
Try out: Identify the value each component brings to the overall product. Even if a component cannot directly deliver value to end users, understanding its role in the larger product ecosystem can help teams align their efforts. Keep information flowing and accessible in an easy way.
Challenge 4: Too many Meetings and Overhead
One of the common complaints about Scrum is the perception of too many meetings, leading to significant overhead and reduced productivity. Teams often feel overwhelmed by the number of Scrum events, such as Sprint Planning, Daily Scrums, Sprint Reviews, Sprint Retrospectives and this is even more present if they have additional meetings in place. This can lead to a sense of meeting fatigue, where the focus shifts from actual work to attending and preparing for these events.
Are you having problem with the daily scrum? This is something we see often that the daily scrum is being held as a status meeting and so lasts much longer than the intended timebox, which is totally not what it is intended for.
Try out: Agree within the Team on looking at the progress towards the sprint goal instead of going through every work item in the sprint and “presenting” the status.
Are there generally too many meetings / events in place in addition to the scrum ones??
Try out: Investigate the current meetings and see how they contribute to the teams success. Try to think if the meetings can be covered by an asynchronously via Chat (MS Teams, Slack, …) or E-Mail. Here Atlassian build a nice infographic in regards to this topic: https://atlassianblog.wpengine.com/wp-content/uploads/2018/05/meeting-flowchart-update-v15.jpg
Myth 1: Scrum is only for IT
One common myth is that Scrum is only for software development. In reality, Scrum can be applied to any complex, innovative scope of work that needs to be tackled by a team. A Marketing Team responsible for Campaigns could use Scrum to reach specific campaign goals in a specific iteration such as increasing impressions on the landing page of a product by x% by the end of the sprint.
Myth 2: Scrum is rigid and doesn’t allow changes
This myth can be looked into 2 different ways. One way is that scrum is rigid in terms of how scrum is lived within a team by the scrum guide. While Scrum provides a structured framework, it encourages teams to adapt and improve their processes within it. That’s why you have scrum events like the retrospective in place.
When teams start with scrum it is recommended to start by the book. Meaning following the scrum guide as much as possible. However after a few iterations the teams should improve on the initial setup and configure scrum so that it works for them the best possible.
Myth 3: Estimations are dictated by Scrum
One of the common misconceptions about Scrum is that it enforces a rigid structure for estimations, dictating how teams should estimate their work. This myth can create resistance and confusion, especially among teams new to agile practices. It leads to the belief that Scrum mandates a specific method for estimating tasks, such as story points or hours, which can feel restrictive and counterproductive for some teams.
Scrum however doesn’t dictate anything related to story points estimation or any type of estimation. Meaning that estimations are not per se part of scrum and came most likely from Ron Jeffries which was one of the contributors to the agile manifesto. Even he pubilshed an article called “Story Points Revisited” that explains that he is not that big of a fan of it.
Myth 4: Scrum prescribes writing User Stories
A common misconception about Scrum is that it prescribes the use of User Stories for documenting product backlog items. This belief likely stems from the integration of practices from Extreme Programming (XP) into Scrum by agile practitioners. XP emphasizes User Stories as a primary way to capture customer requirements, and this method became popular among teams adopting Scrum. However, the Scrum framework itself does not mandate any specific format for capturing requirements. The Scrum Guide defines roles, events, and artifacts but leaves the techniques for managing work to the team’s discretion.
In reality, Scrum is a flexible framework that focuses on iterative development and continuous improvement.
While User Stories are widely used within many Scrum teams due to their effectiveness, they are not a required element of Scrum. Teams can use various formats like use cases, functional specifications, or simple task descriptions to describe Product Backlog items.
The key is to ensure that the items are clear, concise, and understood by both the team and stakeholders, allowing the team to choose the best tools and techniques for their specific context.
Conclusion
In this second part of the Ultimate Guide to Agile, we have delved deeper into how agility functions at the team level, focusing primarily on the Scrum framework. We also provided a detailed overview of Scrum, including its roles, events, and artifacts, to give you a solid foundation in this popular agile framework.
Beyond the Scrum Guide, we explored common challenges teams face, such as commitment issues, juggling multiple goals, and confusion around product definitions. By addressing these challenges with practical strategies and best practices, teams can enhance their effectiveness and remain focused on delivering value.
Finally, we tackled some common myths about Scrum, clarifying misconceptions about its rigidity, applicability outside IT, and its supposed prescriptions for estimations and user stories. By dispelling these myths, we hope to provide a clearer understanding of Scrum’s flexibility and adaptability.
As you continue your Agile journey, remember that the key to success lies in continuous improvement and adapting the framework to meet your team’s specific needs. Stay tuned for more insights and practical advice in future parts of our Ultimate Guide to Agile.
Don’t forget to subscribe to our newsletter to keep up with the latest agile trends and tips.
Comentarios