Agile

TL;DR: Product Owner and Scrum Master? Combining the roles of Product Owner and Scrum Master in one individual is a contentious topic in the Agile community. A recent LinkedIn poll (see below) revealed that 54% of respondents consider this unification useless, while 30% might accept it in rare moments. This blog post explores the implications of merging these roles, emphasizing the importance of distinct responsibilities and the potential pitfalls of combining them. We also consider exceptions where this approach might be temporarily justified and analyze the insightful comments from industry professionals. The LinkedIn Poll: Could the Product Owner and Scrum Master Be the Same Individual? On May 23, 2024, I asked a simple question: Could the Product Owner and Scrum Master be the same individual? Or is mixing roles disadvantageous? Agile puts a lot of emphasis on focus. How come then that so often practitioners are asked — or expected — to cover for two roles simultaneously? Penny-pinching or smart move from a holistic perspective? Referring to the comments, the majority strongly opposes combining the Product Owner and Scrum Master roles, citing significant differences in responsibilities and the need for checks and balances. Conditional acceptance is noted mainly in startup contexts with resource constraints. Some are open to exceptions but remain cautious about long-term viability. Personal experiences highlight the challenges and potential conflicts, while flexible approaches are suggested for specific contexts. We can identify five categories among the comments: 1. Strict Opposition: Fundamental Differences in Roles The Product Owner and Scrum Master roles have distinct responsibilities, requiring full-time attention and unique skill sets. Combining them can lead to neglect and conflict of interest and undermine the healthy tension that balances product goals with team capacities. The roles act as checks and balances, ensuring ambitious goals and realistic execution. 2. Conditional Acceptance: Resource Constraints in Startups In resource-limited situations, such as startups, combining roles may be necessary due to budget constraints. However, this should be a temporary solution until the organization can afford to separate the roles. 3. Skeptical But Open to Exceptions: Specific Contexts and Temporary Solutions While generally inadvisable, combining roles might be feasible in exceptional circumstances, such as during temporary absences or in small teams, provided there is clear role differentiation and support. 4. Experiential Insights: Personal Experience Individuals with personal experience managing both roles or observing this practice often find it problematic due to inherent conflicts of interest and the heavy workload. 5. Pragmatic and Flexible Approaches: Practical Solutions Some suggest rotating the Scrum Master role among team members or having a Developer take on the role to balance responsibilities. Understanding Agile principles and maintaining flexibility in role management can help mitigate potential issues. Ten Reasons Why Combining Product Owner and Scrum Master Roles Is Not a Good Idea What other reasons might there be to question the idea of unifying Product Owner and Scrum Master roles? Let’s have a look: 1. Conflict of Interest Combining the roles of Product Owner (PO) and Scrum Master (SM) creates a conflict of interest. The PO maximizes the product’s value, often requiring prioritization and tough trade-offs. The SM ensures Scrum practices are followed, fostering a healthy team environment. Combining these roles compromises both priorities, reducing objectivity and effectiveness. 2. Loss of Focus Each role demands full attention to be effective. The PO must stay engaged with stakeholders, market trends, and the Product Backlog while creating alignment with their teammates. Simultaneously, the SM needs to focus on coaching the team, removing impediments, and supporting changes at the organizational level to improve the team’s environment. Combining roles can dilute focus, leading to suboptimal performance in both areas. 3. Compromised Accountability Scrum thrives on clear accountabilities. The PO is accountable for the Product Backlog and value delivery, while the SM is accountable for the Scrum process and team health. Merging these roles blurs the accountability a Scrum team’s success is based on. 4. Reduced Checks and Balances Scrum’s design includes built-in checks and balances where the PO focuses on improving value creation, while the SM ensures sustainable pace and quality. Combining the roles removes this tension, potentially leading to burnout or technical debt due to a lack of restraint on delivery pressures. 5. Increased Risk of Micromanagement Combining roles can lead to micromanagement, as the individual may struggle to switch between facilitation and decision-making. This can undermine the team’s self-management, reducing creativity and innovation. 6. Decreased Team Support The SM role involves supporting the team by removing impediments and ensuring a healthy work environment. A combined role may prioritize product issues over team issues, reducing the support the team receives and impacting morale and productivity. 7. Impaired Decision Making The PO must make decisions quickly to adapt to market changes, while the SM needs to foster team accord and gradual improvement. Combining these roles can slow decision-making processes and create confusion within the team regarding priorities. 8. Diluted Expertise Both roles require specific skills and expertise. A PO needs strong business acumen, while an SM needs a deep understanding of agile practices and team dynamics. Combining the roles often means one skill set will dominate, leaving gaps in the other area. 9. Impeded Transparency The Scrum framework relies on transparency to inspect and adapt effectively. A single person handling both roles may unintentionally hide issues or conflicts to maintain the appearance of progress, thus impairing the team’s ability to improve continuously. 10. Undermined Scrum Values Combining roles can undermine the Scrum values of focus, openness, respect, commitment, and courage, as the individual may struggle to balance conflicting responsibilities and provide the necessary support for the team to embody these values effectively. Consequently, by separating the roles of Product Owner and Scrum Master, organizations ensure clear accountability, maintain checks and balances, and foster a healthier, more productive Scrum environment. Additional Considerations What else do we need to consider? Five issues come to mind: 1. Role Synergy vs. Role Conflict While it’s tempting to think that combining roles might streamline processes and communication, each role has distinct and sometimes conflicting responsibilities. Consider whether the short-term gains of combining roles might be outweighed by long-term inefficiencies and conflicts. 2. Impact on Team Dynamics Consider how the combination of roles might affect team dynamics. A single person wielding both roles could inadvertently create a hierarchical dynamic, undermining the flat structure that Scrum promotes and potentially leading to reduced team morale and engagement. 3. Sustainability and Burnout The workload for both roles can be intense. Combining them can lead to burnout for the individual trying to manage both responsibilities. Think about how this might affect their ability to perform effectively over time and the potential impacts on team stability and productivity. 4. Training and Development Reflect on the development paths for team members. Combining roles might hinder individuals’ ability to specialize and grow in their respective areas. It might be more beneficial to invest in strong, separate training programs for Product Owners and Scrum Masters to ensure they can excel in their distinct roles. 5. Adaptability To Change Agile practices, including Scrum, thrive on adaptability. Combining roles might reduce the team’s ability to quickly adapt to changes, as the dual-role individual could be overloaded and less responsive to necessary pivots in product development or team facilitation. Three Exceptions Where Combining the Product Owner and Scrum Master Roles Might Be Justified By now, we have a solid understanding that under usual circumstances, it is not a good idea to combine the Product Owner and the Scrum Master roles. However, under which circumstance might it be acceptable? Let’s delve into the following: 1. Small Startups or Early-Stage Companies Context In the early stages of a startup, resources are often limited. The team might be small, focusing on rapid development and iteration to find product-market fit. Justification Combining the roles can help streamline decision-making processes and reduce overhead. The person in the dual role can quickly pivot and make changes without waiting for coordination between separate roles. Considerations This should be temporary until the startup grows and can afford to hire separate individuals for each role. As the company scales, the complexity and workload will likely necessitate separating the roles to maintain effectiveness and prevent burnout. 2. Temporary Absence or Transition Period Context If the organization is undergoing a transition, such as the departure of a Scrum Master or Product Owner, it might be necessary to combine roles temporarily to ensure continuity. Justification Having a single individual temporarily fill both roles can provide stability and maintain the momentum of ongoing projects. It ensures that the Scrum events continue to be facilitated and that Product Backlog management does not lapse. Considerations During this period, the organization should actively search for a replacement to fill the vacant role. Additionally, the individual in the dual role should receive support to manage their workload, such as delegating non-critical tasks to team members. 3. Highly Experienced Agile Practitioner Context In situations where an organization has an individual with extensive experience and a deep understanding of both Scrum and the product domain, they might be capable of effectively handling both roles. Justification An experienced agile practitioner might have the skills and knowledge to temporarily balance the demands of both roles, especially in crisis situations where their expertise is crucial to navigating complex challenges. Considerations This should be a short-term solution even with a highly skilled individual. The organization should closely monitor the impact on the team and the individual’s workload. Continuous feedback from the Scrum team and stakeholders is essential to ensure that combining roles does not negatively affect productivity and morale. Additional Guidance Clear communication: In any of these scenarios, it is crucial to maintain clear communication with the team about the temporary nature of the combined role and the reasons behind it. This transparency helps manage expectations, and fosters trust within the team. Monitoring and support: Regular check-ins are necessary to assess the individual’s well-being and effectiveness in managing both roles. Providing additional support, such as temporary assistance or redistributing some responsibilities, can help mitigate the risk of burnout. Plan for transition: Have a clear plan for transitioning back to separate roles as soon as feasible. This includes setting criteria for when the transition will occur, such as reaching a specific team size in a startup or hiring a new team member during a transition period. By considering these exceptions and managing them thoughtfully, organizations can navigate periods where combining the Product Owner and Scrum Master roles might be justified while minimizing potential drawbacks. Food for Thought By thoroughly considering the following aspects, you can make a more informed decision about whether combining the Product Owner and Scrum Master roles is the right move for your organization: Experimentation and Feedback If the idea of combining roles persists, consider running it as a time-boxed experiment. Gather feedback from the team and stakeholders before making a permanent change. This can provide insights into the practical implications and help you make a more informed decision. Cultural Fit Assess whether this change aligns with your organization’s culture and values. Scrum and Agile practices often challenge traditional hierarchies and thrive in a culture of collaboration and continuous improvement. Ensure that any role changes support rather than hinder these cultural elements. Long-Term Vision Keep the long-term vision in mind. Decisions made today should support the organization’s goals and values in the future. Consider how role clarity and adherence to Scrum principles will impact your team’s ability to deliver value continuously. Conclusion While combining the Product Owner and Scrum Master roles might seem efficient in specific contexts, it generally poses significant risks to the effectiveness of Scrum teams. These roles’ distinct responsibilities, necessary skills, and built-in checks and balances are crucial for fostering a productive and balanced environment where Scrum teams can thrive. Although there are rare situations, such as in resource-constrained startups or temporary transitions, where merging these roles might be justified, these should only be temporary solutions with straightforward plans for separation. The insights from the LinkedIn poll and comments highlight the importance of maintaining role clarity to ensure sustainable team performance and alignment with Agile principles.

By Stefan Wolpers CORE

The Agile methodology is a well-established and popular option for project management success. You can expect to see it in industries such as engineering, manufacturing, aerospace, pharmaceuticals, and architecture. Whether you’re a development professional currently working in a Scrum-focused environment or expect to soon, now is the ideal time to plan your long-term path for career growth in such settings. Creating milestones along your progression will help you stay motivated while providing goal-related reminders. Success with career advancement plans could also help you secure lucrative, rewarding positions that offer decision-making opportunities and other perks. Acquire Key Skills and Certifications The leaders of Agile workplaces usually require growth-focused workers to have specific skills and knowledge they gradually build during their time with their respective companies. Some fundamentals are: Scrum Kanban Customer-focused engagements A test-first mindset However, once people develop mature Agile understandings, additional skills can make them more valuable to their colleagues and employers, increasing career growth potential. They include: Collaborative development readiness Ownership and commitment An understanding of Agile architecture Developers working in Agile workplaces should strongly consider earning career-boosting certifications. Most of these options cost several hundred dollars and up, but you should consider them long-term investments. They’ll show superiors you’ve demonstrated specific competencies and are serious about climbing the career ladder. New to Agile Development and Scrum? Take This Course. Embrace Scrum Values Having the right skills is a good start, but people with career growth goals must live the scrum values at work and set good examples for others. These are also the individuals many leaders want to hire when establishing or strengthening Scrum practices in an Agile environment. Statistics indicate many critical roles have annual attrition rates surpassing 30%, showing the challenges of Agile talent retention. However, brands have made numerous changes to encourage employee loyalty. Some switched from individual to team-based bonuses. When someone embraces scrum values, they naturally encourage others to follow their lead. Besides increasing project success rates and increasing the likelihood of associated perks, someone who consistently upholds relevant values will get noticed for upcoming promotions. Seek Roles Resulting in Leadership Opportunities Moving along the Agile career path also means proactively looking for roles that give someone leadership responsibilities, such as Product Owner and Scrum Master. Treat this step as a progression of your earlier decision to get specific certifications, if applicable. For example, passing the Scrum Master exam requires scoring at least 74% on a 50-question exam. Hiring managers should appreciate the willingness to put yourself forward for roles as they become available. Doing so reinforces your interest and may prevent the business from needing to hire externally. Building your network is also essential, especially because your first leadership position may be somewhere other than your current workplace. Enthusiastically express your interest in Agile leadership to anyone with potentially useful connections. When attending networking events, always have updated copies of your resume to distribute. Then, you can follow up earnest conversations with the document listing your skills, accomplishments, and experience. Remain Adaptable Working as a developer in a rapidly evolving tech landscape requires an open mind and willingness to adapt quickly to changing trends affecting your role. Consider how one study found that 41% of IT leaders favored passwordless authentication methods. That result made some professionals predict that enterprises across industries will transition to passkeys from passwords. Organization-specific changes could also occur due to business growth, new designations of responsibilities, new focuses, expanded product lines, and other decisions. When Agile developers can adapt to new challenges, they’ll demonstrate their reliability and ability to stay level-headed during short-term disruptions. Developers should also consider how they can adapt personal processes to new circumstances. Succeeding will allow them to maintain consistent workflows while navigating differences. Prioritize Continuous Learning A love of continuous learning helps people advance within and outside of Agile and Scrum-focused environments. One excellent approach is for people to examine recent industry changes and consider the skills they’ll need to thrive. For example, a developer can become familiar with basic artificial intelligence concepts within weeks to months, creating a foundation that could help them expand their career with that technology. Developing soft skills is also valuable in Agile workplaces. People can focus on areas such as: Problem-solving Critical thinking Conflict resolution Time management Motivating others Finally, they should use self-examination practices to find areas of improvement. If someone struggles with staying calm under pressure, or feeling unworthy of specific roles or responsibilities, finding the root cause of those issues and tackling them can make a person a stronger leader and workplace asset. Do Regular Check-Ins Get inspired by these suggestions as you take ownership of your career. Although some aspects will remain outside your control, you can still do a lot to swing the odds in your favor. After setting goals related to these ideas and your own, consider evaluating your progress once or twice a year. Celebrate your accomplishments, and be honest about what could have gone better and what you’ll do to prevent future setbacks. Those assessments will keep you accountable and nurture an enduring focus for the coming years.

Before We Start, What’s a Chapter? A chapter is a craft community (sometimes also referred to as a Practice or CoE) whose primary purpose is to help practitioners of the same craft or discipline (e.g., development, testing, business analysis, scrum mastery, UX, etc.) elevate their mastery of that particular craft or discipline. Chapters are also typically tasked with setting the standards and guidelines for performing that craft in the organization. Credit: Ashley-Christian Hardy, “Agile Team Organisation: Squads, Chapters, Tribes and Guilds,” 2016 TL/DR In Agile organizations, chapters (Chapters, Practices, CoEs, etc.) pursue the systematic development of capability and craft. This pursuit adds a lot of value to the organization (better quality, better knowledge retention, higher employee engagement, etc.). Chapters often struggle to pinpoint where they need to improve or how they can add more value to their members and the organization. Many organizations don’t offer clear guidelines to chapters (and chapter leads) as to what exactly is expected of them or what good looks like. This article presents a simple diagnostic (click to download the diagnostic) that a chapter could use to identify areas where they must focus their improvement efforts. It defines what ‘good’ looks like in the context of a chapter and provides a tool to help the chapter assess where they stand against that definition (where they’re doing well and where they need to improve). In the second part of this series, I will share several experiments that could be run to optimize each dimension of the chapter's effectiveness. I will also share a case study of how this model was implemented at scale at a large organization. Key Terms First, let’s define some of the key terms that will be used throughout this article: Craft refers to the specific discipline, domain, or skill set around which the chapter is formed. e.g., QA is a craft; UX is a craft; business analysis is a craft, etc. A craftsperson is a practitioner of a craft (developer, QA specialist, marketer, business analyst, etc.) I use the term performing the craft to refer to the actual day-to-day carrying out of tasks by a craftsperson (chapter member) – e.g. a QA specialist performs their craft by carrying out QA tasks. Craft quality (quality of the craft) refers to how well the craft is being performed. I sometimes use craftsmanship, which refers to craft mastery and excellence. Knowledge base refers to a centralized repository or system where craft-related information, best practices, documentation, standards, etc. are stored and shared among chapter members (and others across the organization). Standards (craft standards) refer to the established guidelines and principles that define the expected level of quality within a specific craft. Learning journey refers to the ongoing formal and informal learning efforts (training programs, hands-on application of new knowledge, mentoring, etc.) intended to extend existing skills and build new skills, and how that learning is expected to be acquired over time. Is It Worth Reading This Article? Well, if any of the following statements resonate with you, then I would strongly suggest that you read on: As an organization (or tribe, business unit, etc.): “We have a high risk of losing critical knowledge if a small number of our people leave” “We struggle with onboarding and, despite hiring top talent, it’s difficult for them to hit the ground running” “Despite hiring people with a lot of experience to mentor and grow our junior staff, we feel that knowledge sharing isn’t happening” “We invest a lot in training our people – sending them to courses, etc. – but we don’t feel that investment has had much impact on the overall quality of our products” “We have knowledge siloes even within the same discipline — there are islands of expertise that aren’t connected” “We fear that when the contractors and external consultants leave, our people won’t be able to deliver the same level of high craft quality” “Team members struggle when moving from one team to another due to a lack of consistency in how things are done” “Our team members seem to struggle to tap into the collective expertise of the team, leading to a lot of re-inventing the wheel and time wasted” While these are all difficult problems that result from complex interactions of causes that affect and are affected by every aspect of how the organization works, these issues are all heavily influenced by how effective we are at developing craftsmanship — that is, how good we are at developing craft mastery and excellence. Given that in Agile organizations craft communities (chapters, practices, CoEs, etc.) are the primary custodians of developing craftsmanship, what I’m proposing here is that by systematically assessing and optimizing the effectiveness of how these craft communities work, we can make great strides at addressing these challenges. So, Why Care About Chapters? Effective chapters create the conditions that enable high product quality, high employee satisfaction, and low knowledge loss risk. This is because effective chapters are good at developing master craftspeople. People who feel mastery of their craft are typically happier and more engaged, their output and the speed at which that output is delivered is superior, and, due to the fact that there’s more than a small number of them (and that there’s a robust process to develop more), the departure of a few won’t be catastrophic for the organization. Members of an effective chapter (that is, a chapter that’s good at developing the craftsmanship of its members), would typically say things like: Our chapter follows a systematic approach to building our capability and craft mastery (defining what capability needs to be built, providing its members with the mechanisms to plan how to build those capabilities, and providing the resources and support needed to implement that plan) Our chapter has in place the process and systems that enable us to leverage and build upon the accumulated formal knowledge that the chapter has amassed over time – the standards, playbooks, guidelines, best practices, lessons learned, etc. Our chapter has nurtured a rich social network that enables us to tap into the collective informal (tacit) knowledge and expertise of the chapter – the knowledge, nuances, and highly contextual experiences that aren’t documented anywhere (most knowledge is tacit) Our chapter follows a systematic approach to measuring the impact (outcomes) of craftsmanship-building and capability uplift efforts and leveraging the feedback to guide further craftsmanship-building efforts If we improve the effectiveness of a chapter (that is, optimize the 4 factors mentioned above that are key leading indicators to chapter effectiveness), we would increase the chapter’s ability to develop its members into craftspeople, which will positively affect and improve problems such as high knowledge loss risk, siloes, ineffective knowledge sharing, and low product quality. How Do We Improve Chapter Effectiveness? The first step to improving chapter effectiveness is to systematically assess how the chapter is performing against the 4 key dimensions of chapter effectiveness identified above (access to documented (formal) knowledge; systematic capability building; access to tacit (informal) knowledge; and systematic craft quality measurement and continuous improvement). In this 2-part series, I will introduce a simple diagnostic tool to assess chapter effectiveness (Part 1 – this article), and then delve into how to use the insights from the assessment to identify areas of improvement and how to go about setting chapter effectiveness goals and planning, implementing, and learning from chapter effectiveness improvement actions (Part 2). How Do We Measure Chapter Effectiveness? In this section, we will first go over the dimensions comprising it in some detail, and then present the diagnostic tool itself. Chapter Effectiveness Dimensions Dimension #1 The comprehensiveness, fitness-for-purpose, and ease of access (and use) of our craft standards and knowledge base – this is a broad area that covers things like how good we are at leveraging (and creating/documenting) existing knowledge, the ease of access to relevant knowledge, the accuracy and relevance of the knowledge chapter members can draw from (and its alignment with industry best practices), and the effective distilment of ‘lessons learned,’ which represents how outside knowledge is contextualized to fit the unique context of the organization, among other factors. Dimension #2 The effectiveness of the chapter’s effort to uplift the capability and craftsmanship of its members — effective chapters are good at describing what mastery of their craft means (what skills to acquire, what the levels of mastery of each skill look like, etc.), helping chapter members pinpoint where they are on that journey, and then collaborate as a team to envision what the path to mastery looks like for each member. They’re also good at taking those plans and turning them into reality: not only providing the resources and mentorship, but also the encouragement and peer support, keeping each other accountable, and measuring the outcomes of their elevated levels of craft mastery. Dimension #3 The effectiveness of tacit (informal) knowledge sharing between chapter members – Effective chapters realize that most knowledge is tacit – that is, not documented anywhere. Tacit knowledge is difficult to extract or express, and therefore difficult to formally document or write down. How do we effectively leverage knowledge that isn’t documented? By nurturing a thriving social network that allows chapter members to feel comfortable reaching out to each other for help, seek advice, ask questions, share interesting insights, etc. Such a network doesn’t just happen – it requires conscious, persistent effort to build. The statements comprising this dimension seek to explore some of the leading indicators to building effective knowledge-sharing and advice-seeking social networks. Dimension #4 The effectiveness of the chapter’s efforts to systematically and continuously improve craft quality – how do we know if the actions we’re undertaking to uplift the quality of our craft (committing to learning and capability uplift, fostering stronger knowledge-sharing networks, etc.) are delivering value? How do we know if the investment we’re putting into uplifting our capability into specific tools or frameworks is generating the returns expected? Effective chapters are really good at measuring and evaluating the quality of their craft across the organization (quantitatively and/or qualitatively). They’re good at setting SMART craft improvement goals given their understanding of how well the craft is being implemented and where they need to focus and invest in improvement, planning how to implement those goals, and good at implementing those plans (and learning from that implementation). This is a significant challenge area for many chapters, as it is often difficult to ‘measure’ the quality of how the craft is being implemented. The Chapter Effectiveness Diagnostic Introduction The diagnostic (click here to download the pdf version) comprises a number of statements that are intended to capture what ‘good’ looks like for that particular dimension. Chapter members are expected to rate how well they believe each statement describes the reality of their chapter on a scale ranging from 'completely disagree' to 'completely agree.' All chapter members (including their chapter lead) should take part in completing this diagnostic. One option to fill it (what many chapters do) is to send it out as a survey first, then discuss results or insights in one or more follow-up workshops. The purpose of this diagnostic is to serve as a conversation starter. As with all diagnostic and maturity models, the questions are merely intended to prompt us to have a discussion. The comments, anecdotes, and insights chapter members share as the team moves from one item to another provide a wealth of information. That information is what’s going to guide us (as a chapter) as we attempt to optimize the outcomes our chapter is creating. There’s no particular magic to this (or any) assessment model – it simply provides a structure within which good conversations can take place. What’s in the Pack? This pack contains the statements comprising this diagnostic model. Next to each statement is a brief explanation of why having a conversation about that statement is important and what to look for (and how to dig deeper and uncover insights) if the score against that particular statement is low. In the appendix, you'll find a printable version of the diagnostic (a template with only the statements), which can be distributed as handouts. Next Steps If you want to run the diagnostic as a survey, copy the statements into your survey tool. You may set the response options for each statement as completely disagree — disagree — neutral — agree — completely agree. Alternatively, you might opt for a sliding scale of 1-5, for example, or use whatever rating method you prefer to enable your team to assess how well each statement describes its reality. OK, We Ran the Diagnostic – What’s Next? As mentioned earlier, the conversation that follows this self-assessment is where we really get the value. As a team, the chapter gets together to reflect, explore, and try to make sense of the results of their chapter effectiveness self-assessment. They reflect on where they seem to be doing well and where they’re struggling, where they seem to all have the same experience, and where the scores reflect a difference in their perceptions. They reflect on common themes, outliers, relationships, and connections between statements, explore why some statements are not correlated even though they were expected to (and vice versa), and any other interesting insights that came out of the assessment. In the second part of this series, we will do a deep dive into how to translate these insights and learning into experiments and actions and measure the impact they create in optimizing chapter effectiveness. We will explore how to prioritize chapter effectiveness interventions, what experiments to run to uplift each chapter effectiveness dimension, and how to establish a robust continuous improvement cycle to consistently and systematically seek higher chapter effectiveness. We will go through a case study from a large financial organization where this model was applied at scale across a large number of chapters, and share some of the learnings from that experience.

By Ayman Idris CORE

Marty Cagan describes the job of the Product Manager as “to discover a product that is valuable, usable, and feasible." Finding the balance between the business, users, and technology demands a diverse skill set. There are many things that are going on simultaneously that require attention. In this regard, Jira is great. Sure, it has some downsides, but the tool can help Product Managers to: Keep the product strategy aligned. Clearly prioritize tasks while keeping them structured and organized. Analyze the performance of your team. Use a Roadmap To Keep Your Strategy Aligned As powerful as Jira is in the right hands, it is not a solution for everything. For instance, it is probably not the best tool for developing a product roadmap. However, it is quite good for managing one. What this means is that Jira has great functionality for managing roadmaps in a quick, actionable, and transparent way. Nevertheless, it requires proper input: You need to break down your scope into Epics and tasks before you start building a roadmap in Jira. We typically use a framework called BRIDGeS for multi-context analysis of a project. This framework leaves us with prioritized, ready-to-use Epics and tasks at the end of the session. Given this article is not about roadmaps per se, I would rather not go into too much detail. I will be focusing on Jira instead. Setting Up a Timeline in Jira Once you have your work broken down into Epics and tasks, creating a roadmap – or, as Jira calls it, a Timeline – is quite simple. Navigate to your board. Select the “Timeline” option from the menu on the right. Click on the “+ Create Epic” to add an Epic. Add child issues by clicking on the “+” sign next to the Epic. Click on the timeline to set the timeframe for the Epic. Tips and Tricks for Using Jira’s Timeline Feature Unlike most Jira features, the Timeline is rather intuitive and friendly to new users. Still, there are certain easily missable tips and tricks that can make your job much simpler. It’s just that you need to know where to look Add Dependencies You can add Dependencies between Epics from the Timeline. Simply hover over the timeline for an Epic and you will see two dots – one at the top right corner and one in the bottom left corner. Click and drag them to link one Epic to another. This is useful for understanding the order of work or visualizing potential blockers. Note: The color of the connective thread will change to red if the dates of Epics overlap. This feature is quite handy for easily seeing if certain dependencies are becoming blockers. Still, I’d recommend using dependencies wisely, otherwise the roadmap will become confusing because of the intertwined Epics. Use Different Colors for Epics You can right-click on the timeframe to easily change the color of an Epic or to remove start and end dates. Color-coding your Epics is a useful element of visualization. View Settings You can adjust the settings of the timeline if you wish to filter out certain completed issues or expand/collapse all of the Epics at the same time. Another useful option you can find in the view settings is the progress bar. Enable it to see a bar indicating the progress of an Epic. Filter out Epics With a Certain Status You can use the status category filter to hide the Epics and tasks that are marked as done from the timeline. This simple filter greatly improves the visibility of the roadmaps for times when you need to review done/in progress/future scope. Prioritize and Manage Tasks in the Backlog Now that we have an actionable plan, let’s take a look at how Jira can be used to execute it. Setting Up a Backlog in a Kanban Project In my experience, most Agile teams prefer to use a Scrum board that has the backlog feature enabled by default. That being said, a Kanban board needs a little bit of tweaking if you want to have a separate backlog rather than storing all of your issues on the board. The task of adding a backlog is slightly simpler for Team-Managed projects. Simply select the Add View option from the left side panel and enable the backlog. The process of adding the backlog in a Company-Managed project is a bit trickier. Go to the three dots menu at the top right corner of your board. Select Board settings. Select the Columns option. Drag the backlog status card from the board and into the Kanban backlog column. Delete the original Backlog column by clicking on the trash bin icon. Going back to the board, you’ll see that it has only three columns left, and the backlog has been moved to the side panel. Hint: This approach has an added benefit. Creating issues from the Backlog screen is much simpler and faster than from the board. Just click on the + Create Issue button and type in the name of your task. You can keep on typing and hitting enter to add new issues. And you can change their type as well. Setting Up a Backlog (Or Several) in a Scrum Project As I mentioned earlier, the Scrum project comes with the backlog feature enabled by default. That said, there is a major difference between the backlogs in Scrum and Kanban Jira projects: a Scrum Project has two backlogs by default. One is the Project Backlog and the other is the Sprint Backlog. The Sprint Backlog consists of a set of user stories or tasks that the development team commits to completing within a specific sprint or time-boxed iteration. It is a subset of the product backlog and represents the work sprint planning for that particular sprint. The Product Backlog contains a prioritized list of all the desired features, enhancements, and bug fixes for the product. It represents the complete scope of work that needs to be done over multiple sprints. Hint: The backlog view in Jira allows you to create several Sprints. These Sprints can be used as separate backlogs for certain specific tasks. For example, you can use these Sprints as separate backlogs for Bugs, Support Requests, the Icebox, etc. This functionality is super handy for keeping your work well-organized. Plus, this approach allows you to keep your work well-organized. The tasks from these backlogs can be pulled into the Sprint Backlog during the Sprint Planning Session. Story Points As a feature, Story Points are used to estimate the complexity of a user story. Typically, we use the following approach when it comes to assigning points to user stories: Point Description 1 One-liner change. You know what should be changed. Very easy to test. 2 You are aware of what to do. Changes are bigger than one-liner~1-2 days to implement. May include regression testing 3 Bigger scope. May require some research/documentation reading/codebase research. Includes unknown parts. 5 Biggest story. Not enough to split. 8 Must be split. Do research first. Bonus Tip: Backlog Refinement Backlog refinement is the process of reviewing, prioritizing, and tidying up the backlog. It is a necessary activity as, over time, people will add a lot of tasks that are missing context. For now, let’s focus on the benefits of tidying up your tasks: The team is working on the tasks that are adding real value to the product. The tasks are optimized and broken down in a way that a single issue doesn’t take longer than an entire Sprint. The work that is in progress reflects the roadmap. How do we do it? We typically refine the backlog once every two weeks. We take the stories from the product backlog and place them into relevant Sprint containers like Bugs, Technical Debt, or upcoming Sprint. We review the estimation and priority of the tasks that are being moved from the Product Backlog. Analyze the Performance of Your Team With the Built-In Reports Jira has a variety of reporting tools that are available to Product Managers. They are easily accessible from the reports tab on the right-side menu. Note: The Reports tab may not be enabled for you by default. Therefore, please follow these steps in case you do not see it: Select the Add View option. Select the More Features option. Find the Reports option and toggle it on. These reports can be used to analyze the performance of your team. They are also easily shareable and exportable. There is a wide selection of reports, but using all of them isn’t necessary. Here is a brief overview of several reports that we find to be the most useful: Burndown chart: Tracks the remaining story points in Jira and predicts the likelihood of completing the Sprint goal. Burnup chart: Tracks project progress over time and compares the work that is planned to the work that has been completed to date. Sprint report: Analyzes the work done during a Sprint. It is used to point out either overcommitment or scope creep in a Jira project. Velocity chart: This is a kind of bird’s eye view report that shows historical data of work completed from Sprint to Sprint. This chart is a nice tool for predicting how much work your team can reliably deliver based on previously burned Jira story points. Conclusion There are many new, slick work management tools on the market. Most are probably better than Jira in terms of UI and UX. That being said, as one of the oldest solutions out there, Jira has had the time and resources to develop a wide selection of features. This is why many PMs feel lost and confused when they are experiencing Jira for the first time. Don’t worry though – we’ve all been there. That’s why this little guide exists, showing you the different options of tools that will work best for you. Consider this to be your starting point in the endless sea of Jira features.

In these intensely competitive times, every application needs to be aesthetically appealing in addition to providing seamless functionality to satisfy the users. If an app does not function properly because of a visual interface error or if the site is unreadable, users may uninstall or leave the app. This can ultimately lead to a loss of customers and a drop in revenues. To avoid this and ensure the best possible user experience, companies are prioritizing visual regression testing. Let us study a couple of examples of visual regression testing to understand its importance: When you click on a drop-down image the menu does not slide down after adding more options. You have reworked the complete layout of the page, and the submit button on the page is broken. These UI errors need to be fixed since changes in the elements can lead to the breakdown of the visual aesthetics. These illustrations clearly highlight the importance of conducting thorough visual regression testing before software releases. Visual regression testing checks the UI of an application after code changes and ensures that these different visual elements, like buttons, images, and text, all render correctly. Through this blog, we will examine visual regression, the different techniques used, the challenges testers face when performing the tests, and the best practices to overcome them. Common Visual Regression Techniques Visual testing ensures that visual glitches are identified early and do not spill over to the production stage. Let us now briefly examine the commonly used methods for regression testing: Manual visual testing: In this method, testers manually compare UI screenshots before and after making changes in the code. Comparing layouts: It requires comparing the UI layout before and after changes are made and accounts for changes in the UI’s font, color, and other visual elements. Comparing pixel-by-pixel: Used to test small, complex UI elements, this method involves comparing the UI’s pixels before and after changes. Structural comparison: It compares the UI’s Document Object Model (DOM) before and after making changes. Inserting visual checkpoints: In this technique, checkpoints are inserted into the UI to check the UI’s visual state at specific points in time. Manual Regression Testing Manual regression testing is recommended in the early testing stages when the UI is unstable. It is suitable for ad hoc testing and conducting quick on-the-spot checks. In this method, the testers manually check the layout and appearance of the visual elements. It involves taking the latest screenshots and comparing them with baseline screenshots to unearth any gaps. Benefits of Automated Visual Regression Testing Over Manual Methods The manual technique can be time-consuming and lead to a waste of resources because of its repetitive nature. The scale of manual testing grows with every new feature addition, thereby increasing the time spent by a human tester pouring over screenshots to identify bugs. It is impractical to manually conduct visual regression testing when there are tight deadlines to meet. In contrast, automated visual regression testing helps you automate repetitive tasks like checking the page following every code change. Even with the heavy initial investment, automated testing, especially with AI-powered features, helps you save time and money in the long run. Though automated visual regression testing reaps many benefits for testers and developers, it has to be properly implemented if they are to receive its benefits. Let us examine the best practices that go into a proper visual regression testing process. What To Remember While Conducting Visual Regression Testing Following these best practices will help optimize your automated visual regression testing process and help you gain its maximum benefits: Develop Appropriate Test Scenarios Clearly define what to record in the snapshots and the time to take them while testing. Remember to include user interactions in such scenarios since the applications will need to deal with them in the real world. Validate the Entire UI Page Instead of only validating individual components, ensure to validate the entire UI page. This practice will increase the test coverage and improve it. Pick the Right Automated Tool The visual regression testing tool you choose should be capable of ignoring false positives. It should be able to take care of pixel offsets, anti-aliasing, and other issues while ensuring the tests don’t fail. The automated algorithm must be able to analyze the page’s structure and perform layout comparisons. It should also be able to take care of content that is dynamic and moving. Compare Screenshots Testers should compare screenshots with recent ones to identify the disparities. This will help ensure that the UI remains the same, improving the user experience and product quality. Identify and Resolve Bugs Ensure to resolve bugs that the testing tool identifies or send them to the respective developers for fixing them. Remember to update screenshots to be used as a baseline for future regression tests after it is done. Choose the Right Situation To Perform Automated Testing Automated visual regression testing may not be appropriate for all scenarios. In some situations, using a combination of manual and automated methods is advisable. For example, when new features are added, they can be validated using an automation technique and then checked manually. Conduct a Detailed Review A team of reviewers or a single reviewer can examine how adjustments are made without causing interruptions in the desired outcome and make a report accordingly. Learn From Your Mistakes Learning from your successes and failures is crucial in visual regression testing. You need to identify the root causes and impacts of the visual changes detected by your tool. Testers must also identify false negatives and positives and adjust the tool settings and test cases accordingly. Conclusion In conclusion, successful implementation of visual regression testing in Agile teams requires a holistic approach that encompasses automation, collaboration, scalability, and comprehensive analysis. Visual regression testing can be a game-changer if you choose an appropriate automated testing tool with the right features and advantages. By adhering to these best practices, Agile teams can effectively leverage visual regression testing to deliver high-quality user interfaces in an iterative and efficient manner.

Behave is a Python-based behavior-driven development (BDD) framework for writing human-readable tests that describe the expected behavior of software systems. On the other hand, Terraform is an infrastructure as code (IaC) tool that streamlines the management of infrastructure by enabling developers to define resources and configurations in a declarative manner. By combining Behave's BDD approach with Terraform, you can ensure that infrastructure behaves as expected under various conditions. This integration facilitates early detection of issues and the reliability of infrastructure code. Using Behave for Terraform Testing Testing Terraform configurations with Behave involves a series of structured steps: Install Behave Begin by installing Behave and its dependencies using pip, Python's package manager. This step ensures that Behave is ready for use in the testing environment. Shell pip install behave Set up Directory Structure Organize the test files and Terraform configurations in a directory structure that Behave expects. This structure typically includes separate directories for features, steps, and Terraform files, ensuring clarity and organization. For example: Shell . ├── features │ └── terraform.feature ├── steps │ └── step_implementation.py ├── terraform └── main.tf Write Feature Files Utilize Gherkin syntax to write feature files that describe the desired behavior of Terraform configurations. These feature files outline scenarios and steps that test various aspects of the infrastructure code. Here's an example terraform.feature file: Gherkin Feature: Verify EC2 actions Scenario Outline: Check if the EC2 actions are allowed Given I invoke <service>:<action> When the region selected is <region> Then the status should be <result> Implement Step Definitions Develop step definitions in Python to define the behavior of each step outlined in the feature files. These step definitions interact with Terraform commands, allowing for the execution of infrastructure operations and verification of results. Here's an example step_implementation.py file: Python import os from behave import * @given('I invoke {service}:{action}') def step_impl(context, service, action): context.action_name = ''.join([service, ':', action]) @when('the region selected is {region}') def step_impl(context, region): os.environ['AWS_DEFAULT_REGION'] = region @then('the status should be {result}') def step_impl(context, result): action_name = [] action_name.append(context.action_name) #Add assertions or checks for the action and results Run Tests Navigate to the root directory of the tests and execute Behave to run the defined scenarios against the Terraform configurations. During this step, Behave initializes and starts processing your test files. It reads the feature files written in Gherkin syntax to understand the scenarios you've defined. Behave executes each scenario defined in your feature files. It matches each step in the scenario to the corresponding step definition in your Python code and executes them sequentially. Shell behave Review Test Results Upon test execution, For each scenario defined in the feature files, Behave reports whether the scenario passed or failed. It also provides details about any steps within the scenario that failed, including the step definition and the error message. Review these results to ensure that the Terraform configurations behave as expected and meet the desired criteria. Conclusion By following the structured approach outlined above, you can leverage Behave for functional testing of Terraform configurations. This process facilitates the identification of potential issues or deviations from expected behavior, ultimately enhancing the correctness and reliability of infrastructure code. With Behave and Terraform working together, developers can adopt a systematic approach to testing and ensure the robustness of their infrastructure deployments.

Simply adopting the Agile process does not mean your organization becomes Agile. Many companies switched from the Waterfall methodology to the Agile methodology for project management and failed miserably. The major reasons were a lack of training of the team and management on Agile frameworks and a lack of technology, such as project management software, to implement Agile methodology. You need both the right knowledge and the right technology to truly implement Agile. In this post, we will look at both: the meaning of the Agile process and how to optimize the Agile process with project management software. Need an Agile Software Solution? Try Jira. What Is an Agile Process? An Agile process is an approach to project management that focuses on breaking the project into smaller phases. It involves working in small iterations. After every iteration, the work is released and reviewed. Based on the feedback, improvements are made in the next iteration. Originally, Agile was formed as a project management methodology to manage software development projects, but now, it is also used in other business operations including marketing, HR, and R&D. Every iteration in Agile follows the cycle of planning, executing, and evaluating. The purpose of doing so is to ensure continuous improvement and provide the ability to quickly adapt to changing requirements. The ability to respond to change is at the core of the Agile process. It is achieved by working in small repetitive cycles, continuous release of work after every cycle, receiving feedback on the work from interested stakeholders, and continuous improvement. Collaboration is at the heart of any Agile process that makes it possible to respond to changing needs and create work that is in the interest of all the stakeholders of a project. The Agile Manifesto is a founding document of Agile that entails four key values and 12 principles of Agile. Four Key Values of Agile Include Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change by following a plan Similarly, there are 12 principles of Agile methodology. Based on these values and principles, there are various frameworks to implement Agile. The top two frameworks for Agile process implementation are Scrum and Kanban. Each framework lays out the principles, rules, and practices to make an organization’s process truly Agile. I hope this has given you a brief idea about what an Agile process is. Now, let’s talk about how project management software helps you optimize Agile processes. 5 Ways To Optimize the Agile Process With Project Management Software Project management software plays a key role in implementing and optimizing the Agile process. It provides you with a wide array of tools to plan, execute, manage, visualize, track, and collaborate on an Agile process. Here are the five ways you can optimize an Agile process with project management software: 1. Plan Sprints and Set Goals The best way to optimize any process is to set measurable goals and track the progress. Agile involves working in a fixed-length iteration called sprint. Project management software helps you plan sprints and set goals and objectives for the sprint. This ensures every sprint is accounted for and measured for the progress. You get the tools to create a product backlog, prioritize the features, assign the story points to each story, and commit to the stories you can complete in a sprint. This all is part of effectively implementing Agile. 2. Store All the Information in a Centralized Place Project management software helps you optimize the Agile process by storing all the information related to the project in one centralized place. When everything is recorded and documented, you can easily track the progress and ensure accountability. This recorded information lays the foundation for evaluation and improvement. You can easily see who is working on what, sprint goals, and current work status to plan and optimize coming sprints. Not only that, teams find it easy to work together having all the project-related information in one place. 3. Facilitate Information Sharing, Collaboration, and Communication The Agile Manifesto says, “Business people and developers must work together daily throughout the project.” Collaboration is at the heart of the Agile process. A project management tool provides you with built-in collaboration features like real-time chat, discussions, and file sharing to facilitate seamless communication and collaboration within the team and with stakeholders. The free flow of information ensures the team collaborates effectively on all aspects of the development process. Not just that, tools for Agile process management like the Kanban board ensure transparency and enhanced visualization of the flow of the work both for developers and business people. Each team member can better understand their tasks, deadlines, and how it affects the sprint outcomes. A Scrum master can better manage tasks, track progress, and identify bottlenecks to ensure the team is effectively implementing Agile and meeting sprint goals. Business people can visualize the progress transparently which helps them build trust with the team. This results in the overall optimization of the Agile process with the involvement of all the key stakeholders. 4. Hold Sprint Retrospectives To Optimize Performance One of the 12 principles of the Agile manifesto is, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” Project management software provides you with a platform to conduct regular sprint retrospectives at the end of each sprint. The purpose is to reflect on what went well, what didn't, and what can be improved in the next sprint. You get the tools to create charts and reports to get insights into project status and team performance. For example, a burndown chart can help you plot the amount of work remaining against the amount of time to monitor development. This helps in estimating when all of the work will be finished. Similarly, there are velocity charts, burnup charts, and control charts to track progress, analyze data, and solve problems effectively to optimize your project process. 5. Improve Overall Operational Efficiency A developer uses 8 to 10 different tools for a software development cycle. It includes tools for writing codes, testing, continuous integration & continuous deployment (CI/CD), end-user feedback, code repository, and bug tracking. Project management software helps you improve operational efficiency by bringing various tools used in development to one place. It helps you streamline workflows resulting in enhanced process efficiency. Apart from that, many project management software provide you with workflow automation that can help you optimize process efficiency in Agile workflows by saving you time, reducing errors, and increasing consistency. Why Should You Optimize Your Agile Process? Agile teams do not become efficient automatically. It is a process of continuous improvement. Practically when an Agile team works together, it takes one or two sprints to understand each other’s working style and project requirements to reach the optimal efficiency, which is measured using Sprint velocity. Thus, you need to optimize your Agile workflow to improve efficiency and reap the benefits of Agile. That’s why many people refer to Agile as a mindset that embraces change rather than opposing the change. Here Are the Benefits of Optimizing Your Agile Process 1. Faster Speed to Market As per the state of the Agile report, 52% of teams use Agile methodology to accelerate time to market. Optimizing your Agile process means a better understanding of project requirements and reduced wasted efforts. This helps you improve efficiency, resulting in faster speed to market the product. 2. Reduce the Risk of Failure As per the state of the Agile report, 31% of teams adopt Agile methodologies to reduce the risk of failure of the project. Agile encourages frequent testing, continuous-release, and continuous feedback to ensure issues are identified early in the development cycle. This helps you reduce the project risks. 3. Delivery Predictability 44% of the teams say they use Agile for delivery predictability. Agile optimization means effective implementation of Agile. This helps you improve delivery predictability by breaking large work into smaller pieces. The ability to move quickly yet be predictable is a key benefit of Agile. Conclusion According to Gartner, 91% of businesses are engaged in some form of digital initiative for business transformation. If you are not using the right project management software to optimize the Agile process, it will become challenging for you to implement Agile methodology and become truly Agile. Project management software provides you with the tools to implement the Agile process. Along with the right Agile practices in place, you can easily optimize the Agile process with project management software.

Product Ownership Is a Crucial Element in Improving Outcomes SAFe and Scrum both consider product ownership crucial to maximizing outcomes in environments of complexity and uncertainty. Teams are ideally organized around products/value streams so they can apply customer-centricity. Product people and their teams are ideally accountable for outcomes and are empowered to figure out, inspect, and adapt requirements/scope as needed. SAFe Has Multiple Product Ownership/Management Layers As organizations tackle bigger products, they have some alternatives for how to tackle product ownership/management. Scrum advises having one product owner for each product, even if multiple teams develop the product. This is at the core of scaling frameworks such as Nexus and LeSS. SAFe takes a path that is more aligned with the classic structure of product management organizations, which is to have multiple layers of product ownership/management. Product owners own the product at the Agile Team level. Product managers own product at the teams of Agile teams level (Agile Release Trains). Solution managers own products for huge teams of teams working on even larger products/solutions. Why Did SAFe Make This Choice? SAFe takes the perspective of learning from experience in the trenches and what patterns organizations are using and applying lean/Agile principles as needed to help organizations evolve. And many organizations have been struggling to scale product ownership when we're talking about multiple teams. Product management experts such as Melissa Perri also talk about multiple product management roles (see some thoughts about how this relates to SAFe below). Interestingly enough, Scrum@Scale also has product owners at every level. And LeSS/Nexus also introduce multiple product owners when you scale beyond a handful of teams. The advantage of this approach is that it aligns with the product manager/owner journey. Working closely with one or two teams, owning product choices for a couple of product features or a certain slice of the product, can be a great jumping point for junior product managers/owners (What Melissa Perri refers to as associate product managers in Escaping the Build Trap). As the product manager/owner gains experience, they can take on a whole product themselves. It takes time for a product owner/manager to gain the experience to act as the visionary entrepreneur for their product. They might start feeling more comfortable writing stories and executing experiments and, over time, learn to influence, design product experiments, and make tougher prioritization decisions with multiple demanding stakeholders. In other words, product managers/owners naturally evolve from focusing on tactics to strategy over time. What Are Some Downsides To Splitting Product Responsibilities Between the Product Owner and Product Manager? An anti-pattern we often see is that the PM/PO split allows an organization to staff the PO role with “story writers” and “project managers” — people who aren’t empowered as product owners, and that reinforce the project mindset of requirement order-taking and managing scope-budget-timeline. This lack of empowerment leads to delays and an environment where the team is focused on outputs rather than outcomes. Empowering product owners and their teams is a common challenge in SAFe AND Scrum. What I’ve seen work well is carving out an appropriate product scope within which the product owner and team are empowered to figure out what to build to achieve the desired outcomes and optimize the value of that product or that aspect of a bigger product. Doing this requires figuring out the product architecture and moving towards an empowering leadership style. As in many other areas, SAFe takes the evolutionary approach. If you’re a purist or a revolutionary, you’ll probably struggle with it. Real-world practitioners are more likely to relate to the evolutionary approach. It’s important to ensure that the PO/PM separation is not seen as an excuse to continue doing everything the same. Product Managers and Product Owners: A Collaborative Relationship Leaders implementing the PO/PM split should ensure healthy collaboration, involvement, and partnership across the product ownership/management team. Product managers should internalize the SAFe principles of unleashing the intrinsic motivation of knowledge workers, in this case, product owners. Product managers have a role as lean/Agile leaders to nurture the competence, awareness, and alignment in the product team that would enable them to decentralize control and let product owners OWN a certain slice of the product. Product managers and product owners should discuss what decisions make sense to centralize and which should be decentralized. The goal of product managers should be to grow product owners over time so they can make more and more decisions — and minimize the decisions that need to be made centrally. This is key to scaling without slowing down decision-making while maintaining and ideally improving outcomes aligned with strategic goals. Increased Risk of Misunderstandings Around Product Ownership With Product Roles Filled by Non-Product People One very specific risk of the SAFe choice to split the PM and PO roles is that it creates the need for many more people in a product role than the number of people in the product organization. This vacuum pulls people like business analysts, project managers, and development managers into the product owner role. Some people can become great product owners but come with very little product (management) experience. Business analysts, for example, are used to consider what the customers say as requirements. They are used to the “waiter” mindset. They struggle to say no or to think strategically about what should be in the future or what should be in the product. Development managers are used to being subject matter experts, guiding their people at the solution level, and managing the work. Project managers are used to focusing on managing scope/budget/timeline rather than value and outcomes. Use the Professional Scrum Product Ownership Stances to Improve your SAFe Product Ownership One technique I found very useful is to review the Professional Scrum Product Ownership Stances with SAFe product owners and product managers. We try to identify which misunderstood stances we’re exhibiting and what structures are reinforcing these misunderstood stances/behaviors. For example — what’s causing us to be “story writers”? We explore the preferred product owner stances and discuss what’s holding us back from being in these stances. Why is it so hard to be an “experimenter,” for example? An emerging realization from these conversations is that SAFe structurally creates a setup where team-level product owners play “story writers” and “subject matter experts” more often. It’s non-trivial to switch to an environment where they are a “customer representative” and a “collaborator” with the space to “experiment” with their team towards the right outcome rather than take requirements as a given. It’s hard to get SAFe product managers to be the “visionary,” “experimenter”, and “influencer”. The issue here isn’t unique to SAFe. Product owners struggle to exhibit these behaviors in most Scrum environments as well. What I find useful is to align on a “North Star” vision of what we WANT product ownership to look like at scale and take small steps in that direction continuously, rather than settle for “project management” or “business analysis” called a new name. SAFe Product Management: Providing Vision and Cohesion in a Pharma IT Environment Let’s close with an example of how this can play out in practice. I'm working with the IT organization of a pharmaceutical company. As they were thinking about how to help their Enterprise Applications group become more agile, one of the key questions was how do we create product teams that are empowered to directly support the business — by minimizing dependencies and creating real ownership of each of the enterprise applications as a platform that other IT functions can more easily build off of and leverage. Several Enterprise Applications have multiple teams working on different aspects of them. We created stream-aligned teams, each owning and managing that aspect as a product. The product owners and their teams are empowered to consider needs and wants coming in from other IT functions and the business and shape the future of their product. Most of these product ownership decisions happen at the team level. Product managers focus on alignment and cohesion across the platform. We are still working on establishing the right mechanisms to balance vision/alignment with local initiatives at the team level. So, Now What? SAFe’s approach to product ownership is a frequent target of criticism in the hard-core Agile community. Some of it is pure business/commercial posturing (aka FUD), and some of it is fair and constructive. My aim in this article was to help practitioners explore the rationale, the potential, and the risks behind SAFe’s approach to product ownership, as well as some patterns and models, such as the Professional Scrum Product Ownership stances, that can be used to inspect and adapt/grow the effectiveness of your product ownership approach. As an individual product owner or product manager, you can use these models/patterns to drive your learning journey and help you structure your organization's conversation around creating the environment that empowers you to be a real product owner or product manager. As leaders of product organizations in a SAFe environment, I hope this can help you establish a vision of how you want your product organization to look like and guide you on the way there.

Joining the Agile framework provides access to resources and support that can help your organization maximize the benefits of Agile. It also provides a platform to connect with other Agile practitioners to share best practices and learn from each other. Practicing Agile working methods allows teams to pursue their goals at their own pace and with as much creativity as they want, and they're also a great way to bond as a team. Agile teams are also better able to respond to changes in the market quickly and efficiently, which is essential for success. Agile teams also tend to be more motivated, as they feel they are in control of their destiny. So, if you are wondering how to encourage your team to embrace Agile values and principles, Agile games are one of the best options to get started with. What Are Agile Games? A major benefit of Agile games is that they support team building through new learning activities and iteration. As a result, Agile games support the communication and self-organization capabilities of DevOps teams. As a result, your team members will be better able to learn Agile software more rapidly. This will lead to better collaboration between teams, more efficient development, and faster time to market. Agile games also help teams to identify potential risks and issues early in the development process. This allows them to quickly adjust and course-correct as needed. Agile games also help teams build trust, foster collaboration and encourage creativity. This in turn leads to better problem-solving, increased team morale, and a greater sense of ownership. What Agile Games Are Best for Team Building? Here you can find some of the best Agile games that help boost team effort and support. Murder Mystery Play murder mystery games to boost team communication and thinking skills. Participants need to work together to solve the case and uncover the murderer. The game encourages collaboration and creativity as players need to think outside the box and come up with unique solutions. It also tests participants' problem-solving skills and their ability to think critically. The Paper Airplane Another great Agile game is the paper airplane game, and it can be played by any team. As a basic premise, each member of your team must construct a paper airplane. The catch is that each member is only permitted to fold the plane one time before handing it over to the next member. In addition to increasing team bonding, this is an effective way to teach team members how their contributions contribute to the project as a whole. Ball Point This ball-based game follows the same principles as most Agile games, in which team members communicate and formulate strategies. The game consists of teams passing a ball around, and each time a member touches the ball, a point is scored, but points are accumulative when the last member touches the ball and is also the first one to touch it. Marshmallow Tower A marshmallow serves as the crown of a tower in this game. As simple as it may sound, the "building materials" given to teams are often fairly flimsy; spaghetti, for instance, or even string have been used as "building materials" in Agile games. This is another great Agile game for teaching teams agility since it rewards the team with the most structurally sound marshmallow tower, although speed and specifications are also important factors. Chocolate Bar A great way to get a better understanding of iterations and customer feedback for teams is through this game. It can be played in person, or with a Miro board. Your goal is simple (and delicious): you are building a chocolate bar based on customer input. One person will be designated to perform the role of the product manager or product owner, and everyone else will serve as a customer. The Emoji Game This emoji game is an excellent way to facilitate communication when it comes to Agile games. Team members must interpret what the messenger means by using emojis. The catch is that the messenger can only communicate using emojis. A favorite film or album, for example, or a message describing the messenger's characteristics might be appropriate. Conclusion These are the best Agile games for team building as they provide moral support and better communication and delivery skills. Team mates can collaborate more in a better way to solve the game and that also helps them boost These games also help increase the morale of the team and build trust between the team members. They can also help in creating better problem-solving skills and critical thinking. Lastly, these Agile games can help in breaking the monotony of the workplace and having fun while working together.

In the Oxford Dictionary, the word agility is defined as "the ability to move quickly and easily." It is, therefore, understandable that many people relate agility to speed. Which I think is unfortunate. I much prefer the description from Sheppard and Young, two academics in the field of sports science, who proposed a new definition of agility within the sports science community as "a rapid whole-body movement with a change of velocity or direction in response to a stimulus" [1]. The term “agility” is often used to describe “a change of direction of speed.” However, there is a distinct difference between “agility” and “a change of direction of speed.” Agility involves the ability to react in unpredictable environments. Change of direction of speed, on the other hand, focuses purely on maintaining speed as the direction of travel is changed. Maintaining a speed while changing direction is usually only possible when each change of direction of travel is known in advance. Using a sports analogy as an example, in soccer, we can say that a defender’s reaction to an attacker’s sudden movement is an agility-based movement. The defender has to react based on what the attacker is doing. Compare this to an athlete running in a zig-zag through a course of pre-positioned cones, and the reactive component is missing. There are no impulsive or unpredictable events happening. The athlete is trying to maintain speed while changing direction. Often, when leaders of organizations want to adopt Agile, they do so for reasons such as “to deliver faster.” In this case, they are thinking of agile as a way to enable a change of direction of speed like the athlete, and not in the sense of agility needed by the soccer defender when faced with the attacker. This may explain why agile ways of working do not always live up to expectations, even though more and more companies are adopting it. Sticking with the sports analogy, the athlete running through the cones tries to reach each one as quickly as possible and then runs in the direction of the next until the end of the course. This works as a metaphor for defining the scope of a project and has teams work in short iterations in which they deliver each planned feature as quickly as possible and then move on to the next. This may be fine in a predictable environment, where the plan does not need to change, where requirements stay fixed, where the market stays the same, and where customer behaviors are well understood and set in stone. In many environments, however, change is a constant: customer expectations and behavior, market trends, the actions of competitors, and more. These are the VUCA environments (volatile, uncertain, complex, and ambiguous) where there is a need to react or, to put it another way, where agility is needed. Frameworks such as Scrum are meant to support agility. Sprints are short planning horizons, and the artifacts and events in Scrum are there to provide greater transparency and opportunities to inspect and adapt based on early feedback, changes in conditions, and new information. It gives an opportunity to pivot and react in a timely manner. However, Scrum is unfortunately often misunderstood as a mechanism to deliver with speed. Focusing only on speed and delivery and not investing in the practices that enable true agility is likely to actually slow things down in the long run. When the focus is only on speed, it becomes harder to maintain that speed, let alone to increase it, and any semblance of agility is a fantasy. Let me talk about a pattern that I see again and again as an example. Company A has a goal to build an e-commerce site through which they can sell their goods. Their first slice of functionality is delivered in a 1-month Sprint and consists of a static catalog page in which the company can upload its products with a short description. The first delivery is received by happy and excited stakeholders who are hungry for more. The team keeps on building, and the product keeps growing. Stakeholders make more requests, and the team works harder to keep up and deliver at the pace that stakeholders have come to expect from them. The team does not have time to invest in improving their practices. Manual regression testing becomes a bigger and bigger burden and is more challenging to complete within a Sprint. The codebase becomes more complex and brittle. The more bloated the product becomes, the more the team struggles to deliver at the same pace. To try to meet expectations, the team begins to cut corners. They end up carrying testing work over from one Sprint to the next. And there is no time for validating if what is being delivered actually produces value. This is just as well, as no analytics have been set up anyway. In the meantime, whilst the team is so busy trying to build new features and carrying out manual integration and regression testing, they do not have time either to look at improvements to their original build pipeline or to build in any automation. A release to production involves several hours of downtime, so this has to be done overnight and manually. To make matters worse, the market has been changing. The sales team has made deals with new suppliers, but this means further customizations to the site are needed for their products. Finally, the company has pushed for the platform to be available in different timezones, so the downtime for a release is a big problem and must be minimized, so they are only allowed to happen once every six months. Progress comes to a standstill. The product is riddled with technical debt. The team has lost the ability to get early feedback and the ability to react to what their attackers are doing, i.e., customers' changing needs, competitors’ actions, changing market conditions, etc. Just implementing the mechanics of a framework like Scrum does not ensure agility and does not automatically lead to a more beneficial way of working. The Agile Manifesto includes principles such as “continuous delivery of valuable software,” “continuous attention to technical excellence,” and “at regular intervals, the team reflects on how to become more effective.” Following these principles is a greater enabler of agility than following the Scrum framework alone. One effective way of enabling greater agility is to complement something like Scrum with agile engineering practices to get those expected benefits that organizations are looking for with agile. Over the years, I have encountered many Agile adoptions at companies where a lot of passion, energy, focus, and budget went into training and coaching people in implementing certain frameworks such as Scrum. However, what I do not encounter so much are companies spending the same amount of passion, energy, focus, and budget into implementing good Agile engineering practices such as Pair Programming, Test Driven Development, Continuous Integration, and Continuous Delivery. When challenged on this, responses are typically something like “We don’t have time for that now," or “Let’s just deliver this next release, and we’ll look at doing it at a later date when we have time." And, of course, that time usually never arrives. Now, of course, something like Scrum can be used without using any Agile engineering practices. After all, Scrum is just a framework. However, without good engineering practices and without striving for technical excellence, a Scrum team developing software will only get so far. Agile engineering practices are essential to achieve agility as they allow the shortening of validation cycles and get early feedback. For example, validation and feedback in real-time on quality when pairing, or that comes with proper Continuous Integration being in place. Many of the Agile engineering practices are viewed as daunting and expensive to implement, and doing so will get in the way of delivery. However, I would argue that investing in engineering practices that help to build quality or allow tasks to be automated, for example, enables sustainable development in the long run. While investing in Agile engineering practices may seem to slow things down in the short term, the aim is to be able to maintain or actually increase speed into the future while still retaining the ability to pivot. To me, it is an obvious choice to invest in implementing Agile engineering practices, but surprisingly, many companies do not. Instead, they choose to sacrifice long-term sustainability and quality for short-term speed. Creating a shared understanding of the challenges that teams face and the trade-offs for short-term speed without good engineering practices in place versus the problems that can arise without them can help to start a conversation. It is important everyone, including developers and a team’s stakeholders, understands the importance of investing in good Agile engineering practices and the impact on agility if you don’t do it. These investments can also be thought of as experiments — trying out or investigating a certain practice for a few iterations to see how it might help can be a way to get started and make it less daunting. Either way, it is questionable that an Agile process without underlying agile practices applied can be agile at all. For sustainability, robustness, quality, customer service, fitness for purpose, and true agility in software development teams, it is important for continuous investment in agile engineering practices. [1] J. M. Sheppard & W. B. Young (2006) Agility literature review: Classifications, training and testing, Journal of Sports Sciences, 24:9, 919-932, DOI: 10.1080/02640410500457109