Viewing Posts by Christian Bisson
Beyond the Basics: Essential Topics to Address When Forming a Scrum Team
When forming a new Scrum team, it’s crucial to look beyond the foundational aspects of Scrum and consider the broader ecosystem of practices, mindsets, and collaborative tools that contribute to a team's long-term success. This article focuses on just a few of the many topics that can be crucial for a team's growth and sustainability. In my experience, teams are often simply taught what Scrum is, but many essential elements are overlooked. This can happen due to the inexperience of the coach or Scrum Master; lack of time to properly prepare; or, unfortunately, a lack of buy-in from managers who push for training to be completed as quickly as possible. Addressing these additional areas can make a significant difference in setting up a team for success:
1. Team Culture and Psychological Safety
2. Defining Team Values and Working Agreements
Examples of working agreements include:
These agreements create clarity and foster a shared commitment to team practices.
3. Effective Use of Collaboration Tools
4. Backlog Management and Prioritization Techniques
Additionally, emphasize the importance of properly splitting backlog items vertically so that each item delivers incremental value. This approach ensures that each piece of work completed adds real user or business value. Define a clear definition of “done” to establish a shared understanding of completion criteria and maintain high-quality standards across the team. The importance of story points should also be highlighted. While story points can aid in planning, their main strength lies in triggering discussions and helping the team share a common understanding of the complexity and scope of backlog items. This practice fosters better alignment and clarity across the team.
5. Agile Mindset Beyond Scrum
Conclusion
What other topics are important for you when you train new teams?
|
The Power of Agile Team Cohesion
by Christian Bisson Agile team cohesion is the seamless collaboration, effective communication, and shared goals and values among team members. I frequently prompt new teams to reflect on a time they thought things were going great; consistently, "the team" emerges as the primary factor contributing to that moment’s greatness. Being intangible, team cohesion is often undervalued, with some viewing it as simply as an overhead. For example, team building activities, or even retrospectives that have a bit of fun included in them can be seen as a waste of time. Heck I’ve also been told by team members that it was an insult to their intellect! Despite that, the impact of team cohesion is far-reaching, offering substantial benefits to the team and the project at hand.
Enhanced CommunicationCohesive teams communicate more effectively, leading to smoother workflows through several key mechanisms:
Increased Productivity
ConclusionTeam cohesion is important, and it’s important for all members of the team to understand its value so that everyone contributes to it. How do you actively contribute to your team's cohesiveness? Share your insights and any noteworthy team-building activities you've found effective.
|
4 Pitfalls of an External Product Owner
By Christian Bisson Within the realm of agile project management, the composition of a team greatly impacts its success. While all team members play a vital role, the inclusion of an external product owner (as opposed to an internal one) poses challenges that can hinder teams’ potential to deliver value to users. In this post, I will highlight four potential pitfalls of having a product owner external to the team, with real-life examples underscoring the benefits of an integrated team approach.
1. Misalignment and Unclear VisionWhen a product owner is external to the team, misalignment and an unclear vision can arise. The absence of direct day-to-day collaboration stifles the shared understanding of project goals, priorities, and user needs. This lack of alignment makes it difficult for the team to make informed decisions and deliver a product that meets customer expectations. Example: Imagine a software development project where the product owner is external and has limited interaction with the team. This separation hinders effective communication and prevents the product owner from gaining in-depth knowledge of the project domain. As a result, misaligned priorities and a fuzzy vision emerge, leading to a disconnect between the team's efforts and the desired outcomes.
2. Inefficient Prioritization and Decision MakingAn external product owner often leads to inefficient prioritization and decision-making processes. Without a direct line of communication, the product owner's expertise and insights may not reach the team effectively. As a result, crucial decisions regarding scope, timelines and trade-offs may be delayed or misinterpreted, leading to project inefficiencies and missed opportunities. Example: In a marketing campaign project, an external product owner who lacks real-time interaction with the team may struggle to grasp the evolving market trends and user preferences. Consequently, delays in decision making occur, preventing timely adjustments to the campaign strategy, ultimately impacting its effectiveness and return on investment.
3. Communication Gaps and Feedback DelaysWith an external product owner, communication gaps and feedback delays become commonplace. The limited availability and reduced involvement of the product owner hinder continuous communication and the timely exchange of information. This results in a slower feedback loop, preventing the team from promptly addressing concerns, adapting to changing requirements, and delivering high-quality increments. Example: In a mobile app development project, an external product owner may have competing priorities and limited availability for sprint reviews. As a result, feedback on delivered iterations may be delayed, preventing the team from incorporating valuable insights—and potentially leading to inefficient use of development resources.
4. Detached from User-Centric MindsetWhen the product owner is external, the team risks losing touch with a user-centric mindset. The direct contact between the product owner and end users diminishes, inhibiting the team's understanding of user needs, preferences and pain points. Without this critical insight, the team may struggle to develop solutions that truly resonate with the target audience. Example: Consider an e-commerce project where an external product owner has limited interactions with actual customers. The team, lacking direct access to user feedback and insights, may fail to anticipate user behavior, resulting in an e-commerce platform that falls short of meeting customers' expectations and inhibits business growth.
ConclusionIn the agile realm, the inclusion of an external product owner introduces several pitfalls that can hinder project success. Misalignment, inefficient decision making, communication gaps, and a detached user-centric mindset are among the challenges an integrated team approach aims to mitigate. By recognizing the drawbacks of an external product owner, agile teams can foster collaboration, transparency, and a deep understanding of customer needs, ultimately leading to more successful project outcomes. The above points assume there is one external product owner for the team. However, if there are multiple external product owners in a team, all the challenges mentioned earlier become even more significant. It not only amplifies the existing issues, but also adds to the tension and confusion within the team. |
Stop Patching: 5 Steps to Find the Core Problem
When facing a challenge in a project or during the evolution of your product, it's natural to look for quick solutions that can help you move forward. However, this approach can lead to "patching" the symptoms rather than addressing the root cause of the problem. In the context of agile software development, a good example of patching that I see trending is relying too much on the Scrum Master as a "Swiss army knife," where any problem is fixed by expecting them to compensate in some way. While it's true that the Scrum Master is a versatile member of the team, it's important to remember that their primary responsibility is to facilitate the Scrum framework, not to be a jack-of-all-trades. Instead of treating the Scrum Master as a catch-all role, it's crucial to find the core problem that's causing the challenge and address it directly. This may require some investigation, analysis and collaboration among the team members, but the payoff can be significant. By identifying the root cause, you can avoid repeating the same issue in the future, improve the overall quality of the product, and increase the team's productivity and morale. So, how can you find the core problem when facing a challenge? Here are some steps that can help: 1. Define the problem. Start by clarifying what exactly the challenge is that you're facing. Is it a technical issue, a communication problem, a misalignment of expectations or something else? Write down a clear and concise description of the problem that everyone can understand. 2. Collect data. Gather information about the problem by talking to stakeholders, reviewing documentation, analyzing metrics or conducting user research. The goal is to get a holistic view of the problem, its impact and its potential causes. 3. Analyze the data. Once you have collected the data, you need to make sense of it. Look for patterns, trends and insights that can help you identify the root cause. This may require some critical thinking, brainstorming or hypothesis testing. 4. Validate the hypothesis. Once you have a working theory of what's causing the problem, test it by gathering more evidence, conducting experiments or soliciting feedback from the team. The goal is to confirm or refute your hypothesis and refine your understanding of the problem. 5. Address the root cause. Finally, once you have identified the core problem, take action to address it directly. This may involve implementing a new process, fixing a bug, improving communication or changing the team's dynamics. Conclusion So, the next time you face a challenge, resist the urge to rely on the Scrum Master as a Swiss army knife and instead use their expertise to facilitate the process of finding the root cause. How do you deal with challenges? |
Measure, Measureā¦and Measure Again!
by Christian Bisson
In a complex world where we strive to improve, there is one trending weakness that I’ve seen amongst many teams and organizations—they measure little to nothing, and make decisions based on “gut feeling.” Having key metrics is a powerful tool to identify areas to improve, and not just for weak points—you want to recognize strong points as well so that you can continue them. Here are a few examples…
ValueHow many times have you seen teams happy to deliver something—only to have absolutely no idea what value was ultimately gained from that delivery? There are a few ways you can be blind to the value being delivered (or not delivered):
All too often, people waste money when they could focus their resources elsewhere if they measured the return on investment (ROI) and adapted accordingly.
Delivery predictabilityWhat will be delivered, and when? Every organization faces a challenge to know this. And all too often, typical random delivery dates are given to stakeholders—and forced on teams. This in turn hurts the quality of the deliverable (not to mention the very small odds that the dates are even being respected). By measuring on a small scale (like a team’s velocity throughout sprints) or a larger scale (like being familiar with SAFe and its “product increments”), you can compare results to actual data to make more reliable predictions (at the end of the day, it is still a guess).
Product backlog healthThroughout the years, I’ve seen many backlogs, from small to gigantic. And I rarely see any of them being measured to make sure they’re actually healthy. The definition of “healthy” varies, but in this case let’s assume it means that the backlog is an ordered/usable artefact that teams can rely on to know what to work on next to bring value to stakeholders.
Here are a few things that can be measured:
ConclusionThere are so many things that can be measured and used to properly align next steps—and they require the proper tools to do it efficiently. You want to spend as little time as possible getting the data and results that you need, and utilize reliable “live” information (with little cost to get it).
What will you be measuring in 2023? What do you think your blind spots are? |