• Brian Levy

Picking and Choosing Agile’s Scrumworks in Performance Management

Provided, the scrum guide acts as a helping hand for companies and organizations that are making the switch using agile and scrum methodology. Unfortunately, there are bad agile and scrum methodology out there, and so, because the industry has become agile and scrum, let’s learn how we should use agile and scrum. Typically, what’s happening in the industry is people want to make a higher salary and so they take a course (at places like Bridgeport Digital), get certified, and go out to adopt some of the “agile practices” that would justify getting paid a higher salary. What I’d like to do with you today is steer you away from the techniques and processes that people consider “agile.” I’d like to do this by discussing more of the underlying rationale about how things should happen; here’s the why behind it all. If you understand why, you will be able to create your own practices, create your own way of going and it will comply with everything necessary from scrum and agile.




The expectation when you’re using scrum and agile is that you create your own processes; you’re not just receiving one and trying to duplicate it. And so, I’m going to give you the information you need to craft the process, the way you think it should be, the way that is most helpful to you.


“Thriving in today’s marketplace frequently depends on making a transformation to become more agile.” ― Scott M.



Defining The Gap in Agile


Let’s look at the big picture for a second. I have goals. If you look at the image below, on the top right hand side, you will see, “Future State” which is also known as our goal. Hence, my future state is the goal that I’m after and goal, by definition, is a desired or future state; the way I want the world to be. However, I’m caught on the left hand side and on the left hand side, what you’ll see are the words, “Current State.” But I’d like to be over on the right hand side where it says, “Future State.” There’s a gap between these two items, where I want to be and where I am right now.




Basically, the definition of a problem is the gap between your desired state and your current state. All of agile and all of scrum is built on gap analysis. We look at what we want for the future, our current state, and creative ways to bridge the gap between the two. In essence, scrum itself is a problem-solving method. In the scrum guide, there is a section labeled, “Scrum Definition.” The first line says, “Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.” In other words, it’s a framework for problem-solving. Once we understand this, we can go deeper into what scrum@scale is about.


Scrum@Scale at Work in Performance Management


Scrum was designed for either one team or a small group of teams. It’s a way for the team, or a small group of teams, to conduct problem-solving. Scrum@scale is a framework that says whatever we are trying to accomplish is going to take many teams, teams of teams (of teams). If we’re trying to get teams (of teams) of people to coordinate and work together we need a communication mechanism in order to have proper communication for coordination. This is what scrum@scale framework provides. When we have communication, often what happens is that we need to have common mechanisms to make sure we’re aligned to obtain the same outcome; the benefit of using scrum@scale. Then again, the main benefit is alignment that needs to take place. Let’s talk about how we make this happen.


“Team performance is directly proportional to team stability. Focus on building and maintaining a stable team. Stability reduces friction and increases credibility and confidence.” ― Salil Jha



Defining Vision in Agile Performance Management


Typically, with a corporation or any big organization that is a government nonprofit, they each have a vision (“Future State”). That version can be anywhere from ten years, more or less, in the future. When we look at our future state, the goal is normally ten years out, “Here’s what our situation should look like in 10 years.” Everything in agile and scrum is built on looking at that vision and then decomposing it into smaller, more manageable pieces.

At this point, I have my vision of ten years out but I might also accompany something we call “strategic goals,” and that means we look five years out. Therefore, we’ll take down the vision and ask ourselves what aspects can be accomplished in five years and those things become our strategic goals. Although, we may break the vision down even further to see what we can accomplish in three years; corporations typically call these strategic objectives.


  • What can we accomplish in a year? That’s an initiative.

  • What can I do in a quarter? Sometimes we call those quarterly goals or features.


Again, we’re breaking these big things down from our vision into smaller, more manageable pieces. This is the basis of what we do in Agile and Scrum.




The context for everything that we do should be a goal of a future state we’re trying to accomplish in our organizations. Yet, if I asked you to break down your goal right now could you? It depends on how much time you spend in your organization discussing what your goals are. Most organizations only spend about 5% - 10% of their time at work discussing what the vision or goal is. Most of our time should be spent making sure we know what the goals are. In fact, the more important something is, the more time should be spent discussing the goals. Here’s the deal, someone who works in sales will most likely spend 75% of their time discussing the goal, why is this? For most organizations, if we aren’t bringing in revenue through sales, we will fold in less than six months because revenue is such an important thing. Almost all sales organizations are goal focused, they’re target focused.

I would go as far as to say sales naturally adopts agile principles before anyone else (other than marketing) because if they don’t they will fold. This pertains to gap analysis, we need a certain amount of revenue or we’ll go out of business. Hence, it's a sales job to figure out how to get the revenue.


  • What revenue do we (the sales team) want? Which is the future state.

  • How much revenue do we have right now? Which is their current state.

  • The gap in between these two states is our problem. How do we fix it?


Most sales team members are compensated according to the revenue they bring in. They are rewarded instead of being incentivized to constantly adapt to keep solving the problem between the desired state and the current state.


“By adopting an agile mindset and providing improved engagement, collaboration, transparency, and adaptability via Scrum's values, roles, events, and artifacts, the results were excellent.” ― Scott M. Graffius


8 views0 comments