The Scrum Master and Product Owner as leadership partners

After a recent large organizational change that resulted in a number of new teams formed, a product owner (PO) approached me looking for some help. He said, “I don’t think my new Scrum Master is doing their job and I’m now carrying the entire team, do we have a job description we can look at?”

I can already imagine how a version of me from a previous life would have responded, “yes of course let’s look at the job description and see where the SM is falling short of their roles and responsibilities”. But as I considered my response, my first thought was that focusing our attention on roles and job descriptions was a doomed route to failure. Pouring our energy there would likely just extend the pain the PO, and likely SM, were going through.

Sure we have an SM job description in our organization, and it clearly documents how the SM provides service to the organization, team and PO. But reviewing this with the seasoned SM didn’t really make sense to me; they were very well aware of the content of the job description and what was expected of them.

At the same time that this was happening, another newly paired Scrum Master asked for my help regarding their PO. From their perspective the PO was “suffocating” the team. The PO was directing the team in many aspects of the sprint that they felt was stepping beyond their role. “I don’t think the PO knows their role, maybe you can help me get them some training?” was the SMs concluding comment.

Over the course of the next few weeks this scenario played out again through more POs and SMs sharing similar challenges. Surely this was not a sudden epidemic of previously performing individuals who now needed to be reminded of what their job was?

Recognizing the impact of change

A common pattern was emerging from all of this, change was occurring and each individual was relying on, and to some degree expecting, old patterns to continue to work with their new situation. Their old way of working in Scrum seemed to work very well; so it was everyone else around them that was not meeting expectations.

The core issue however was that change was not being fully confronted: the product was different, the team competencies were different, the stakeholders were different, the expectations were different and finally the team dynamic was different all the way down to the relationship between the SM and PO.

Scrum as a form of Change Management

I looked for the solution from Scrum itself, at its heart a method for teams to use to adapt to and thrive with change. Was there enough transparency, inspection and adaptation going on between the SMs and POs in these situations? I would argue, not enough.

A pattern was becoming clear: nobody was fully disclosing their challenges to the other, they hadn’t fully confronted and understood their new situation and hadn’t come up with new approaches that would improve things. Said another way, they hadn’t inspected their new circumstances sufficiently and transparently enough so that they could adapt their role to fit the new need.

One thing that many successful SMs and POs recognize is that they are both leaders dependent on each other, and for their teams to be successful they need to figure out how they will work together in partnership. It doesn’t matter whether the terms of that partnership gets hashed out over a few chats over coffee or through a facilitated chartering workshop. What matters is clarity around how you agree to work together as partners meeting some shared goal.

As an SM or PO, here are some sample questions whose answers you may wish to understand and align on:

  • Do we both understand and support the team’s mission and goals?
  • What are the product goals?
  • How can we best help the team achieve those goals?
  • Are there any conflicts between the team and product goals?
  • When our goals or methods are in conflict, how will we resolve them?
  • In what ways will I be supporting your success as an SM/PO?
  • How will we keep each other informed and engaged?
  • Should we have a peer/subordinate/other relationship?

So if you are an SM or PO, and it’s unclear to you on the answers to some of these questions, you may just want to tap your leadership partner on the shoulder and say “let’s talk”.

[EDITOR’S NOTE: Martin Aziz is a first-time contributor to Agile Advice – please welcome him in the comments.  And let us know if you are interested in contributing.]

Please share!

If Your Up-Front Planning is Measured in Weeks, Then a Lean Startup is Going to Eat Your Lunch

Title inspired by Michael James…see below.

One of the most powerful assumptions built in to Agile methods is that we learn by doing — that our learning, our planning, our problem-solving, and ability to mitigate risk is enhanced when planning is performed inline with active development and in the context of deliberate experimentation.  Scrum, for example, is based on empirical process control theory which means that we make decisions based on what is known.

One of the most common pitfalls we see among organizations trying to “adopt” Agile is excessive pre-planning — their assumption being that we can decide by planning, learn by planning, or mitigate risk by planning.  This sometimes manifests as an anti-pattern that people call “Sprint Zero” — a signal that an organization misunderstands Agile methods fundamentally.  More importantly, a signal that the organization may incorrectly perceive Software Engineering — or any team-based work — as predictable and repetitive rather than the complex, creative endeavor that it is.

If your organization injects a “Sprint Zero” or a planning phase (that is measured in weeks rather than days or hours) ahead of the creation/development of real product, then these two posts are of interest to you:

Please share!

Question: Product Owner and Technical Debt

Question from Meredith:

As a product owner, what are the best ways to record technical debt and what are some approaches to prioritizing that work amid the continuous delivery of working software?


Hi Meredith! This is an interesting question. I’ll start by answering the second part of your question first.  The two most common ways of handling technical debt, quality debt and legacy debt are:

  1. Fix as you go. The Scrum Team works on new PBIs every Sprint, but every time a PBI touches a technical, quality or legacy debt area, the team fixes “just enough” to make the PBI implementation have no debt.  This means that refactoring and the creation of automated tests (usually through TDD) are done on the parts of the product/system that have the problems.
  2. Allocate a percentage. In this scenario, the Scrum Team reduces its velocity (sometimes significantly) to allow for time to deal with the technical, quality and legacy issues. This reduction could be adjusted every Sprint, but is usually consistent for several Sprints in a row.

In both approaches, the business is paying for the debt accumulated, and the cost includes an “interest” fee.  In other words, the sooner you fix technical, quality and legacy debt, the less it costs.  This approach to thinking about your product/system is essential for long-term sustainability.  One organization I worked with took three years working on their system to clean it up without being able to add any new features!  Don’t let your system get to that point.

Now to the first part of your question…

As a Product Owner, you shouldn’t really be making decisions about this cleanup work. Your authority is limited to the Product Backlog which should not include technical items. The only grey area here is with defects which may be hard to classify as either fully business or fully technical. But technical design, duplication of code, technical defects, and legacy code all are under the full authority of the Scrum Development Team. Practically, this means that every Sprint the team has the authority to choose however few PBIs they feel they can take while considering the technical state of the product/system.  We trust and respect the team to make wise decisions.

Therefore, your main job as a Product Owner is to provide the team with as much information as possible about the business consequences of the work they are doing.  With strong communication and collaboration about this aspect of their work, the technical members of your team can make good trade-off decisions, and balance the need for new features with the need to clean up previous compromises in quality.

A final note: in order for this to work well, it is critical that the team not be pushed to further sacrifice quality and that they are given the support to learn the techniques and skills to create debt-free code.  (You might consider sending someone to our CSD training to learn these techniques and skills.)

Using these techniques, I have been able to help teams get very close to defect-free software deliveries (defect rates of 1 or 2 in production per year!)

Let me know in the comments if you would like any further clarification.

Please share!

Link: It’s Time to Kill Performance Reviews

For many years, folks in the Agile community have been recommending that performance reviews be eliminated from the corporate world.  In 2005 while coaching at Capital One, I remember many discussions on the awfulness of performance reviews.  This was really my first understanding of the depth of culture change required to be Agile.

Now, this concept of eliminating performance reviews is gaining traction outside the Agile environment.  Here is a great LinkedIn Pulse post by Liz Ryan in which she explains in depth about killing performance reviews.

From her article:

A little voice in the back of my brain nagged at me: “Despite your efforts to make them more compassionate and less uncomfortable for everyone, performance reviews are stupid from the get-go, Liz!

“How does one human being get to evaluate another one, when their personalities and perspectives may be radically different?

Consider using other techniques to help with improvement efforts among your staff.  Lean has Kaizen.  Agile has Retrospectives.

Real Agility means that learning is inherent in the culture of an organization.  Performance reviews establish extrinsic motivators for learning… and all the research points to the idea that learning is much more powerful when it is intrinsically motivated.

Consider some other tools that might help your team to work more effectively, while maintaining intrinsic motivation:

Finally, consider that, at least in Scrum, the concept of a self-organizing, self-managing team makes it very difficult to do performance reviews.  It is hard to apportion “blame” or “praise” to individuals.  Each team member is dynamically deciding what to do based on the needs of the team, their own skills, and their interest.  Team members are often collaborating to solve problems and get work done.  Traditional roles with complex RACI definitions are melted away.  Performance reviews are very difficult under these circumstances.

Please share!

The Daily Goal

When my Scrum team first proposed trying mobbing I wasn’t sure what to expect. No one on the team (including myself) was an expert. I reserved judgment and watched a few sprints. I stayed silent when the same team decided to skip the tasking out portion of planning and simply pulled in enough stories to fulfill their Sprint goal.

After a couple of sprints it became obvious that there were a number of pros; the team was engaged and aligned. They responded as a consistent, unified voice at Sprint Review and Retro. Planning went a lot faster as the team no longer wrote out all their tasks and didn’t have to copy all of them into Jira.

In particular, the Daily Standup’s usual agenda of “what did you do yesterday? what are you doing today? what are you doing tomorrow?” became redundant. And this had me thinking; ‘maybe the team didn’t need a stand up anymore? What’s the point?”

Then, one of the team members introduced me to the concept of the daily goal and I watched as he walked the team thru it. I thought this made a lot of sense and so did the team. We kept up the practice. Some days the team would forget about it or be too tired to bother. I noticed on those days the team wouldn’t be as clear on what they were working on or how to align on a particular challenge. I also noticed that the Stand Up the next day would be more fragmented and meander a bit. They would forget to communicate to one another and look at me as their Scrum Master expectedly, wanting me to drive it.

I started to coach the team back to their daily goal practice and reminded them this Stand Up was for them to align on the work ahead for the day. This became more important as the team divided up into mini mobs or pairs and were no longer one big mob.

I find the Daily Goal useful for a number of reasons. Instead of tasking out the work a week in advance, they decide how to approach the work on a daily basis that takes into account any day to day changes that have happened. Planning goes a lot faster now that we’re not tasking out all the work in advance. The team stays focused on a daily basis as opposed to at just Planning. They write their daily goal on their Scrum Board making it visible to anyone on the floor what their focus is for the day. Even better, the daily stand up as renewed purpose and the dialogue is more interactive.

Here are some examples of our Daily Goals:

  • Refactor Story 1
  • Coordinate with outside team members to align on test strategy
  • Complete happy path for Story 3
  • And sometimes it is as simple as “Complete story 4”

I hope to continue the practice and frankly, it’s fun! Achieving short time goals is motivating and brings a sense of accomplishment. I highly recommend it. Let me know your thoughts and if you’re trying this technique let me know how it’s working out for your team.

[EDITOR’S NOTE: Alexandra Dragon is a first-time contributor to Agile Advice – please welcome her in the comments.  And let us know if you are interested in contributing.]

Please share!

The Real Daily Scrum

On many occasions, I have observed “Scrum Masters” and even “Product Owners” attempting to drive what they understand to be the Daily Scrum. Just this morning, I witnessed a “Daily Scrum” in which a “Product Owner” gave the team a bunch of program updates and made sure that each team member had tasks to work on for the day. Then, the PO “wrapped up” the meeting and left the team to get to the work. I then stayed and observed what the team did next. They actually stayed together to discuss the work and figure out how they were going to organize themselves for the day. I then went over to the Product Owner and whispered in her ear that the team was now doing the real Daily Scrum. She said “Oh,” and promptly walked over to find out what was going on. I then observed her from a distance nodding her head several times while appearing to understand what the team was talking about. I’m not sure if she understood or not, but that’s irrelevant. The point is that the Daily Scrum is for the Development Team to inspect and adapt its progress towards the Sprint Goal and decide how it will self-organize for the coming day. If the Development Team decides as a result of the Daily Scrum that it needs to re-negotiate any previously forcasted functionality with the Product Owner, then that conversation can certainly happen at that time.

Please share!

What Do Strong Companies Hire For – Skills, or “Something Else?”

Perhaps you’ve experienced this…You go all revved up to a job interview with your beautiful resume in hand outlining all your accomplishments, believing you have all the right training, skills and experience…but you’re not chosen for the position. You cannot understand why.

Advertising guru and author, Simon Sinek, explains: “Weak companies hire the right experience to do the job. Strong companies hire the right person to join their team.”

Teamwork is becoming the hallmark of most successful businesses and organizations. We have entered an age where cooperation and working together is a vital necessity. No longer is the individual star performer going to do it for an organization. That’s not enough. Everyone needs to have the same vision, the same values, the same feeling of being valued. The demands on companies is just too great for one or two individuals to lead the way. Everyone must be a leader.

How can one show a potential employer that you are a team player? That you have great consultative and cooperative skills? That you’re willing to learn from everyone around you? Is this something that can be reflected in your personality?

“A recent international study surveyed more than 500 business leaders and asked them what sets great employees apart. The researchers wanted to know why some people are more successful than others at work, and the answers were surprising; leaders chose “personality” as the leading reason. Notably, 78% of leaders said personality sets great employees apart, more than cultural fit (53%) and even an employee’s skills (39%).”

Forbes Magazine has published online articles about the hiring process which are fairly old-school, even wishy-washy. Writers talk about knowing the clear skill-sets a company is looking for, and having a detailed scorecard that defines the performance objectives for the position. They also discuss qualities of behaviour, but do not define behaviour in any specific way. Their expertise falls short in looking at personality, team-building qualities, and desire to learn, change and adapt.

Agile is the leading team-oriented methodology being adopted by the best and the brightest organizations in the world, such as Google and Apple. Agile teaches its participants to reflect, act and learn.

This is a kind of life-agility that’s needed in every realm we function in, whether as spouses, parents, employees, or members of our communities.

What do you hire for?

Please share!

9 Agile Estimation Techniques

Many people have used a variation of Planning Poker to do Agile estimation.  Here is a reference of 9 different Agile estimation techniques for different circumstances.  I have seen all of these techniques work in practice, except one.  Try a new one each Sprint!

Planning Poker

Participants use specially-numbered playing cards to vote for an estimate of an item.  Voting repeats with discussion until all votes are unanimous.  There are lots of minor variations on Planning Poker.  Good technique to estimate a very small number of items (2 to 10).

The Bucket System

Using the same sequence as Planning Poker, a group or a team estimate items by placing them in “buckets”.  The Bucket System is a much faster Agile estimation technique than Planning Poker because there is a “divide-and-conquer” phase.  The Bucket System can also be used with larger groups than Planning Poker and with very large numbers of items to be estimated (50 to 500).


For super-fast Agile estimation, the items to be estimated are simply placed by the group in one of three categories: big, uncertain and small.  The group starts by discussing a few together, and then, like the Bucket System, uses divide-and-conquer to go through the rest of the items.

TFB / NFC / 1 (Sprint)

This Agile estimation technique is similar to Big/Uncertain/Small but puts a specific “size” into the mix, namely 1 Sprint.  The categories are “Too F-ing Big”, “No F-ing Clue” and “1” Sprint (or less).  I learned this one recently from someone in one of my CSPO classes.

Dot Voting

Dot voting is usually considered a decision-making tool, not an Agile estimation technique.  However, for estimating small numbers of items, dot voting can be a super-simple and effective technique.  Each person gets a small number of “dots” and uses them as votes to indicate the size of an item; more dots means bigger.

T-Shirt Sizes

Items are categorized into t-shirt sizes: XS, S, M, L, XL.  The sizes can, if needed, be given numerical values after the estimation is done.  This is a very informal technique, and can be used quickly with a large number of items.  Usually, the decisions about the size are based on open, collaborative discussion, possibly with the occasional vote to break a stalemate.  There is a brief description of T-Shirt Sizes here.

Affinity Mapping

Items are grouped by similarity – where similarity is some dimension that needs to be estimated.  This is usually a very physical activity and requires a relatively small number of items (20 to 50 is a pretty good range).  The groupings are then associated with numerical estimates if desired.

Ordering Protocol

Items are placed in a random order on a scale labeled simply “low” to “high”.  Each person participating takes turns making a “move”.  A move involves one of the following actions: change the position of an item by one spot lower or one spot higher, talking about an item, or passing.  If everyone passes, the ordering is done.  The Challenge, Estimate, Override and the Relative Mass Valuation methods are variations on the ordering protocol.

Divide until Maximum Size or Less

The group decides on a maximum size for items (e.g. 1 person-day of effort).  Each item is discussed to determine if it is already that size or less.  If the item is larger than the maximum size, then the group breaks the item into sub-items and repeats the process with the sub-items.  This continues until all items are in the allowed size range.

Principles of Agile Estimation

Agile estimation techniques are collaborative.  All appropriate people are included in the process.  For example the whole Scrum team participates in estimating effort of Product Backlog Items.  Collaborative techniques are also designed so that it is impossible to blame someone for an incorrect estimate: there is no way to trace who estimated what.

Agile estimation techniques are designed to be fast (-er than traditional techniques) and deliberately trade off accuracy.  We are not trying to learn to predict the future… or get better at estimation. Instead, we recognize that estimation is a non-value added activity and minimize it as much as possible.

Most Agile estimation techniques use relative units.  This means that we don’t try to estimate dollars or days directly.  Instead, we use “points” or even qualitative labels and simply compare the items we are estimating to each other.  This takes advantage of the human capacity to compare things to each other and avoids our difficulty in comparing something to an abstract concept (such as dollars or days).

Check out my recent “Agile Planning in a Nutshell” article.

What Other Agile Estimation Methods Are There?  Please let me know in the comments and feel free to include a link!

Please share!

Insight from a new Scrum Master

I recently had the pleasure of doing some coaching with someone who is new to Scrum and has taking on the role of the Scrum Master as part of a team of teachers.

Edwin Portfillo - Scrum Master
Edwin Portillo  – (c) Copyright Edwin Portillo, 2015

Last week, I unexpectedly received this email from him. I wanted to share it as a thought for other new Scrum Masters in the making…..

I’m beginning to understand that being a SM involves me not coercing people into following a specific task but guiding them into  deciding as a group what must be done for the team to move efficiently.

“We never want to be in a position where 100% of the work is 80% done.

On the other hand, if 80% of the work is 100% done, you have a qualified success.”

 Edwin Portillo
High School teacher (Scrum Master – The Teaching Team)
Hope High School / Blueprint Education

As you can see, Edwin has come a long way already in his understanding of the role. Please feel free to share your Positive comments with Edwin if you wish.  I’m sure he’ll appreciate it :->

I’ll start…  Thanks Edwin for taking the time to really think about how your actions should impact your team. Thank you for sharing your ideas with new Scrum Masters in such a simple and effective way.

Mike Caspar
Passionate About Agile


Scrum –
Hope High School –
Blueprint Education –

Please share!