Welcome to the Home of Scrum! ™

Today is International Women’s Day! In the spirit of this year’s theme, #ChooseToChallenge, I would like to highlight an initiative between two women who came together with the common goal of elevating women in their respective communities and learning from each other in the process.

Join Leslie Morse, Product Owner of Professional Development Solutions at Scrum.org in celebrating Interational Women's Day. She issues two #ChooseToChallenge callings to the Agile industry. First, to seek out opportunities every day to find someone around you to share your glow with. Second, to find the courage to tackle your own sustainable pace journey.

TL; DR: Peer Recruiting Peer Recruiting is the new hiring: Shortly, all creative, technology-based organizations will need to abandon the command & control structures that served the industrial world of the 20th century so well. Instead, they will reorganize themselves around autonomous teams to deal with the complexity and pace of innovation of the 21st century. In such an agile world, recruiting will become a team decision, and the “human resources” department’s role will change into a supportive one. Recruiters will need to become servant leaders or facilitators, guiding the peer recruiting process. The following guide to peer recruiting is based on my experience in participating in recruiting Scrum Team members over the last ten years. This first article will cover the Scrum Master role. 🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 30,000-plus other subscribers. Join us on April 20, 2021, for a live virtual workshop on driving product innovation with the Zones of Value framework. (Participation is free.) I. Peer Recruiting and the New Role of People Operations In the near future, all creative, technology-based organizations will need to abandon the command & control structures that served the industrial world of the 20th century so well. Instead, they will become self-organized structures, built around autonomous teams. (Think of General Stanley McChrystal: “Team of Teams: New Rules of Engagement for a Complex World”). In such an agile world, recruiting will become a team decision, and the role of the people operations department will change into a supportive one. Recruiters will need to become servant leaders or facilitators in this peer recruiting process. The Supportive Role of People Operations Peer recruiting does not imply that People Operations—from here on referred to as “PO”—will be rendered obsolete. On the contrary, they will continue being a significant contributor to the success of the whole organization. However, People Operations’ role will change from choosing someone from the candidate pool and present that individual to the Scrum Team as the new teammate. Instead, they will support the team in picking the “right” candidate and ensuring that the legal and administrative side is being cared for. Typical tasks of the peer recruiting process that PO will provide to a Scrum Team, therefore, comprise of: Creating the remuneration package for the position in question (in compliance with the organization’s principles) Handling contractual and administrative issues (social security, visas, work permits, etc. Supporting the Scrum Team creating a job advertisement (if required) Placing job advertisement and run corresponding campaigns Doing background checks and pre-screening of applicants Organize interviews and trial days (from travel arrangements and meet & greet to introducing the organization) Collecting the Scrum Team’s feedback after interviews or trial days Handling the signing of the contract Finally, kicking-off the onboarding process for the new teammate. These steps hold a significant opportunity for PO to become a change agent for the organization, contributing to its agile transition by ensuring that new hires will have the required agile mindset. Why Bother with the Inclusion of the Scrum Team at all? You may wonder why a change of process will be required in the first place? There are plenty of reasons, my top three are: It’s consequent. On the one side, the Scrum Team is empowered to make decisions that directly impact the return on (product) investment. On the other, they are being patronized by deciding on new teammates for them? It also means the team has skin in the game. And they will be motivated to go the extra mile to make the new connection work. Now, it is their responsibility, too. Finally, not involving the Scrum team immediately signals to all candidates that your organization isn’t agile but merely “doing Agile”—a weak value proposition in the war for talent with an agile mindset. II. The Eight-Step Peer Recruiting Process of Hiring a Scrum Master Now, let’s have a detailed look at the proposed process, which has been proven to be motivating and successful several times so far in different organizations. 1. What kind of Scrum Master Are You Looking for? This is the question you will need to answer in the first place: What is the purpose of building autonomous teams in your organization? Does the organization want to become (or stay) agile? Or is the organization just “doing agile?” In the “team of teams” universe, you should always hire for the mindset. While you can quickly teach skills, training an unsuitable candidate in the right mindset will be futile most of the time. Therefore, the following description is targeting organizations that want to become agile. 2. Create a Job Advertisement In an ideal world, there wouldn’t be a necessity to run a job ad. Someone in the product development organization would personally know a suitable individual and introduce her to the team. (And the organization.) Unfortunately, truly agile people are in short supply. So there probably will be the need to create a job ad for the website and other channels. I strongly recommend kicking-off the collaboration between the Scrum Team and People Organization at this point. Most ads that PO departments produce for agile jobs are simply awful. Their usual “I don’t know what this is all about, but I have to come up with an ad by noon, so I copied the text from a competitor” approach scares away suitable candidates because they sense the lack of competence. Instead, I suggest sitting together with the whole team, sharing a coffee, and getting a copy of the ad right by being authentic and human and reflecting the organization’s culture. 3. Run the Job Advertisement That is the PO department’s job. However, the Scrum Team may have good suggestions outside the typical LinkedIn approach. Why not try Reddit, for example? Or sponsoring some meetups of the local agile community? 4. Pre-Screening Applicants It would be helpful for the team if PO could pre-screen applicants. This screening could be the standard background check. Or a first analysis if a candidate is suitable for formal reasons or in compliance with the hiring organization’s internal programs, for example, diversity initiatives. Unsuitable candidates should then be at least flagged and probably be removed from the pool. (Although the Scrum Team should be aware of that for transparency reasons.) 5. Discuss Suitable Applicants with the Team The team members should then be provided with access to all suitable candidates, preferably in the form of anonymized CVs: No photos, no age, no gender, no ethnic group, no religious believes—any information on candidates that might trigger a bias of whatever kind should be excluded. Also, you will normalize information on a candidate’s public profile, e.g. blog or Twitter or other accounts. A summary such as “A is actively contributing to the Scrum community by running a meetup as well as creating a newsletter with 800 subscribers“ will suffice for the selection process. If this approach requires a scissor, glue, and a Xerox machine, so be it. Please keep in mind that these biases are triggered on autopilot and that there is not willpower known to humanity that could prevent biases from interfering with the selection process. Then have a joined meeting—PO & all Scrum Team members—and discuss whom to invite for the in-person interviews. (A simple dot-voting will suffice in the end.) 6. Running the Interviews The “Hiring: 47 Scrum Master Interview Questions to Identify Suitable Candidates” PDF provides a broad set of questions (and possible answers), spanning several categories. Those are the starting point for the interviews. The purpose of the interviews is to identify those who will be invited for a trial day with the Scrum Team. Instead of one or two team members having an extended interview with a candidate each, I recommend running interviews of 30 minutes each with as many team members as possible. The trick is that you split the questionnaire evenly among the interviewers and later aggregate the answers. Thus, you will obtain more constructive feedback from all the interviewers. Tip: Create interview teams of two teammates each: One is asking questions, while the other is taking notes. After half of the interview has passed, they switch roles. The reason for that is that most people are not good at leading the conversation and at the same time take meaningful notes. Two people, however, will have a much better chance to recognize signals on the candidate’s side, for example, particular answers or body language. Note: It is important that exactly the same procedure applies to all candidates otherwise the results are less comparable. It is a good practice to run these debriefings to aggregate the answers right after an interview round with a candidate. Target for objectivity and have PO handle this task. They are the professionals. The most important question to answer, however, is the “Would you like to work with the candidate?” question. And that question should be asked the next morning. Sleeping on it will sober the interviewers and thus provide a path for a better decision. Tip: Go with your first thought and walk away from any candidate who will have lost the “yes” overnight. Don’t rationalize your decision, as people can be taught new skills, but they won’t change their personality. The trial day is an expensive exercise and should not be wasted. Candidates that are not considered for a trial day should receive an answer detailing the decision’s reasons. I know that legal departments tend to freak out over this. They usually fear legal action, for example, on the grounds of discrimination legislation. However, respect and transparency are important values of the agile community and should be honored accordingly in my eyes. Finally, invite the candidates that the Scrum Team would be interested in working with for a trial day. Let the team suggest a date, as they need to align a trial day with their Sprint rhythm. 7. Have a Trial Day A trial day for a Scrum Master should not merely focus on basic Scrum mechanics. If you do that, you might risk ending up choosing someone who is comfortable with “doing Agile by the book”. (Whatever book that is…) Hence, the purpose of the trial day is in my eyes to get a practical understanding of how the future Scrum Master can support the whole organization in becoming (more) agile. The three top areas, I focus trial days on, are as follows: The Scrum Team This is the simple part. Good exercises for hands-on learnings are: A. UNDERSTANDING THE CURRENT STATUS OF THE TEAM Have an introductory session with the complete team, a kind of “ask me anything” session for the candidate. A simple questionnaire will do the job, for example: 20 Questions a New Scrum Master Should Ask Her Team to Get up to Speed.. B. RUNNING A RETROSPECTIVE Ask the candidate to run a Sprint Retrospective with the Scrum Team in question. Thirty minutes to prepare for the exercise should be sufficient. I would expect a seasoned Scrum Master to have prepared Retrospective formats at hand. (Retromat offers a wealth of exercises to choose from, see also: How to Curate Retrospectives with Retromat. Scrum Master survival kit for in-person Retrospectives. By “Retrospective,” I am not referring to the basic “good, bad, and two actions items” thirty-minute version. I would expect something a bit more sophisticated along the lines of Esther Darby’s and Diana Larsen’s book: “Agile Retrospectives: Making Good Teams Great”. C. CREATING A DASHBOARD WITH AGILE METRICS Visualizations are essential to stakeholder communication, and I believe the Scrum Master should take care of collecting data, aggregating information, and finally providing the gained knowledge in a way that helps the organization grow. In this exercise, the candidate would be asked to create an initial version of such a dashboard and start collecting the first data. For example, typical metrics that are readily available by questionnaires or polls are: Team happiness, Perceived value delivered to customers during the last sprint, Perceived current level of technical debt, The agile health level in the organization: The Scrum checklist of Henrik Kniberg works fine for this purpose Alternatively, the ‘State of Agile’ Checklist for Your Organization Note: Acquiring stakeholder feedback on the level of appreciation of the product delivery organization will most likely not be possible on a trial day. The Product Organization Good exercises for the product organization are: 1. UNDERSTANDING THE CURRENT STATUS OF THE TEAM FROM THE PRODUCT OWNER’S PERSPECTIVE Have an interview with the Product Owner on the current situation from her perspective. Again, a simple questionnaire will do the job: 20 Questions from New Scrum Master to Product Owner. Good candidates will be prepared for that interview and provide their ideas on how they can contribute to improving the agile product discovery and delivery process. 2. PARTICIPATING IN A BACKLOG REFINEMENT The candidate should participate in a refinement session, helping the Scrum Team improve the Product Backlog in collaboration with the Product Owner—garbage in, garbage out, right? The candidate should demonstrate suitable refinement practices during the exercise, addressing: How to deal with large Product Backlogs, How to use the INVEST principle and the 3Cs to create Product Backlog items, How to handle acceptance criteria (for example, use Gherkin) The whole estimation vs. estimates process: estimation poker, knowledge transfer, #noestimates, predictability as an agile key metric. A good candidate can ask the right question during the refinement session without having detailed knowledge about the Product Backlog itself. Handling the process and its principles are the focus of this exercise. 3. STAKEHOLDERS AND THE ORGANIZATION BEYOND THE PRODUCT & ENGINEERING This part of the trial day assesses the future Scrum Master’s communication capabilities. “Selling” the product and engineering organization to stakeholders and the rest of the Organization is not just valuable but an essential trait to either further an agile transition or maintain its dynamic. It will be essential in organizations with silos and legacy command & control structures outside of the product and engineering organization. This also applies to fast-growing startups with a lack of organizational structure, to begin with, particularly when those are sales- or marketing-driven. The task for the candidate will be to design a basic communication strategy with stakeholders that is suited to support transparency, interaction, and collaboration. (Read more on this topic here: 10 Proven Stakeholder Communication Tactics during an Agile Transition.) A worthwhile trial day usually requires a full working day, as well as the attention of the whole Scrum Team, which is a pretty significant investment. So, choose the candidates carefully. Tip: Invite the candidate—as well as Scrum Team members—for lunch. It will be pretty much impossible for her to play a role for 60 minutes when interacting socially with several other people at the same time. Having food together brings out true colors. Note: Menlo Innovations takes the trial process even a bit further: “So we bring people in and get them to speed date with our own staff. The question is always: would you like to work with this person? If the answer is yes, then we bring them into work with us for a day, then a week, and then a month. If the answer is still, “Yes, I would like to work with this person,” then they are hired.” 8. Gather Feedback from the Team the Day after the Trial Day Collect the feedback from the team members the day after the trial day with a simple questionnaire: “How would you rate the candidate’s competency level on a scale from: 1 [Awesome!] to 6 [Thanks, but no thanks.]” “Did the candidate do anything to impress you positively?” (Free text field.) “Did the candidate do anything to impress you negatively?” (Free text field.) “Would you consider working with the candidate as your new teammate?” Three options: Yes No Don’t know “Should we make the candidate an offer? Three options: Yes No Don’t know If the feedback is unanimous, it is the People Organization’s task to take over. Either by entering the contract negotiation, or provide negative feedback from the Scrum Team, and continue the search. If the feedback is not unanimous, the team should discuss—under the moderation from PO—whether the differences are surmountable or not. In the latter case, the candidate should not be forced upon the team. The team always has a veto right. III. Conclusion If your organization shall become agile, switching the hiring process to peer recruiting will be necessary. It won’t make PO obsolete, but its role will change to facilitating others choosing the right candidates. Thus, the People Organization department will become a change agent, contributing to the agile transition of the organization. Trying to stick with the traditional command & control process on the other side would signal everyone with an agile mindset that your organization isn’t agile, but merely “doing Agile.” And why would a real talent want to join you then? Please share your experience with us in the comments. ✋ Do Not Miss Out and Learn more on Peer Recruiting: Join the 9,000-plus Strong ‘Hands-on Agile’ Slack Community I invite you to join the “Hands-on Agile” Slack Community 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. Related Posts Hiring: 42 Scrum Product Owner Interview Questions to Avoid Agile Imposters Agile Failure Patterns in Organizations

The significance of Mirrors in our world I am sure you must have come across funny mirrors in theme parks or fun carnivals which makes you see a ludicrous version of yourself, maybe a heavier or lighter version. It’s good for a laugh, but you won’t buy one of those for your home to use regularly. On a regular basis, we want to see our true reflection in a normal mirror when getting ready for school, work, etc. The mirror enables us to take a look at the way we appear and then adjust from there. Please bear in mind that “THE MIRROR CAN’T ADJUST THE WAY YOU LOOK”. How feedback loops relate to mirrors Feedback loops are also like mirrors in our Agile journey, they have the capability to show us how we work at the present stage helping us interpret what can be improved, but the responsibility to experiment and improve things lies with us. These feedback loops can’t change the way we work, just like the mirror can’t change your appearance. One of the most common and frequently used feedback loops is Daily Scrum, which helps you inspect what is already done and adapt the course of your work towards the Sprint goal. When we use a dirty mirror, it doesn’t give us a clear reflection of our appearance. If we still don’t clean it, we adjust our appearance based on the vague image that we see in the mirror, which may lead to a disastrous outcome. Similarly, Daily Scrum helps the team to inspect the progress and adapt the plan towards the sprint goal. If the Daily Scrum is not done efficiently then the progress of the sprint goal becomes vague and may lead the team towards a poor plan, thereby, spearheading towards a disastrous sprint. Let’s explore what may cause an inefficient Daily Scrum. 5 Dysfunctions of Daily Scrum: Status Updates: When the daily scrum restricts to the status updates, for example: “the story that I am working on is In-progress” or “the story I am working on is blocked”. In these cases, the progress on that work unit never surfaces. What has already been done and what more needs to be done. If something is blocked then what is it blocked by and who can help it unblock. This information not only helps the team get better insights on the progress but also helps the development team to know what will be done next, increasing the accountability within the team. Passive participation: I strongly believe that we must share what we are working on, be it development, quality assurance, DevOps tasks, or any enabling task. Active participation helps the team understand the value of collective accountability and ownership, helps a team to better understand the present situation so that they can help each other in the best way possible. Passive participation also promotes Silo formation within the team based on expertise. This is one of the reasons why Scrum doesn’t recognize titles within the Scrum teams. Invisible Work: Team often works on units that are not present in sprints, this hampers the transparency around the progress towards the sprint goal and also impacts the forecasting abilities of the team. It is perfectly fine to add some unforeseen work to the sprint which compliments the sprint goal but it needs to be communicated and discussed with the Product Owner to find the best way to accommodate the change within the sprint. No Impediments: We know software development is complex in nature, and it is quite impossible to stay in a “No impediment” Zone for some time. If the team is habitual to state that they don’t have any impediments then, it can be a smell. In these cases helping the team understanding what can be stated as impediments can help them raise the impediments. If they can identify the impediments faster, they can resolve the impediments faster. Feet Dragging: This is a very visible sign of an inefficient Daily Scrum some examples can be Team members waiting for each other to move first for Daily Scrum or Team takes time to arrange themselves for Daily Scrum. These are the cases where the team doesn’t get value out of their Daily Scrum. Helping them understand the purpose of daily scrum can be a good starting point for these cases and then comes the silver bullet to all the solutions in the Agile world i.e. “INSPECT & ADAPT”. Conclusion To get a clear reflection, you need to keep your mirror clean. To become transparent you have to clean your feedback loops.