Stefan Wolpers

TL; DR: Scrum Master Anti-Patterns from Job Ads Job ads for Scrum Master positions reveal great insight into an organization’s progress on becoming agile. I analyzed more than 50 job ads for Scrum Master positions to gain these. Learn more about what makes job ads such a treasure trove with the following 22 Scrum Master anti-patterns derived from job ads. 🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 29k other subscribers. Analyzing a Job Advertisement for a Scrum Master Position Probably, you are considering a position as a Scrum Master in a particular organization. I suggest that before going all-in (the application process), you should consider analyzing the job description for Scrum Master anti-patterns first. How Large Organizations Create Job Ads Usually, the organization’s people management department will create the job advertisement’s final text and post it to the chosen job sites. Hopefully, and depending on their process and level of collaboration (and agile mindset) in the organization, the team for which the new position was advertised may have participated in creating the job ad. This certainly avoids promoting the wrong description to prospective candidates. However, too often, advertisements may read like a copy and paste from positions that an organization’s people management department believes to be similar to that of a Scrum Master (for example, a project manager). Sometimes, the people management department copies from other Scrum Master job ads that they believe correctly reflect the organization’s requirements. So, don’t be too surprised to see a job advertisement that reads like a list of Scrum Master anti-patterns. Red Flags: A Sign of Cargo Cult Agile or just on Organization at the Beginning of the Agile Transition? This is often the case when an organization’s people management does not have a lot of experience in hiring agile practitioners because they are in the early stages of the agile transition. Therefore, an unusual job description does not imply that the organization is not trying to become agile; it may just mean that the people management department has not yet caught up with the new reality. Such an advertisement can help raise the topic and benefit during the job interview. However, be aware that if an organization that claims to be agile is using this kind of advertisement despite being well underway on its agile transition, it then raises a red flag: miscommunication in the hiring process may indicate deeper issues or problems at the organizational level. It could be as critical as someone at the management level, to whom the new Scrum Master would likely report, having no clue what becoming agile implies. Scrum Master Anti-Patterns from Job Ads in 22 Examples Let’s have a look at some examples of Scrum Master anti-patterns from more than 50 job descriptions that should raise a red flag: Ersatz PM: The Scrum Master position is labeled as “Project manager/Scrum Master”, “Agile Project Manager”, or “Agile Scrum Master”. (Are there un-agile Scrum Masters mentioned in the Scrum Guide?) The whip: The Scrum Master is expected to communicate the company priorities and goals. (Product Backlog-wise priorities are the job of the Product Owner. Scrum-wise it is a good idea that the Scrum Master spreads Scrum values and, for example, coaches the Scrum Team to become self-managing. Whether this is aligned with the company goals remains to be seen.) Technical PO: The Scrum Master is also supposed to act as a (technical) Product Owner. (There is a reason why Scrum knows three accountabilities and not just two. Avoid assuming more than one role at a time in a Scrum Team.) Outcome messenger: The Scrum Master reports to stakeholders the output of the Scrum Team (velocity, burndown charts). (Velocity—my favorite agile vanity metric.) (Read More: Agile Metrics — The Good, the Bad, and the Ugly.) SuperSM: The Scrum Master is supposed to handle more than one or two teams simultaneously. (Handling two Scrum Teams is already challenging, any number beyond that is hardly feasible.) Scrum scribe: The Scrum Master is supposed to do secretarial work (room bookings, facilitation of events, ordering office supplies). (Read More: Scrum Master Anti-Patterns: Beware of Becoming a Scrum Mom (or Scrum Pop).) Problem solver-in-chief: The Scrum Master removes all problems on behalf of the Scrum Team. (How is the Scrum Team supposed to become self-managing if the Scrum Master handles all obstacles? ‘Impediments’ are those issues that the Scrum Team cannot solve independently.) Team manager: The Scrum Master is responsible for team management. (If nothing else helps read the Scrum Guide: Is there anything said about team management by the Scrum Master?) Delivery manager: The Scrum Master is responsible for the “overall delivery of the committed sprint”. (I assume the organization does not understand Scrum principles very well. The forecast and the Sprint Goal seem to be particularly challenging.) Delivery scapegoat: The Scrum Master is expected to accept full responsibility for the delivery process. (That is the responsibility of the Scrum Team.) Proxy PO: The Scrum Master is expected to drive functional enhancements and continuous maintenance. (Maybe someone should talk to the Product Owner first?) Keeper of the archives: The Scrum Master is expected to maintain relevant documentation. (Nope, documentation is a team effort.) The PM Reloaded: The Scrum Master organizes the Scrum Team’s work instead of the project manager. (Why use Scrum in the first place if creating self-managing teams is not one of the milestones to solve complex adaptive problems?) Risk detector: The Scrum Master is expected to monitor progress, risks, resources, and countermeasures in projects. (The Scrum Master is neither a project manager nor a risk mitigator. (Risk mitigation is a side-effect of becoming a learning organization built around self-managing teams.)) Scrum minion: The Scrum Master is expected to prepare steering team and core team meetings. (The last time I checked the Scrum Guide there was no ‘steering team‘ mentioned.) Here, I am lost: The Scrum Master is expected to perform the role for “multiple flavors of agile methodologies”. (Multiple what?) Psychic: The Scrum Master is expected to participate in “project plan review and provide input to ensure accuracy”. (The Scrum Master is neither a project manager nor capable of predicting the future any better than another human being.) Bean counter: The Scrum Master is expected to “review and validate estimates for complex projects to ensure correct sizing of work”. (Well, reviewing estimates might be the job of the Scrum Team during the Product Backlog refinement process if they see value in that. However, there is no review by the Scrum Master. Finally, ‘correct estimates’ is an excellent example of an oxymoron.) Product discovery guru: The Scrum Master is expected to provide “Design Thinking sessions.” (I love covering the product discovery process, too. However, this should be a joint effort with the Product Owner and the rest of the Scrum Team.) Techie: The Scrum Master is expected to “walk the Product Owner through more technical user stories”. (Nope, that is the job of the developers. The Product Backlog refinement sessions are ideal for this purpose.) Siloed in doing agile: There is no mention of the Scrum Master either coaching the organization, the stakeholders or coaching the Product Owner. Lastly, my favorite Scrum Master anti-pattern from job ads is: “…working reliably on projects within a given time and budget frame whilst maintaining our quality standards.” In other words: “Actually, we’re happy with our waterfall approach but the C-level wants us to be agile.” Conclusion — Scrum Master Anti-Patterns from Job Ads Imagine, the job ad of the organization of your interest is a best-of of Scrum Master anti-patterns. Should you, in this case, immediately drop your interest in becoming a member of that organization? I don’t think so. An extensive list of red flags can be beneficial, too. For example, the people management department might merely be misaligned with the Scrum Team in question as the organization is still in the early day of its agile transformation. That sounds like an attractive opportunity for me. On the other hand, the organization might merely try to attract talented people by sugar-coating the otherwise command & control management style with some glitzy agile wording. Continuing the application process under these conditions might indeed be a waste of your time. A short phone call or interview will bring clarity. What other Scrum Master anti-patterns from job ads have you noticed? Please share your findings with us in the comments. ✋ Do Not Miss Out: Join the 9,000-plus Strong ‘Hands-on Agile’ Slack Team I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world. If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free. Related Posts 47 Scrum Master Interview Questions to Identify Suitable Candidates. Peer Recruiting: How to Hire a Scrum Master in Agile Times. Scrum Master Anti-Patterns — 20 Signs Your Scrum Master Needs Help. Download the Scrum Guide 2020 Reordered for Free.

While the new Scrum Guide is less prescriptive and more inclusive, it also ties loose ends by including elements better, namely the previously free-floating Sprint Goal and the Definition of Done with the creation of Scrum commitments. This inclusion works remarkably well in the former’s case; regarding the latter, we need a shoehorn, though.

If you are looking to fill a position for a Product Owner in your organization, you may find the following 71 interview questions useful to identify the right candidate.

As 2020 comes to an end, you are probably considering how to further your career as a Scrum Master or Product Owner in 2021.

If you have to make a career decision early next year, you will find the industry data the Scrum Master Trends Report 2019 contains still very helpful.

TL;DR: The Scrum Product Owner in 58 Theses The following 58 Product Owner theses describe the PO role from a holistic product creation perspective. They cover the concept of the Product Owner role, product discovery, how to deal with external and internal stakeholders, product portfolio and product roadmap planning, and the Product Backlog refinement. The Product Owner theses also address the Product Owner’s part in Scrum events from Sprint Planning to Sprint Review to Sprint Retrospective, and the Daily Scrum. Do you want to get this article in your inbox? You can sign up here and join 28k other subscribers. The Product Owner Theses A Product Owner is an innovator at heart and thus a value creator for customers and organizations if given a chance to work in an agile manner. The Product Owner is also the most vulnerable Scrum role. Turn them into a [fill-in a ticket-system of your choice] monkey or deprive them of the ability to say ‘no’—as in being the guardian of the Product Backlog—, and the Product Owner quickly becomes the Achilles heel of any agile organization. The Product Owner role depends on the size of an organization, the industry it is operating in, its culture, and the lifecycle stage of that organization’s product(s). Lastly, there is an overlap with the product manager role. (Spoiler alert: they aren’t identical.) The following Product Owner theses attempt to provide an overview of a successful Product Owner’s responsibilities and competencies. Role of the Product Owner This category of the Product Owner theses addresses the meta-level of the Product Owner role and the Scrum process: The Product Owner embraces, shares, and communicates the product vision, representing the customer voice and internal stakeholders. Process-wise, the Product Owner is accountable for effectively managing the Product Backlog, thus “owning” the product on behalf of the organization. The Product Owner is accountable for maximizing the value— resulting from the Scrum Team’s work—that the product is providing to customers and the organization. To achieve this, the Product Owner is empowered to make all necessary product-related decisions on behalf of the organization. If “Product Owners” are not empowered to do so, they are no Product Owner per se, and the organization is not practicing Scrum. The Product Owner thus acts as the single representative of all stakeholders—internal and external—toward the Developers. The Product Owner owns the “why” and influences the “what” and “who,” but never the “how.” Therefore, any product progress is always a collaborative effort of the Scrum Team. The Product Owner needs to work closely with the Scrum Team members, particularly with the Scrum Master. Those two are natural allies. The Product Owner shall actively participate in Scrum events. Additionally, there is the Product Backlog refinement as a continuous process. Therefore, the Product Owner needs to be with the rest of the Scrum Team—co-located or distributed—to avoid delays, communication errors, and other forms of waste. Contrary to popular perception, the Product Owner is neither a user story author nor a requirements engineer, but a communicator, a storyteller, and facilitator among all stakeholders. Product Discovery and External Stakeholders This category of the Product Owner theses is branching out into the areas of product discovery and product management: The Product Owner has a holistic understanding of problems and opportunities in a market, the product itself, the organization and its strategy, and its various stakeholders. The main accountability of the Product Owner is driving value for customers and the organization while mitigating risk at the same time. The Product Owner lives up to these responsibilities by embracing a continuous product discovery process designed around learning and experimentation. In this process, the Scrum Team validates hypotheses continuously through experiments. Suitable frameworks and practices for this kind of product discovery process are, for example, Lean Startup, Lean UX, Design Thinking, Design Sprints, or the Business Model Canvas. Also, user story mapping, continuous user testing, rapid prototyping, or A/B testing have proven helpful. The Product Owner is capable of thinking in systems to deal with complexity and uncertainty. Product Owner Theses: Internal Stakeholder Management This category deals with specific aspects of relationships of Product Owners with internal stakeholders: The Product Owner needs to gain the trust and mandate of internal stakeholders. The Product Owner can explain to any stakeholders how their requirements fit into the plan of how to achieve the product vision. Regular feedback from internal stakeholders is crucial to the Product Owner’s successful work, namely providing input to the hypotheses funnel to run experiments. Close cooperation with customer care and sales has proven to be particularly relevant for product success. The Product Owner has to be empowered to say “no” to requests no matter how influential the stakeholder is. Communication with stakeholders needs to be transparent and regular to encourage their engagement with the Scrum Team. The Scrum Master proves to be a good ally in the pursuit of stakeholder engagement. Good opportunities to engage stakeholders are Scrum events like the Sprint Review, workshops such as user story mappings, or training team members of stakeholders to better communicate with the Scrum Team in general. Stakeholders make excellent members of the customer development or user research team. Product Portfolio, Product Goal, and Roadmap Planning This category covers one of the most controversially discussed topics: how to build product roadmaps that work for a Scrum Team? Product definition: “A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users, or customers. A product could be a service, a physical product, or something more abstract.” (Source: Scrum Guide 2020.) Product Goal definition: “The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. [The Scrum Team] is a cohesive unit of professionals focused on one objective at a time, the Product Goal.” (Source: Scrum Guide 2020.) The role requires that Product Owners act like product managers. The Product Owner is familiar with the six levels of agile planning: product vision, product strategy, product roadmap, release planning, Sprint Planning, and Daily Scrum. Acting like a product manager includes working on the product vision, strategy and market research, business models, lifecycle management, and product portfolio and roadmap planning. (See also Roman Pichler’s “The Scrum Product Owner Role on One Page.”) Generally, portfolio planning in larger organizations with several products requires each Product Owner to align with other Product Owners to synchronize development efforts. While the product roadmap addresses strategic aspects of product planning, the Product Backlog addresses tactical and technical development issues. Roadmap planning is—like Product Backlog refinement—a continuous effort, just at an extended cadence. An agile product roadmap is a high-level plan that describes how the product vision is likely to be accomplished, facilitating experimentation and learning at the same time. Agile roadmaps are based on objectives and are usually theme- or goal-oriented. However, an agile roadmap is not a mere list of prioritized features with a fixed shipping date for months to come. (See also: “Product Roadmap First Principles.”) Product Owners communicate the “big product pictures,” for example, by utilizing user story mapping techniques. (See also Jeff Patton’s “User Story mapping.”) Having a committee of stakeholders deciding on product discovery and portfolio management is the most critical reason for agile product delivery initiatives’ failure. Product Owner Theses: Product Backlog, Refinement, Work Items, Forecasts, and Estimations This category covers the Product Owner’s home turf: the Product Backlog, its refinement, and user story work item creation: The Product Owner is not the primary author of the Product Backlog, churning out work items on behalf of stakeholders. (Ticket application monkey syndrome.) All user stories are work items, but not all work items are user stories. Creating user stories does not equal breaking down requirement documents from stakeholders into smaller chunks. Writing user stories is a collaborative effort with the whole Scrum Team to create a shared understanding of what shall be built for what reason for whom. Hence, a user story is a token for discussion, which is why refining the Product Backlog may take up to 10% of the Scrum Team’s availability during the Sprint. Product backlog refinement is a continuous process and needs to be synchronized with the product discovery process. Creating an actionable Product Backlog requires the Scrum Team to work collaboratively on Product Backlog items for two to three Sprints in parallel. The Scrum Team needs to agree on what standards work items need to match before the Developers can choose them as work items in a Sprint. The most crucial purpose of the estimation poker is knowledge transfer and supporting the creation of a shared understanding among all members of the Scrum Team on what needs to be built. Estimations also allow forecasting a window of availability for work items. Estimations are a crucial part of the risk mitigation strategy of the Scrum Team. Product Owners should be familiar with Ron Jeffries’ Three-Cs—Card, Conversation, Confirmation, and Bill Wake’s INVEST principle. Sprint Planning, Sprint, Sprint Review, and Retrospective The Product Owner theses’ sixth category addresses Scrum events from Sprint Planning to the Sprint Retrospective and a PO’s responsibilities during the Sprint: The Product Owner sketches the upcoming Sprint’s potential scope by identifying the most valuable Product Backlog items. The Product Owner defines the business objective the upcoming Sprint shall accomplish. The Scrum Team creates the Sprint Goal during Sprint Planning. The Product Owner understands that next to user stories, technical or refactoring tasks, bugs, and research need to be addressed in each Sprint. The Product Owner is available on short notice to clarify questions of the Developers during the Sprint. The Scrum Team decides on the release of a Product Increment. The Product Owner hosts the Sprint Review to “inspect the outcome of the Sprint and determine future adaptations” of the Product Backlog. The Product Owner embraces the Sprint Review as a vital inspection and adaption feedback loop with the Scrum Team, external, and internal stakeholders. Conclusion: Product Owner Theses Scrum has always been a pragmatic business, and to succeed in this mindset, Product Owners need to have a passion for getting their hands dirty. While the basic rules are trivial, getting a group of individuals with different backgrounds, levels of engagement, and personal agendas, to continuously deliver value by creating a great product is challenging. The larger the organization is, the more management level there are, the more likely failure in one of its many forms is lurking around the corner. Which relevant Product Owner theses are missing to describe the role in a better way? Please share your thoughts with us in the comments. ✋ Do Not Miss Out: Join the 8,800-plus Strong ‘Hands-on Agile’ Slack Team I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world. If you like to join, all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free. Product Owner Theses — Related Posts 71 Scrum Product Owner Interview Questions to Avoid Agile Imposters Product Owner Anti-Patterns — 31 Ways to Improve as a PO. 70 Scrum Master Theses. 47 Scrum Master Interview Questions to Identify Suitable Candidates. The Scrum Guide Reordered — understand the Scrum Guide’s patterns and concepts.

If you are looking to fill a position for a Product Owner in your organization, you may find the following 71 interview questions useful to identify the right candidate.

The Scrum Guide Reordered 2020 is based on about 95 percent of the text of the Scrum Guide 2020, extending its original structure by adding additional categories, for example, on self-management, commitments, or accountability.

TL; DR: The Scrum Guide 2020-The Scrum Guide 2020 is available now: Change is coming to make Scrum more accessible and inclusive beyond software development.

A Sprint Planning checklist? How dare you: Agile is a mindset, not a methodology. It is a journey, not a destination. There is no one-size-fits-all approach, and what else could you possibly cover with a checklist, the mother of all standardized processes?