This post will deep dive into step 1 of the cycle: receiving feedback.
Examples:
What are some example ways to receive feedback from your users?
As a Scrum Master, getting feedback from your team through a retrospective or 1:1’s with your team members
For larger groups such as ARTs, or larger customer bases, you’ll want to use more scalable feedback mechanisms like NPS Surveys.
Your company may have existing mechanisms for getting feedback, such as regular surveys or 360° feedback. Leverage these existing mechanisms where possible.
If possible, try to mix in quantitative and qualitative data. For example, user telemetry data can be invaluable if you’re supporting a software product.
Why it’s important:
Though it might seem obvious, you need to make sure you’re hearing pain points directly from the user, and not simply guessing about their pain points.
Pitfalls to avoid:
Make sure you have at least something set up that allows you to get feedback from all users. It’s easy to fall into a trap of chatting with your “go-to” people, which gives a partial view of your organization.
Make sure you have mechanisms that get feedback regularly. A common pitfall I see is that a group gets a bunch of feedback all at once…and then doesn’t connect with users again for another year. Be intentional about building feedback mechanisms that repeat regularly. “Regularly” will vary based on the size of your audience, but quarterly or once per PI is a good minimum to shoot for.
This is the cycle I use for all my work as an Agilist – whether as a Scrum Master, Release Train Engineer, or Agile Coach to track the improvement work you’re doing for your team, Program, or Portfolio.
More generally, this cycle works well for any work where you’re trying to delight customers without a strict requirement document – virtually any working environment!
Why “Relentless?”
I intentionally use the word “relentless” to describe this cycle, rather than the more commonly used “continuous”. “Continuous” has an implied passiveness about it, whereas “relentless” has an association of active, intentional action.
I think of “continuous” like a river passively flowing; “relentless” is a kayaker actively paddling toward a destination, regardless of the current.
Main Benefits
This cycle addresses several overlooked parts of delivering value to users:
Communicating with users: Steps 1 & 4 ensure a bi-directional flow of communication directly with end users. To properly implement this cycle, you must establish a way to both receive feedback and communicate changes out to your users. You can’t just sit in an ivory tower, doing what you think is best for the user.
Turning feedback into action: Step 2 explicitly calls out the hard work of turning messy user feedback into tactical actions
Recognition that these are small experiments:
Connecting user feedback to improvements: All too often I would hear users complain that they take too many surveys in their corporate environment, and they don’t feel like the surveys are valuable. If surveys are a part of your “receive feedback” strategy, executing on this cycle can help you communicate to your users that the changes you made were a direct result from survey feedback, proactively addressing the concern that survey feedback doesn’t make an impact.
Turn These Steps into your Kanban Columns
These 4 steps can become the steps in your process flow. By making them the headers of your Kanban columns, you can now visualize all the small experiments you’re working on, tracking them from feedback all the way through communication back to your users.
Wrapping Up
This is the overview of the cycle. I’ll be deep diving into each of the 4 steps in subsequent posts, giving example actions you can take, why the step is important, and common pitfalls you want to avoid.
In my role as an Agile Coach, I’ve been asked to work to help upskill candidates who become eligible to transfer internally into a Scrum Master role. I’ve helped 2 candidates do so to date, and want to provide tips for others.
This article is focused on internal transferring, though much of this guide is applicable to candidates applying to external positions as well.
Make a plan. Your plan can/will change over time, but have a rough idea of how you’re going to get from point A (current role) to point B (Scrum Master). You’ll want to actually write down your plan and track your progress. Be able to show anyone your progress. You’re going to have an uphill journey convincing hiring managers to take a risk on you, so you’re going to need to be able to tell your story of how you’ve upskilled to be ready to be a Scrum Master. If you have a good plan, you will have a convincing story. Your company may have a program to do this, and if not, you can use the suggestions below. Are you going to try to transfer internally or apply outside your company? You’ll need different approaches depending on which route you are applying. The rest of this is assuming you’re trying to transfer internally.
Understand HR Red Tape. You want to get ahead of any HR policies that might prevent you from transferring internally. The two HR policies you need to consider are Geography and Leveling. For Geography – understand if your company is hiring Scrum Masters only for certain physical locations or if they are hiring from anywhere. If it’s certain locations, are you already located in one of the hiring zones? If not, are you willing to relocate? For Leveling – some companies have rules about internal transfers around leveling. Our company had a rule that you could only apply for jobs that are lateral moves from your current level. If your company has a rule like this, make sure to understand the level that Scrum Masters are hired and what your current level is.
Learn Agile and Scrum Basics. There are lots of great resources for this. Start with the Scrum Guide.
Learn tech basics if possible. Our company had a program for Technology topics for non-engineers. This gave non-technical people a basic understanding of technology concepts. This is a less important step, but can give a leg up in understanding what your team is working on.
Find a mentor. Someone you can bounce questions off of.
Find someone willing to let you shadow. This might be the same person as your mentor, but find a current scrum master who will let you shadow them on the job. Over time, try to see if you can facilitate their events for them, with them watching you instead.
Get certified. Look for opportunities to get certified. My experience is the SAFe Scrum Master (SSM) is the best certification if your organization is using the SAFe framework, which many Fortune 500 companies are. If you’re unable to obtain a SSM, see if you can work towards a Certified Scrum Master (CSM) or Professional Scrum Master I (PSM I).
Nail your behavioral interview questions. At this point, you’re probably ready to start applying. Be ready to tell the story of why you’re ready to be a Scrum Master (Did you write down your plan in Step 1 and track progress toward it? If so, this is the pay off!) Look for other common behavioral interview questions for Scrum Masters and be ready with convincing answers.
Apply, apply, apply! You’ve got an uphill battle to convince hiring managers to take a chance on you. Figure out the formal and informal ways that hiring managers post jobs at your company. Many hiring managers only want experienced Scrum Masters, so look for those who are willing to take a chance on an entry-level Scrum Master
Continue building your network. While you’re applying, keep building your network of Agile professionals. The more people who can vouch for you, the more likely it is that you’ll find someone who is willing to take a chance on you.
This is a non-trivial process. For the candidate that I’ve been able to place, it took them 6-12 months to complete this process and start their first Scrum Master role.
But it’s worth it! Being a Scrum Master is a very rewarding career, which is why I’m passionate about helping others upskill such that they can enter the field.
This talk gives 5 key ideas from SAFe’s LPM training class, and shows how to put them into practice using Jira Align. These are two topics that I’m very passionate about, so it was a lot of fun to put them together for this talk.
On 11/18, a new version of the Scrum Guide was released. This was the first major revision since 2017! This is the location where Ken Schwaber and Jeff Sutherland come together to agree upon “What is Scrum?”
Most (all?) major Agile scaling frameworks build on Scrum. It’s amazing how many Scrum Masters aren’t actually familiar with the Scrum Guide!
The Scrum Guide calls out 7 major changes to the Scrum Guide, which I’ve condensed into the 6 topics below:
1. Lighter & Less Prescriptive
The Scrum Guide is down to 11 pages from 17, and has been made more broadly applicable. Language referring to software has been removed, and simpler language has been implemented.
The Scrum Guide seems to be moving to be more broadly applicable across domains and contexts. The Scrum Events are less prescriptive than they previously were. For example, the Three Questions have been removed from the Daily Scrum section.
These small changes will allow the Scrum Guide to be applicable in more domains, which can only be a good thing for Scrum.
2. Sprint Goal, Definition of Done, and Product Goal Linked to Their Artifacts
This is perhaps the most consequential change to the Scrum Guide. While all three Commitments existed before, they were loosely defined. They’ve been called out explicitly as “Commitments” and tied directly to the Scrum Artifact of which they support.
Each Artifact can be thought of as a unit of delivered work. Each Artifact now has an associated commitment that allows Stakeholders and the Scrum Team to understand what is expected within the Artifact.
Artifact
Commitment
Product Backlog
Product Goal
Sprint Backlog
Sprint Goal
Increment
Definition of Done
This addition will be a great reminder for teams about the different levels of commitments that exist within the framework. I hope this encourages Scrum teams to avoid glossing over these important commitments.
3. Product Goal
“The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against”
The Product Goal is completely new terminology that is referenced in the change listed above about commitments and emphasizes the importance of having a longer-term vision for your product.
Though it seems obvious to look ahead, it’s very easy for Scrum teams to lose the forest for the trees while executing their sprints. In my opinion, one of the many reasons that Agile scaling frameworks are so popular is to help support long-term planning. I love that the Scrum Guide is being more explicit about the importance of longer range planning.
4. One Team
The phrase “Development Team” has been removed from the Scrum Guide to avoid the idea of a “team within a team”.
In practice, I often hear the phrase “core team,” which is another key signal of the existence of a team within the team.
The Scrum Guide has made some subtle changes to drive home the idea that there is a single Scrum Team with 3 roles – a Product Owner, a Scrum Master, and Developers. Developers is explicitly defined as any team member who does the work, even though it is very software-specific language. I do wonder if this language will change to be more generic in a future Scrum Guide update.
5. Self-Managing Instead of Self-Organizing
This is a change that is so subtle that I’m not sure why the authors called it out as one of their most important changes. The terms are generally interchangeable in common usage, and even the Agile Manifesto Principles use the term “Self-Organizing.”
The authors of the Scrum Guide believe that self-organizing means that the team defines when and how the product is built. They believe that self-managing means that the team defines when, how, and what is built (emphasis mine).
I believe this is intended to reinforce the change listed above about One Team – reemphasizing the idea that the Product Owner is a part of the Team and the Team is defining what gets built.
6. Sprint Planning Addition – “Why”
Answering the questions “What” (can be built) and “How” (will it get done) have always been a part of the Sprint Planning event. With the new update, the question “Why” has been added – instructing the teams to answer the question “why is this sprint valuable?”
I think this is a great addition to remind teams not to hyper focus on the tactical things being built – similar to reasoning behind the Product Goal.
Final Thoughts
A lot of these changes are subtle, but I do think they are moving the Scrum Guide forward, which is always great. I look forward to see what future enhancements will be made in future versions.
Parkinson’s Law is a rampant idea, though many don’t know the idea by this name. Parkinson’s Law states that:
“Work expands so as to fill the time available for its completion”
Parkinson’s Law was proposed by Cyril Parkinson in 1955 in a satirical article that mocked government bureaucracy, so it was likely never intended to be taken seriously. [1]
However, this idea often has legs. After all, we’ve all had experiences where a time crunch inspires an amazing amount of work to be completed in a short amount of time. Maybe you managed to learn a semester’s worth of material in the week leading up to the final exam. Or had a project with a tight deadline that inspired a heroic effort.
Or perhaps you’ve been on the flip side of this law, where work without a deadline expands:
Parkinson’s Law is Supported by Science
Evolution Research Sets the Stage
It turns out that Parkinson’s Law is actually supported by science. The story beings with research on evolution from Niles Eldridge and Stephen Gould.
The prevailing theory of evolution was that it occurred in a smooth, upwards progression. Eldridge and Gould discovered that for many species, evolution was not a smooth progression, but long periods of relative stability with short bursts of change. This is called the “punctuated equilibrium” model:
Gersick Discovers the “Uh Oh Effect”
Connie Gersick was researching organizational behavior to discover how teams complete projects. She studied 8 groups of teams of various size (3-12 people), different project lengths (7 days to 6 months), across different domains.
She found that progress was not linear like the phyletic gradualism model. Instead, the groups made progress that resembled the punctuated equilibrium model – long stints of stagnation followed by bursts of intense progress. [2]
The interesting finding is that what prompted the shift was consistent across the groups. It was the halfway point of the deadline.
We call this the “Uh Oh Effect” – seemingly halfway through the course of the project, the teams collectively said “Uh oh,” and adjusted their approaches to allow more effective progress.
How to Leverage the “Uh Oh Effect” for Agility
People don’t like to talk about Parkinson’s Law, or the “Uh Oh Effect” in the context of organizational Agility because it often promotes waterfall-like behaviors. Leaders use this idea to set overly-ambitious deadlines for big chunks of work to ensure that work gets done in a timely manner:
This is inherently waterfall behavior, but I also argue that it’s inefficient. Remember, based on Gersick’s research, that regardless of project length, the first half of the project is largely ineffective. Only at the temporal midpoint does the team say “Uh oh,” and identify more effective ways of working, and make huge movement forward in a punctuated equilibrium type of progress.
I believe knowing about Parkinson’s Law and the “Uh Oh Effect” should lead us to thinking in smaller units of work and smaller time blocks. Remember, that the first half of the timebox isn’t very effective, regardless of the size of the timebox. So use smaller timeboxes to increase the numbers of “Uh Oh’s” that your team gets.
I made this clip to document a technique I created to run a Team Norms building session for a team. It’s a two-part technique that allows for rapid brainstorming for the first half and a deeper dive into tricky team issues for the second half.
This technique was a big hit with my team, and I think this is a great technique if you’re going to run a team norms session for your team!
On 4-3-19, I’m excited to be brining my talk “What Can Agilists Learn from Super Hero Movies” to Raleigh for Tri-Agile! Here’s a small taste of what I’ll be sharing:
While this is too much content to clone onto this forum, myself and 2 colleagues put together a nice series on the 12 Principles of Agile. This series tackles common problems that organizations face in achieving each Principle.
This series is near and dear to my heart. I find that working with the 12 Agile Principles can be a great guiding light to fostering better Agility.
Check out the first part of the 12 part blog series here!
I was the featured guest on this week’s episode of the SqlDataPartnters Podcast, talking about technologists and Super Heroes. Feel free to give it a listen at http://sqldatapartners.com/superheroes or find episode 132 on the SqlDataPartnters podcast on your favorite podcast app.
Will Talks Tech 