Try This

The Product Owner is never around
Experiment 1 - Columbo?
Play the detective a little. Find out why the Product Owner isn’t around. Don’t just make assumptions. Usually the best way to find out is to ask probing questions.  Asking them where they are all day probably won’t get you the results you want.
Experiment 2 - Take your seat
Why isn’t the Product Owner sitting with the team? Experience has found, and popular Scrum coaching promotes, Product Owners sitting with teams, because they become more involved and the development misses fewer Acceptance Criteria. This promotes a solid team spirit and allows the team to see more into the business side of things.
Experiment 3 - We can't do this without you
Explain to the Product Owner that Scrum only really works well if the Product Owner is involved daily with the team.  We knew it back when the Agile Manifesto was written, and we know it even more now.  It says right in the Principles behind the Manifesto…

Business people and developers must work 
together daily throughout the project.

The Team does’t agree with the answers the Product Owner is giving them
Experiment 1 - We could fill a warehouse with what you don't know
Please understand that regardless of agreement, decisions need to be made. There’s a world of business going on all the time, and those who know what’s going on in that realm don’t have the time nor the energy to explain everything.

There’s not a lot of value in getting bent out of shape over decisions that the Product Owner makes.  It’s their job to know the customers and the the customers’ requests better than anyone.  Trust that they have the best intentions for the customer and the product in mind when they make their decisions. Just like they trust the Development Team to make the best development decisions, you need to trust them.

Experiment 2 - Flip the Script
Let’s turn things around. Do you want the Product Owner questioning every decision you make? You were hired to do a job that you are excellent at doing. You were hired because you could be trusted to make the decisions relevant to your domain. If you are adamant that the Product Owner is making poor decisions, or not consulting the team on all decisions, and you need to be involved in the decisions-making process, be prepared to invite the Product Owner, and everyone else, into a discussion when you need to make decisions in your domain.
Experiment 3 - Talk it out
Bring this up at a Retrospective.  Voice your opinion or observation.  Discuss with the entire Scrum Team (remember, the Product Owner is part of the Scrum Team).  Please remember the Prime Directive, though.

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

The ScrumMaster is never around
Experiment 1 - What's really going on here?
Not unlike the same problem with the Product Owner not being present, find out what’s going on.  Why isn’t the ScrumMaster around? Have an honest conversation about your concerns.  Also, you could bring this up at the next Retrospective and get input from the entire team.  You might be surprised at the results.
Experiment 2 - You get what you pay for
If the organization is forcing ScrumMasters to take on more than one team, well, expect this result.

Everyone’s job in Agile, not just Scrum or Kanban, is to reduce waste while increasing quality. Misunderstandings about the demands of true ScrumMaster work abound. So, when we try to Lean out an organization, and we don’t really understand what a ScrumMaster does, we naturally try to overload the people filling this role.

Be the bearer of truth and try to educate the organization about the dangers of having servant-leaders split their time and focus between several teams.

Experiment 3 - Covert Ops
While we might like to sometimes say that all Team Members are empowered to question everything, sometimes ScrumMasters have a secret reason for the things they do.

Much like parents raising children, part of the ScrumMaster role is to coach the team into self-management, self-organization, and full empowerment.  We do that with our children?  Yeah, actually we do.  We teach them how to be self-sufficient adults with the education to fuel their career, the drive to succeed, and the creativity to engage with any kind of work in a fun and productive way.

Parents don’t always explain all the details to children (though they do so more now than ever).  Likewise, you’ll find ScrumMasters, at some point, trying to let the team fly on their own for a while, to see how they cope with more responsibility.  Eventually, the ScrumMaster isn’t needed, and they leave to go help another team.

(This is only one scenario where the ScrumMaster’s absence is intentional. There are more.)

Team Members disappear for hours at a time
Experiment 1 - Find Them!
Go get them and bring them back to the team area.  All work should be done collaboratively and in the team space.
Experiment 2 - Maybe the dingo ate your baby
Before you worry about where they are, or how often they are gone, maybe you should worry about why they aren’t with the team.  Is someone forcing them away? Is the work they are doing so boring they have to get away from the rest of the team?  If it’s just one person, are they having personal-life problems that are interfering in their work?

Finding out why they aren’t there is probably the most impactful thing you can do, while not damaging a relationship, and addressing this problem.

Experiment 3 - Follow that car!
Don’t feel like asking them where they are going? Follow them. Passive aggressively figure out what’s up by following them.  If they turn around and see you, quickly turn your back and look at your phone, or your watch, or some papers you are carrying.  Make it look really suspicious.  They’ll ask you what’s up.  Then tell them you “want in.”

True Story: I did this and found that half of the team felt like outsiders due to cultural differences.  They would spend a large part of every afternoon down the block at a fancy coffee place (not Starbucks, I said ‘fancy’.)  When I found out what was up, I grabbed a friend the next day and got there before them.  I called them over to our table and found out they sit around for about an hour each day talking about work, the team’s work, and new things (like new technologies) they’ve learned (or learned about).

This is important stuff for many reasons.  These discussions can REALLY help out teams that are struggling.  Not just the new technologies stuff.  But the fact that they felt like cultural outsiders.  Teams need to talk about these differences, and how to weave them into the rest of the team.

The Team Members aren’t swarming around backlog items
Experiment 1 - Why Not?
Has anyone made it clear that limiting the Work In Progress (Limiting WIP) actually tends to increase quality and speed?  Why not?
Experiment 2 - Who cares?
Stop badgering the team about how they address the work.  They’ll figure out, eventually, what works for them.
Experiment 3 - Stop complaining and coach them
A good coach knows when to step in and make suggestions for growth, and when to stand back and let the team learn and grow on their own.  Figuring that out, as a young coach, is difficult.

Pick your moment well, and suggestions like these carefully, thoughtfully and well-informed.  There are few things as damaging to your credibility as picking the time and place well, but not knowing exactly how to introduce an improvement suggestion.  Great suggestions like these are all-too-often shot down just because they weren’t delivered well.

When suggesting things that are semi-controversial, be sure to let the team know it’s ultimately their decision when to implement new things, how to do it, and that you trust them to make the right decisions along the way.

All of the work is In Progress all the time
Experiment 1 - Look up
Look at the ‘swarming’ question just above this one.  Read all of of the answers there.  If you still have questions, come back here.
Experiment 2 - Cover that up!
In Sprint Planning Part 2, have the team arrange the Sprint Backlog Items according to the order in which they thing they’re going to start working on them.  Then, take a large sheet of paper and cover up everything below a certain point on the board.

For example, if the team decides they should only have 3 items in progress (WIP Limit = 3) at any time, cover up everything on the board except the top 3 items.  When the team completes one of the Sprint Backlog Items, lower the paper to reveal another item.

None of the work is Done until the last day of the Sprint
Experiment 1 - Be firm
Look at the 2 questions above.  They deal with starting too much work at once.  Or at least, they have to do with having too much WIP at one time.  Look at the answers and try them out.  If you still have the same problem, you’re not being to firm in your dedication to following the team’s own rules.

Why decide to try an experiment, if you can’t follow the protocol that the experiment is based on?  Be firm.  If the team says 3 item In Progress maximum, then hold them to it.  In Progress means not Done!  If they can’t get something to Done, then they can’t start something new.

Experiment 2 - Tough Love
Continuing on the theme of Experiment 1, above, use some Tough Love on the team.  Hold them to their commitment of seeing things through to Done, once they’ve been started.

If you don’t let them start new things, and they absolutely cannot keep working on their current item, because it’s blocked, then you all have a new job.  It’s called Impediment Removal.  And if the Impediment cannot be removed by the ScrumMaster or the Team Members, then it behooves your chain of leadership to help you get the impediment removed, because the team isn’t working until it is removed.

Now that’s Tough Love!  It’s an extreme stance, but sometimes you have to go to extremes to get good results from leadership.

The developers are ‘throwing work over the wall’ to the testers
Experiment 1 - You shouldn't be throwing anything with that shoulder of yours
Stop throwing stuff.  It’s not nice.  The biggest problem with new uncoached Scrum teams is that they do a lot of things that are not nice.
Experiment 2 - Bit off more than you could chew, eh?
You’ve got more going on here than you are letting on (probably).  Or, you’re just really bugged (pun intended) by this and need to vent.

If your developers are throwing crappy code at the testers and expecting them to put up with it, you have a team that doesn’t hold one of the Scrum Values in very high regard.  Namely, Respect.

I say you’ve got more going on here, because your team really should be working hand-in-hand with QA to try out small sections of code constantly.  Write a failing test.  Write code to make the test past.  Refactor the code so it meets coding standards, is more elegant, is more bullet-proof, and integrates well. Rinse and Repeat.  QA is there to tell you what a good test is, or even to write the test and run it.  But they should be in it from the first line of written code, through to the last. No more throwing terrible code over a wall and forgetting about it.

Experiment 3 - Battlefield - Own it!
Your team should own their own code.  No idea what I mean huh?

What if the team had to fix every one of the defects the results from their own code?  Past, present, and future.  Do you think they’d start being a little more careful about how they write their code?  A little more diligent about writing strong code?

Think about this battlefield example: If the team had to clear a field of land mines, but no one would cross the field until your team proved it was safe by walking every inch of it first, do you think they’d try REALLY hard to make sure they found every mine?  Or would they just clear a path wide enough so they knew they could get across (especially if they ran really fast)?

Treat your code base like the mine field, because it’s very similar.  There are catastrophic things that can happen if you aren’t thorough.

The developers deliver everything to QA on the last day of the Sprint
Experiment 1 - That's just stupid!

Why would they do that?  That’s just dumb!

What if the testers find a defect in the code they received on the last day of the sprint?  What is they found a LOT of defects?

What if there was a holiday on the last day of the sprint?

What if the testers went on strike?  That may be a stretch.  What if they all got sic on the last day of the sprint?

It doesn’t make a lot of sense to dump a ton of work on the testers on the last day of the sprint.  Because nothing is Done until it passes, right?  So if every piece of work had one little bug in it, the likelihood of a ton of things not being Done is pretty high.

Experiment 2 - Turnabout is fair play
Tell the testers to take just as long testing as the developer did developing.  See what happens. Record the results. Do better next time.
Experiment 3 - Been there. Done that. Got the t-shirt.
Yeah, we’ve all been fortunate enough to see this before.  And, we’ve all lived through it.

The problem is, some people still do this.  It’s not fair.  It’s disrespectful. And, it doesn’t benefit anyone.

Testers get blamed for the un-Done work. Developers lose out on learning new skills (testing). Analysts lose because they didn’t see it coming (or failed to stop it).  The ScrumMaster loses because they didn’t stop the team from taking on too much work.  The Product Owner loses because they have to answer to the sponsors/stakeholders as to why the Release just got pushed out.

Don’t do this.  We figured out ways (XP) to fix this decades ago.  Fix it!

Random Team Members keep getting pulled out of the Sprint for a ‘manager’s project’
Experiment 1 - Yeah... So, can you just stop that? Thanks...
This is old-school.  This particular manager will never change.  Just do what they say and live with it.  Right?

NO!  Stop thinking that way!  Right now!

Look, using Scrum to address the complex world of work is not obvious anymore.  When you were a child, before the public, and most private, school systems brainwashed experimentation-as-an-educational-tool out of you, it was just how you did stuff.  It’s how you built a fort or tree-house.  It’s how you learned to not cut your own hair.  It’s how you learned that fire was hot (and hot things hurt).  It’s how you learned to ride a bike / roller skates / skateboard / surf board.  You identified something to do.  You briefly thought about how to do it.  You tried something.  It either failed or succeeded.  You reflected on that experience, and changed your behavior accordingly.

When we took our first job, more than likely, that sort experimentation and evolution way of thinking ceased.  It ceased for that manager too.  So, you should probably do the same thing for that manager that you did for the team and your stakeholders.  Explain how Scrum works.  Explain why Scrum works.  Explain, with emphasis, that one of the main things that keeps Scrum working is transparency.  If we don’t know what everyone is working on, we’ve broken Scrum.  If we haven’t planned for the work in the current Sprint, we’ve broken Scrum.  You get the picture.

Sometimes, simply doing a Scrum refresher, or doing some initial training with managers will solve these problems.

Experiment 2 - Introducing, the Product Owner!!!
Take the Manager to the Product Owner.  If they’ve never met before, introduce them and explain the Product Owner’s role and responsibilities.  Include that the Scrum Team, together, agrees what to work on during each Sprint.  Subverting that process is an anti-pattern.  Do not forget to stress that making all of the team’s work visible is a big part of Scrum.
The Project Manager keeps interrupting Team Members during the day, while they are working
Experiment 1 - No Projects, so no Project Managers!
We’re Product focused now.  Not Project focused.  So, we don’t need Project Managers.  We self-manage and self-organize.  It’s an insult to let Project Managers exert any type of power or authority over our work.

Get ’em out of here.

Experiment 2 - Hey, ScrumMaster!
Much like the interfering Manager being introduced to the Product Owner, introduce the Project Manager to the ScrumMaster.  No one should be bothering the team. Period. It’s the ScrumMaster’s responsibility to shield the team from interference like this.
Experiment 3 - Stupid is as stupid does
Project Managers do what Project Managers do.  In Scrum is there a role for Project Manager?  I’ll answer that for you, No, there isn’t.  Does that mean they can’t help a Scrum Team?  Also, No, they could possibly help.  Now the juicy question: How?

Project Managers generally get a bad rap from Agilists, and particularly in Scrum circles.  Let’s try and be a little more inclusive, ok?  Invite the PM into the team area to see how the team operates.  Invite them to one of the Daily Scrums.  Invite them to the Sprint Review and Sprint Planning meetings.  Obviously they would just be an observer in those meetings.

Now, armed with the experience of seeing all of the duties the Scrum Team has covered, invite the Project Manager to share what they think they can additionally bring to the table.  In general what we hear are administrative and conventional project management duties.  Most focus is usually around reporting the project status and allocating budget for the team.

Most of us don’t want to deal with budgeting for the team, so that’s usually OK, even though the point is generally moot (we can address that elsewhere), but reporting project status should REALLY be examined.  This interferes with the Product Owner’s domain.  The PO is responsible for keeping the stakeholders and sponsor informed about Release expectations and assistance they may be able to provide the team (impediment removal).  So, the PM may not really be needed anymore.

Again, don’t just dismiss the Project Manager as a nuisance.  They could possibly be providing value that is not readily apparent.  Do some investigation and see if there is a value-add in having a PM.

We would definitely collaborate more if the people who sit next to our cubicles didn’t complain about the noise so much
Experiment 1 - Go Away!
Take the team and go somewhere else.

This is usually easier if the work the team does is easily transportable.  If not, ask the complainers to go somewhere else.  Because, you guys need to talk!

Experiment 2 - Fight the System!
Normally, your physical environment is provided for you.  You don’t usually get to pick your team’s space.  But, did you just accept that from ‘the powers that be’?  Try to get a private space for your team, because they can get loud at times.

Ideally, you’ll want a space for the team to work individually and in small groups, a space for the team to gather around their Scrum Board, and a space for them to invite other people from the organization in and show everyone their product.

In my experience, a footprint of 200sqft is sufficient.  But, I’ve been on a team that operated in as little as 90sqft for 6 months straight (we got to know each other REALLY well).

Using Jira is mandatory, so we’re not using a physical board
Experiment 1 - LAME!

 Biggest cop-out ever!

If you think that’s a good reason to NOT use a physical Scrum Board, please let me know, so we never have to work together.

Experiment 2 - Reason? Or excuse?

Let’s be honest.  That not a ‘reason’ for not using a physical Scrum Board.  It’s your ‘excuse’, right?  You are relieved that you don’t HAVE to use a physical board, so you are using Jira as an excuse not to create one.

The difference is that the evidence for using a physical board is irrefutable at this point.  And most very successful Scrum teams use both an electronic board and a physical board.

The physical board is a low cost, low barrier to entry Information Radiator.  This Information Radiator keeps people who would like to interrupt team members, from interrupting them.  Sometimes.  Other Information Radiators, if kept up-to-date, can keep almost all of the rest of them away.

The physical board also serves as a reminder for team members to focus on the work during the Daily Scrum.


Updating the physical board is pointless. We all update Jira in real time.
Experiment 1 - What Makes Sense?

Does it make sense to have 2 boards (1 electronic, 1 physical)?  Does it make sense to update both boards in real-time, so they always reflect reality?  Answering questions like these for yourself will usually lead you to the right action to take.

Experiment 2 - Reduce Waste
If it’s wasteful to have 2 boards, remove one.  If it’s wasteful to stop updating the board(s), stop it.  If you are wasting space by keeping a physical board that no one every looks at or uses, get rid of it.  Reduce the waste in your system, and in your teams’ area.
Experiment 3 - But, you said...

You said, in your Team Working Agreement, that you would keep it up to date.  So, either do it, or update your Team Working Agreement.


Experiment 4 - Who/What is your Physical Board For?
Seriously, who is the physical board for?  Is it for your team?  Is it for management?  Is it for other teams with interdependencies?  Is it a deterrent for people who may interrupt you or other team members?  Is it helpful for team members to physically move tickets from one state to another across the board?

What was the original intent of having the board? Did you create it just because someone told you to? Are you trying to get the team to visualize their own work? Is it for other people to know what’s being worked on, what’s next, and what’s done? Is it supposed to make the team look busy?

Don’t just answer these questions quickly or emotionally.  The honest answers will tell you something about your team and your system.  If you need to involve a true Scrum leader, get them involved in helping explain why these questions matter, before you take action.



It’s hard to get to consensus on estimates since we have to keep explaining Story Points to the new people on the team
Experiment 1 - Trim the fat

Cut the waste out of your system.  Stop re-explaining estimates to the team.  Explaining the same thing over and over is wasting your time.

Experiment 2 - Use Relative Sizing
Stop making the team think in terms of definite values.  I’m talking about Story Points.  When people assign a number to something, it tends to go, quickly, from an estimate to a precise.  Doesn’t sound right, does it?  That’s because it’s NOT right!  Don’t do it.  At least not yet.

In Relative Sizing, or Affinity Estimation as Lowell Lindstrom would put it, you line up all of your Product Backlog Items next to each other and quickly compare them to their neighbors.  Continually reposition them so the smaller items move to one end of the line, and the larger items to the opposite end.  Now start grouping them into approximate effort groups.  When you are done, you have several groupings of similarly sized Product Backlog Items.

You may, at this point, assign a common value to each of the PBI’s in each group.  You may be tempted to select a common estimation scale to express those values (Doubling or Fibonacci).

You’ve now quickly estimated the entire Product Backlog.  And you didn’t even talk about Story Points.

Experiment 3 - Stop Using Story Points
Stop using Story Points.  They probably aren’t helping you anyway.  You probably aren’t even using them right either.

Use abstract estimates like Woodland Animals, or facial hair.

Experiment 4 - Whatever happened to the good old days?

In the old days, Ideal Developer Days worked fine.  And Hours.  Whatever happened to estimating in hours?  Try estimating in lines of code (or code paths).  Estimate ROI and burdown to toward it.  Estimate the total cost of development, and burn that down.  Estimate the number of defects per lines of new code, and then estimate the number of hours needed to develop the stories in the sprint, and fix all the defects you expect.


Why do we need to be cross-trained? We have an Analysis team, a Dev Team, a UAT team, and a Deployment team.
Experiment 1 - Why are you asking about Scrum?
Whatever it is you are engaged in, it’s not Scrum.

Look, just because you work in short cycles, and you have meetings that coincide with the timings of Scrum events (you might even name them like Scrum events), it doesn’t mean you are using Scrum.

For Scrum, you are going to need people that can do analysis, design, development, testing, and deployment stuff.  All of it.  Ideally, you don’t just have one person for each skill either.  You’ll no doubt realize that cross-training your people is cost-effective, and makes it easier for them to talk to each other about the short and long-term future of the product.  It becomes easier to break up work into small, vertically sliced pieces, which can be demonstrated as working functionality to stakeholders periodically.

Experiment 2 - Then don't
Don’t do it.

See what happens.

Experiment 3 - Let's have a talk
Since you know that Scrum works best with teams of cross-trained developers, someone must have planted this idea in your head at some point.  Find that person, buy them a coffee (or beverage of their choice), and have a calm discussion about why Scrum favors those teams that are multi-skilled, and multi-trained.
Can we use Scrum during our UAT phase (or insert your favorite phase name)?
Experiment 1 - You aren't following, are you?

Scrum doesn’t live in a phase of development.  It exists in lieu of development phases.

Experiment 2 - Bundle and Save!

Combine all of your phases into a (if you MUST call it a phase) single phase called Product Development.  No, not just Development and Validation.  All of your phases.  Now, use Scrum and sprint through THAT!  You will save time, money, aggravation, and sanity.

Our SME is on vacation for a week. Should we all do analysis until she comes back?
Experiment 1 - While the mouse is away...

You know what they say…  While the mouse is away, the rest of the team will screw around.

Experiment 2 - SME's suck

Look, we’ve proven time and again that calling people out as SME’s is detrimental to the organizations health in so many ways.  Other workers feel like crap because of it.  It puts people up on pedestals and they get big giant heads that they can’t fit through a bathroom stall door (and then that becomes a whole other mess).  Tons of other problems.  Don’t go down the SME route.  Stop doing this to people.  Call everyone a Development Team Member (until we come up with a better name for everyone), and we’ll all be a lot happier for it.

Experiment 3 - Let's get to work, shall we?

Once, I was working at a well-known company with a tradition of fear and bloated hierarchy.  So much so that even the development teams had hierarchy within them.  When I started coaching them to use Scrum, that hierarchy remained, for a while.  Every day after the Daily Scrum, the team would literally line up behind the team SME and for up to two hours wait their turn while he told them how to do their job – one person at a time!  Are you kidding me (I screamed in my head)!  Several months prior, when he went on vacation, the team experienced a surge of new ideas and innovation.  When he came back, everything went back to normal.  Sad isn’t it?  The lesson, if you weren’t listening, is to get rid of your SME’s and give everyone the autonomy to work out their own solutions their own way.

We’ve been sprinting for ## months! When do we get to take a break?
Experiment 1 - What is a 'break'?

What?  A break?  You want a break?  You know who gets breaks?  School teachers and homeless people.  Well, maybe government workers too.  Oh, and maybe those western Europeans, they tend to take off every time the sun shines.  But, us?  We don’t take breaks!

Experiment 2 - This life ain't for us all

Look, no one (who knew what they were talking about) ever said that working on a Scrum Team was easy.  It’s hard.  It’s rewarding.  It’s challenging.  It’s fun.  And guess what?  It’s continuous.  As soon as one Sprint ends, another begins.  That’s the way it works.  No work happens outside of a Sprint, and all work done by the team is on the Sprint Backlog.  So, one Sprint after another, after another, after another…..  Get it?

Experiment 3 - Pace yourself

Yeah, these are called Sprints, but they are back-to-back-to-back, so it’s a marathon of short Sprints.  You work hard and get rewarded.  The thing is, you should not be working so hard that after any number of Sprints you feel so tired that you are energy-drained and just need to sit there for a few days throwing pencils at the ceiling tiles.  We call it, working at a sustainable pace.  Try it sometime.  It’s worth it.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

The Product Owner owns 36 apps, so she’s not always available for us
Experiment 1 - Here We Go Again...

OK, for the last time, this has to do with FOCUS and a Project-centric vs Product-centric mindset.  We usually end up with one person owning 36 products, because we either do not know what a product really is (ill-defined products), or we do not care enough about our product(s) to have someone assigned to focus on them long term.  Don’t bothering telling me about your company’s crazy budgeting model, I’ve heard it before.  It comes down to these two things.  The project-centrism thing creeps in where we overload a ton of work onto one persona nd tell them to split their time.  That’s just idiocy.  We all know about how detrimental it is to advocate context switching.  It’s no different when we are talking about Product Owners. 

Experiment 2 - Hire more Product Owners

Stop telling well-intentioned Product Owners to do the job of multiple Product Owners.  All of the product will suffer if the PO must split their time.

Do some Product Roadmapping

Invest some time and energy into mapping out products when the Product Owners is splitting their time so much.  When you see how much they need to delay things, because they can’t give all of the Scrum Teams their attention, you’ll see how obvious a decision it is to stop this behavior.  Until then, enjoy the chaos!

How do we account for [fill-in-the-blank] meetings on our Sprint Backlog?
Experiment 1 - Make Them Part of the Sprint, DUH!

Sheesh! IS it that hard to figure out?  Just add the meetings to the Sprint Backlog, estimate how much time they will consume of the aggregate time in the Sprint, and make that time their estimate.  Then subtract that time from the total time left in the Sprint and move on with Sprint Planning as normal.

Experiment 2 - NEXT!

Meetings are not part of the product that you are building, so they do not belong in the Sprint Backlog. NEXT!

The team is just not estimating right
Experiment 1 - What Does That Even Mean???

It seems that you have some goal or preconceived notion that there is a single correct way to estimate.  Pray tell, what is it, so we may all be enlightened?

Have you tried telling your team that your way of estimating is the right way?  How did they 

Have you asked the team why they estimate the way they do?

Experiment 2 - Are you (the entire team) keeping track?

Are you keeping track of your estimation history?

Are you seeing patterns in the teams estimation?

Are similar type items in the product backlog estimated similarly?

If not, why not?

Our estimates need to be more precise
Experiment 1 - Read the Previous Problem First

Seriously, I’m not even being my old sarcastic self at this point. Estimates are called ‘ESTIMATES’ because they are a rough idea of how long, or how much effort, something is going to take to complete it.  Estimates are not precise – else, they be called ‘PRECISES’ (and that just sounds dumb).

Experiment 2 - Still Here?

You’re still here and want MORE advice?

OK, look, estimates are how a team eventually understands how much effort it will take to get some amount of work done. In the future (read those 3 words again and again until you truly understand them), the team (the Development Team mostly) will come to understand how much time it will take to complete any amount of work, with their current skillsets, enginuity, tools, etc. they have. They’ll likely never be completly precise about it, but they’ll get closer and closer over time.  

BTW, I hope it’s the Development Team that is concerned about their own estimates, and not someone else.  If it’s someone else, tell them to F Off!

We can’t possibly get anything done in a 2-week timebox!
Experiment 1 - Nothing?!


You mean it’s not humanly possible to get anything at all done?

Experiment 2 - Smaller is better

What is the minimum viable something that we could get done and demonstrate to stakeholders?

Challenge that mindset (the nothing)!

You don’t have to do EVERYTHING all in one fail swoop.  Break things down and do a little now and a little later.

Get a minimum viable something done.  And build on that sprint after sprint until you see where your failure point is.

Experiment 3 - Ever heard of TDD?

Using Engineering Practices like Test Driven Development (TDD) may help get smaller scoped things done quicker, and with higher quality.  Try it out and see what can be done in shorter periods of time.

Experiment 4 - Then shorten the timebox

If you can’t get anything done in 2 weeks, then now you have 1 week.  

QA is silo’ed, the rest of us are under the same management. So, QA get’s sidetracked with lots of non-value-add work every Sprint.
Experiment 1 - Stop It!

Seems to be an easy enough fix to me…  Stop it!  Put everyone on the Scrum Team under the same manager.  There, I fixed it.

Experiment 2 - Who's In Charge Here?

I forget… Who tells the Development Team Members what to do (and when to do it) during a Sprint? Oh, tht’s right, it’s the Development Team members themselves! They collaborate each day to figure out what is the most important stuff to get done that day (or the next day, if your Daily Scrum meeting is at the end of the work day). So, there really is no such thing as any Development Team member being told to do work originating from a source other than the Sprint Backlog.

There are a ton of process cops already. Why do we need a ScrumMaster too?
Experiment 1 - You're looking at this all wrong

If you feel like you have too many ‘process cops’ already, then you are probably looking at the existing process in a negative light.  And, that’s no way to look at your processes.

ScrumMasters are here to help teams, not harm them.  ScrumMasters are not policing Scrum.  They are training and coaching on Scrum.  They are nurturing teams to adopt Scrum in order to create robust and resilient processes that increase local empowerment, awareness and creativity.

If you have governance and compliance officers that are hounding you constantly, they are probably there out of obligation to a higher order of oversight – not because they are trying to catch you doing something wrong.

Experiment 2 - That's not the intent at all

The ScrumMaster is supposed to be a servant leader, not a process cop.  Where did your org go wrong?

What’s the culture of your org like?

There are a lot of rules about promoting code from one environment to another. Uncle Bob’s style of TDD won’t work for us.
Experiment 1 - You're Right, Our Mistake!

Yup, you are right!  It’s way to hard for you.  Forget what we said about Extreme Programming practices.  It’s all just a farce, a ruse to get people to buy books and expensive training.  Your organization is doing fine with whatever (antiquated) processes and rules you’ve developed in the past.  No need to change.  You guys ROCK!

Experiment 2 - Well, Everyone Else is Jumping Off the Bridge...

Everyone else IS jumping off that bridge. So why aren’t you? The cool thing is that they all have these super cool bungee cords wrapped around their feet, and they are having the time of their lives.  That bungee cord is called Extreme Programming, and it saves them so much time and aggrevation, they are innovating their products instead of wasting 4 times the amount of time to fix all the bugs they unintentionally introduce into their products.

We write Unit Tests! Why does everyone say we aren’t doing TDD right?
Experiment 1 - Imagine

Imagine there’s no code.  It’s not hard. Just try.  If you had to write code only once, and get it right the first time, how much code would you want to write?  How many problems would you want to solve at one time?  You would probably keep it short and sweet, right?  Yeah, I would too.  The easiest way modern day programmers have found to do this repeatedly is through true TDD.  No code gets written without a test being written for that code (which doesn’t exist yet).  That test NEEDS to fail first – because there’s no code to test.  When just enough code has been written to pass the test, stop answering the problem, and start making the code more elegant (refactor).  If you are doing these three basic steps, then everyone is right – you are doing it wrong.

Experiment 2 - I Don't Think You Understand What Unit Tests Are

Here, I’ll give you the Wikipedia link to find out what Unit Tests really are.

OK, now go read what TDD is. (Check this out too)


(I’m SO tired of hearing this arguement. I’m going to go mix myself an adult beverage.)

Our off-shore resources only work at 25% the rate as our on-shore team
Experiment 1 - How DARE you call them that!

Stop calling PEOPLE ‘RESOURCES’!

Experiment 2 - Are You Seriously Still Using Offshore Sub-Teams?

Again, Stop it! Offshore sub-teams are a money pit that your company will eventually detest. Stop it now before it becomes such a mess that you will have to completely re-organize your development AND business structures.

Experiment 3 - Who's Really Offshore?

You ever realize that if anyone is offshore, EVERYONE is offshore?

Be careful who you call offshore.

Experiment 4 - Make Each Location Another Team

The answer to this one is know by the best operating companies – obviously not YOUR company (or you wouldn’t be seeking advice for this one).

At every location you want to operate for product development, create wholly functioning, self-organized and co-located teams.  These teams will communicate seamlessly and develop much quicker than if they had to wait for a sub-team to get back you with answers (or questions) 12 to 14 hours from now.

Don’t think that no one has ever done this before.  It’s been proven time and time again by MANY truly Agile organization world-wide.

We have lazy people on the team. I thought Scrum was supposed to make them work harder?
Experiment 1 - Who Needs 'em?

Get rid of lazy people, they just drag everyone down.

Experiment 2 - You Hired Them!

YOU hired lazy people, so it must be your own fault.  People don’t become lazy over time, they just stop the charade of being interested in your products/culture/company. So, this is YOUR fault. You should first fire the lazy people, and then confess your sins to management and tender your resignation.

Experiment 3 - Motivate Them

Anyone who hasn’t read Dan Pink’s book DRiVE probably still thinks it’s possible to motivate people into working better. If you truly believe that you have lazy people on your team, I’m guessing you’ve never even heard of Dan Pink. So, try your best to motivate them, or you can affect their whole life by taking corrective action against them (when you truly don’t understand what is going on under your own nose).

Experiment 4 - Become a Better Leader

You made it THIS far through the advice experiments, so maybe you’ll want something positive…  Read Dan Pink’s book DRiVE. It will give you insight into what motivation really is (pay attention to the explanations behind Autonomy, Mastery and Purpose). This will give you better ideas behind how to make the entire organization better for everyone.

Stop assuming that ‘poor performers’, if their are such people, are bad people, or that they are ‘not a good fit’. Talk with them about what makes them motivated to stay with their team, with the product they are helping to build, with the company.  Se if they are experiencing a form of intellectual burn-out.  If you care so much as to call them ‘lazy’, then you should care enough to make sure you never have any more ‘lazy’ people in the organization again.  And if you read DRiVE, as suggested, you’ll understand that it is your responsibility to make sure this pattern isn’t repeated.

My team is full of SME’s. They’ll never agree to Pair Programming.
Experiment 1 - Who are you? Captain Hook?

Smee?! Who is this Smee? Wasn’t he Captain Hook’s first mate?  This isn’t Fantasy Land! Get rid of these Smee-wanna-be’s and hire real life people.

Experiment 2 - There's No Room at the Inn for SME's

On Agile teams, it is well known that there’s no room for these people you love to call SME’s. I know you love to give people these titles or attributes that encourage people to stay with the company, because losing them would be a huge detriment to the life of your product(s). But, seriously, knock it off! Stop giving people kudos for living long enough (at the company) to become a SME, or a Senior, or a Principle Architect 3rd class, etc. These titles only help separate people from their abilities. They definitely help to separate skilled people from working collaboratively with other skilled people.

The short advice, if you have SME’s get them off of your Scrum Teams immediately. They create a hierarchy of delegation and completion of work that is counter to the self-organization concept of truly Agile Scrum Teams.

Our Definition of Done is impossible to achieve for a Story/Sprint
Experiment 1 - Declare Defeat Then

Then I’m assuming during each of your Sprint Reviews with your Stakeholders, who are probably executives, your have nothing working to show, and you’ve already received feedback that they are so upset with never being shown anything that works, that they are calling for your heads like the Queen of Hearts. True?

May I went to an extreme there. But, if I was a stakeholder for this team, that’s what I’d do. If you truly are a self-organizing Scrum Team, whose values include Respect, Openness and Courage, then why isn’t this happening (or already happened).  And why haven’t you ditched your DoD and started over?

Experiment 2 - Ditching the DoD

By the definition of Scrum (the Scrum Guide) every Scrum Team needs to have a Definition of Done that is currently achievable, and should become more stringent over time. So, if your current DoD is out of reach, then throw it away and start over with a DoD the IS achievable.

Over time, make this DoD slightly more stringent, to increase the team’s responsibilities, and stretch their skillset.

But, don’t ever START with a DoD that cannot be achieved by the Scrum Team. That is devastating to a team’s morale.

We talk about our Product Backlog all the time. We don’t need a Definition of Ready.
Experiment 1 - OK

That’s fine with me.

There’s nothing in the Scrum Guide that says you MUST have a DoR.  If your team is OK with the way you do things right now, then don’t adopt/create one.

Be forewarned though. If your team spends a ton of time in Sprint Planning and Product Backlog Refinement, because you don’t know how much discussion to have about individual Product Backlog Items, before starting work on them, then you might reconsider this decision. 

Another cue that you might need a DoR? Development Team members need a ton of discussion with the Product Owner during the Sprint, because they are still uncertain what is acceptible and what is not.

Our Product Owners all sit on another floor in the building, or in another state. But, they are really good at communicating with us when we schedule time with them.
Experiment 1 - So, What's the Problem Here?

If you are convinced that everything is fine, then why are you wasting my time asking a wuestion that isn’t really a question? Are you trying to tell me that I am wrong when I say that the best experiences that the VAST MAJORITY of the Scrum Community world-wide has had involve Product Owners literally sitting in the same room as the rest of the Scrum Team?

I hope that’s not the case. I hope what you are trying to tell me is that you know something is wrong with what you are doing, and you want me to help you fix it.

Experiment 2 - So, Are You Happy?

Part of a Scrum Master’s job is to make sure that everyone on the Scrum Team is doing the best they can to increase the psychological Safety and Trust of everyone else on the Scrum Team.  If this circumstance (with the PO) is a problem, then try to state it as a problem, and tell me what is wrong, and what you think should be done about it. I’m sure you can help yourself out, all on your own.

We have a low tolerance for failure here
Experiment 1 - So, You Have a High Tolerance For Lying?

Every organization has a tolerance for failure that is either high – in order to encourage experiementation and learning, which begats innovation, OR they have a high tolerance for being lied to by someone ‘in charge’ telling them everything is always OK.

Which organization would you rather work for? Which would you like to change your current organization into?

Experiment 2 - Whaddayagonnadoaboutit?

(That title is something New Yorkers think they invented. Chicagoans know better.)

Scrum Values of Respect, Courage and Openness say thay you need to act here. So, if you are going to do something, what are you going to do?

Preach – go directly to the nearest manager and start preaching about Scrum and how we have a high tolerance for failure, because it in turn promotes innovation?

Train – take it upon yourself to retrain management into understanding that failure leads to future successes that out-pace using the same product development processes we’ve always used here?

Coach – open a dialog between yourself and whoever believes thay can trust you, and feel safe at the same time, while you guide them closer and closer to the conclusion that you are right about failure, and they are wrong?

You are playing a Choose Your Own Adventure type game (yes, I know they are books and not games) with management here. Choose a path to gain acceptance of failure, because without it, Agility is doomed (you don’t even have to mention Scrum, it’s Agility that is at risk here).

There’s a lot of turn over on these teams, so we need a uniform way to estimate everything
Experiment 1 - Wow! Was That Your Idea?

Wow! You came up with that all by yourself? You deserve a promotion! Or a raise! Maybe both!

Who are you kidding?! Take a look at your organization. Maybe your leadership style. Maybe everything! Figure out why there is so much churn and fix THAT!

Experiment 2 - Normalization is Like Vanilla Ice Cream

I, personally, do not like vanilla ice cream. I think it’s boring. If you like vanilla ice cream, chose another example of boring-ness.

Normalization of how teams work is not going to entice people to stay. The spice of life is what will get people to stay with your teams. Make your teams, and the processes they create for themselves, their own creations, and see how that affects churn.

OR, try something else – I’m probably wrong about that whole variety thing anyway. You know, the ice cream shops only sell vanilla.

Experiment 3 - What Does Estimation Have To Do With It?

I’m extremely confused as to how you jumped from having such a dysfunctional organization (where people do not want to stay on the same team, or stay with the company), to there being a problem with how the team is estimating.

Explain that to me, and I’ll explain why you should not be concerned with HOW the team is estimating, and why you should be more concerned about HOW your organization is passing up retention opportunities with your current employees.

We don’t need a Scrum Board, because we all know what we are doing
Experiment 1 - Sounds Good To Me

If that’s the case, then I’m assuming that everyone on your team works WITH at least one other person on the team throughout the Sprint (no individual work), the team has not missed completing a Sprint Goal in recent memory, Sprint Planning is always a joy, as are the Sprint Reviews and Retrospectives.

Good for you guys!

Experiment 2 - Visualization of Work

Pray tell, then, how are you visualizing the work of the Scrum Team?

Experiment 3 - Not Required, But Helpful

There’s no requirement that a Scrum Team create a Scrum Board. But, they are helpful in most cases. If your team decides not to create a Scrum Board, that’s fine, they haven’t broken Scrum. Yet.

If not visualizing the work, through the creation of a Scrum Board, AND anything in the Scrum Team’s experiences starts to turn negative, the Scrum Board is my first stop on the train ride to fixing your team’s problems.

Very, very, very few successful Scrum Teams do not have Scrum Boards to visualize their work.

Our Coach is telling us to separate the Sprint Retrospective from the Sprint Review, but our Scrum Trainer told us they happen at the same time.
Experiment 1 - Listen to Your Coach

Your Coach is right. They are separate events with separate participants. Separate them.

Experiment 2 - Listen to Your Trainer

Your Trainer is right. They happen at the same time.

Wait… No… That’s not right. Oh!!! This is that point during the training where a key person, who is shaping our use of Scrum, fell asleep a little bit. What they heard isn’t what the trainer actually said.

The Sprint Review and the Sprint Retrospective happen on the same day during a Sprint.  The last day. Further, they happen back-to-back. Meaning as soon as the Sprint Review is over, the Sprint Retrospective is supposed to start.

It’s easy for anyone to sit through 2 (or more) days of training and make this common mistake of misunderstanding that these two events are completely separate and also have two different sets of participants.

Go back and ask your trainer if they really said that the two events happen at the same time, with the same participants. If they agree with your prior understanding, do the following: 1) NEVER communicate with this ‘trainer’ again. 2) NEVER use the training company they work for again. 3) Send me their name and contact information, so I can spread the word that this charlatan is conning people out of their money and spreading BAD information about Scrum. (Thanks!)

Experiment 3 - Do Your Own Research

The Scrum Guide is the definitive definition of Scrum (written by the creators of Scrum). Read it. It is very clear about the boundaries of each event in Scrum, and who are the participants in each event.

If you are using a different definition of Scrum… well, good luck.

So what if we delay a Scrum event for a team member to arrive?  We still do it.
Experiment 1 - Your Actions = Your Character

This is a “You are what you eat” sort of mentality – from my perspective.

If you want to be less diligent about when you do things, that’s fine with me. Just remind me about this if I ever interview at your organization. Because, I don’t like working with people who bend the easiest rules to follow (timeboxing), just because it allows people to not be accountable for their own actions.

Experiment 2 - That's Not Scrum!

If you aren’t practicing diligent timeboxing techniques, you aren’t doing Scrum!

Experiment 3 - What does the Team Working Agreement Say?

What does your team’s Team Working Agreement say about this?

Nothing? Maybe you should suggest a change at the next Sprint Retrospective.

You don’t have a Team Working Agreement? Why not? It’s not required for Scrum, but not having one is like jumping in the drivers seat of a sportscar, and not knowing how to drive at all (it’s dangerous!). I often wonder how teams have ever collaborated at all, without having an agreement to the terms of working together.

Our team waits for the ScrumMaster to start every Scrum event, because she is the real Scrum person on the team
Experiment 1 - There Is No I In Team

Just like that super-annoying idiom/cliche “There is no I in team”, there is no one specific ‘Scrum person’ on a Scrum Team.

Well, ok, the Scrum Master is supposed to teach and coach everyone about Scrum, but that doesn’t mean that Scrum Events need to be put on hold for this specific person to show up.

Let’s use our brains a little here. This is a TEAM, not a kingdom. The team lives on, and Scrums along, even without a Scrum Master present.

Experiment 2 - So, Do You Work Without Your Manager Present?

If this is the case, then you obviously do not start your normal daily duties without your direct manager/supervisor/overloard looking over your shoulder…right?

Experiment 3 - How Micro-Manage-y of You!

Do I really have to say how reminicent of micro-management this is?

If the Scrum Master ‘owns’ the Scrum Events, either get a new Scrum Master, or start changing your organization’s definition of Scrum.

Ideally, the Scrum Master owns nothing, has no official authority, and has no official powers.

We chose to use Scrum to help use with our Services / Product Support team’s work. But, Scrum is a terrible methodology.
Experiment 1 - Correctamundo!

Totally agree. Cease the use of Scrum right now and find something more suited to how you would like to manage the work.

Experiment 2 - Oh! How wrong YOU are!

How dense! Of course Scrum is a silver bullet to all walks of life and all ways of working. You guys are obviously not trying hard enough to fit this Scrum shaped peg into the service shaped hole.

Experiment 3 - Mmmmmaybe!

There is, of course, no silver bullet to all of the world of work’s problems. Contrary to what ‘famously’ named authors of Scrum books will claim, Scrum is not suited for all types of work. Period. (wait, now there are lots of periods…)

If someone is trying to get your organization to use Scrum in an area of work where you’ve already experienced bad side effects of trying out Scrum, sit down with them and have a discussion (not a debate) on the matter.  It may be that the person you are talking to has a valid opinion of why it didn’t work before, and why it might work now. Then again, they might not know the particulars of your organization, and may be barking up the wrong tree.  No one will know, for sure, if Scrum will work for you until they do some deep investigation.

We have to use an algorithm to calculate teams’ Story Points per day, because our teams have decided to not be constrained to a concrete timebox for every sprint
Experiment 1 - I've Heard Shit Sandwiches are Tasty!

Pardon my French, but you guys are all ate up, like a shit sandwich.

Experiment 2 - Points Per Day is Outdated

Points per developer and Points per day techniques of estimating work has rarely worked to help express teams’ self-organization, nor increase their Agility. It was a bad idea when it was invented. It’s a bad idea now.

Experiment 3 - Seriously, You Want To Work Even Harder?

So, you just decided to make the way you perceive work even more difficult. Good for you.

Can I interest you in a bunch more algorithms to figure out: how many dots people get when dot voting; how much time each person should get to drone on during the Daily Scrum; how many teams we need to complete this project/product release before an unmovable deadline; how many Development Team members are needed for this team; how many tasks are needed to completely fill up the Sprint Backlog with work for the team to complete this Sprint? Oh, and I’m sure there’s more (like ALL of the silly metrics that command and control management organizations like to collect on ‘self-organizing’ Scrum teams).

Experiment 4 - Silly Rabbit! Scrum is For the Adults!

Knock this nonsense off!

Figure out what SHORT timebox is right for your Scrum Team, and stick to it. We don’t mess around with the length of the Sprint!

The first few days of every Sprint are boring because we are always waiting for the Business Analysts and Business Systems Analysts to finished updating the FRD, before we work on the stories
Experiment 1 - I Thought You Said You Are Doing Scrum...

What version of Scrum says it’s OK for anyone on/off the Scrum Team to hijack the team until they are done doing their work? (which isn’t really ‘their’ work at all)

Experiment 2 - Reduce, Reuse, Recycle?

Get these people out of the way so the team can work. These people slow teams down. I see this type of work when teams are not Refining the Product Backlog (well, or at all). These people are not necessary on Scrum Teams, if this is their behavior.

Seriously, if you (the Scrum Team) can’t work collaboratively to get these things done before the beginning of the Sprint in which the PBI’s will be selected, what the heck are you guys doing during Product Backlog Refinement?

A better use of these people is to invite them inthe Development Team properly, dedicate them to the team’s work (they don’t get to work on/for any other team), cross-train them so they can do more than just type in requirements. Because that is NOT a full time job on a Scrum Team. 

Our BA’s and BSA’s aren’t very good at documenting the technical details before we start coding
Experiment 1 - Refer to the previous problem/experiment, please.
Our stories sit in In Progress for a long time before the Scrum Board shows any progress being made. Managers don’t think we are really working.
Experiment 1 - Think Small

Make your Product Backlog Items smaller.  They’ll move through the Scrum Board’s flow faster.

Experiment 2 - Don't Be Afraid to Talk to Management

Is everyone on the team afraid of having a conversation with managers? All it takes is one (maybe two or three at the most) time around the topic of the team being self-organizing, and re-addressing each In Progress topic everyday with the rest of the team, before Managers lay off.

Remember, the Sprint Backlog is a Transparent Artifact in Scrum.  Meaning, everyone has access to at least view it.  This visibility prompts management, at times, to inquire about the appropriateness of the team’s prioritization of efforts. Be prepared to have these conversations. Have the Scrum Master ready to train uninitiated Managers on the spot.

Sometimes the ScrumMaster gets upset when the people assigned to stories trade them to other people on the team
Experiment 1 - Mind Your Own Business!

Tell the Scrum Master to take a step back and let the Development Team handle the work. That’s the Development Team’s job. Period.

Experiment 2 - Assignments! We Don't Need No Stinkin' ASSIGNMENTS!

In Scrum (contrary to what all of the electronic Backlog Management tools try to get you to do), there are no assignments. People elect to do the work.  And we trust them to make good decisions.

Experiment 3 - Step Away From The Sprint Backlog

The Scrum Master really has NO CONNECTION to the work being done by the Development Team. It may help, in some contexts, to have the Scrum Master stay very abreast with the work the team is doing, but they really have no stake in the day-to-day HOW of the team getting the work done. So, once again, get the Scrum Master to mind their own business, step away from the Sprint Backlog, and focus on their own priorities, responsibilities, etc.

It’s difficult to read stories quickly because sometimes they have little detail, sometimes they only have a title, other times they are so technically detailed it’s hard to tell what value they provide
Experiment 1 - You've Got Some 'Splainin' To Do

Sounds like you’ve just encountered many of the interesting ‘problems’ that all collaborative teams eventually encouter.

Too much detail – Just get the PBI to a ‘Ready’ state, then leave it alone until Sprint Planning.

Not enough detail – Again, get it to a ‘Ready’ state, then leave it alone until Sprint Planning.

Wow! You can solve all of this with one answer? Who woulda known?

The Product Owner keeps telling us that the stories aren’t done yet.
Experiment 1 - Who's the Boss?

This isn’t a campy sitcom from the 1980’s, this is work. So, who IS the boss around here? Figure that out and you’ll figure out who gets to tell the team if the work is done or not.

Experiment 2 - You Should Have Figured This Out By Now

You’ve been practicing Scrum for a while now. You should know who gets to tell the team if something is done or not.

Experiment 3 - I'm Sure Scrum Has a Hard and Fast Solution For This

Since Stories are part of Scrum (they aren’t), and everyone only uses Stories in their Product Backlogs (not true – there are hundreds of types of PBI’s), then everyone knows that the Acceptance Criteria is the solution here (it may not be)!

All you have to do is double check the story’s product with the Story’s Acceptance Criteria. If the Criteria are met, the Story is Done! How easy! (It’s not that easy)

Experiment 4 - What Does the Definition of Done Say?

While some types of PBI’s may have individual done-ness criteria (Acceptance Criteria), Scrum actually says that a Scrum Team needs a Definition of Done that describes what an acceptible Increment will ‘look like’. Whether your PBI’s have their own criteria of done-ness or not, both the description of the PBI and the Definition of Done should be able to give the Development Team enough information about what each individual PBI, as well as the resulting Increment, should look like when ‘done’.

There are few surprises in Scrum. Done is no surprise.

We need more columns on our Scrum Board to keep track of which states our work is in, but the ScrumMaster says no
Experiment 1 - Best Do What Yer Told, Or Else!

The Scrum Master obviously knows what they are doing! They’re certified, right? Better do what they say.

Experiment 2 - What Do They Know?

Who has a closer connection to the work being done? The Development Team, or the Scrum Master? The Development Team OWNS the Sprint Backlog, thus they should be making all of the decisions about the Scrum Board.

Experiment 3 - Maybe Try Some Open Collaboration?

Has it ever hurt to sit down and openly collaborate with someone on a creative wat to do something? OK, maybe it has (I’m getting images of highschool project teams where one of my classmates was always tripping on LSD).

Let’s assume for a minute that the Scrum Master just wants to make things easier for the Development Team – which happens to be the same goal of the Development Team! Maybe sit down and talk it through. You may find that adding more columns is actually a bad thing. The Scrum Master may find that adding columns streamlines the way the team visualizes their work and makes them happier, without causing any extra delays.

Our Product Owners want more formal direction in their Role and Responsibilities
Experiment 1 - Good For Them!

Have they read the Scrum Guide?

Experiment 2 - Get Certified

I can’t imagine they still need more to go on, but, hey…whatever.  Maybe try getting their CSPO from a Scrum Alliance Certified Scrum Trainer. Those classes are super in-depth about the Product Owner role, and almost all trainers have simulations that put the Product Owner through their paces.

Experiment 3 - Still Need More???

Wow! Back for more?

All right, look. The Product Owner OWNS the product that the Scrum Team is mutually responsible for creating.  They also OWN the Product Backlog, which is the ordered list of all currenty known ‘stuff’ that could go into the Scrum Team’s product. They also ‘own’ (so this isn’t an all captital letters OWN, there’s a difference) the relationship with the product’s stakeholders.

All of these things the Product Owner owns must be tended to daily. So, get on it! There’s really not enough time in a day for everything the Product Owner needs to do.

We are having a ton of problems with timing of Scrum Events, because half of our team members are in the USA and the other half is in India
Experiment 1 - Yup, Dislocation Hurts

You did this to yourself (at least your management probably did this to yourself), so now you have to live with it.

Don’t fool around with coloring this in a positive light – don’t call this a distributed team, or a multi-location team, or a remote team. It’s called a dislocated team, because dislocation hurts, and this is what you get from it – painful circumstances that you have to deal with.

Stop this nonsense, co-located your teams, and live your best life.

Experiment 2 - Do Your Best

Yeah, really, #1 is the best answer for this problem – hands down.

But, since you lack the backbone and intestinal fortitude to stand up to management and make things right, I only have this for you: Do what you can.

If what you can do is shift around the timing of Scrum Events so that everyone can attend, even though it’s a pain in the ass – well, that’s what you have knowingly accepted as ‘good practice’.  Good luck!

Manager: It would be great if I knew what was going on when I look at a Scrum Board. I feel like they need my help, but I can’t tell
Experiment 1 - Learn About Scrum

Take any, yes ANY, course on Scrum you can find.

Experiment 2 - Talk to the Product Owner

The Product Owner should be well-informed about what is going on during the Sprint.  Talk to them and get some help deciding if you need to help the team.

Likely, unless you’ve been asked for help, the team doesn’t need your help.

Experiment 3 - Talk to the Scrum Master

The Scrum Master should be well-informed about what is going on during the Sprint.  Talk to them and get some help deciding if you need to help the team.

Likely, unless you’ve been asked for help, the team doesn’t need your help.

Experiment 4 - Talk to the Development Team

The Development Team knows best what is going on during the Sprint.  Talk to them and get some help deciding if you need to help the team. DO NOT try to talk to them during a Daily Scrum!

Likely, unless you’ve been asked for help, the team doesn’t need your help.

Experiment 5 - Take Control of the Team

Scrum Teams don’t usually know what the hell is going on.  You should take control as early, and as often, as you see fit. After all, you ARE a manager!

Should we put some more stuff on the Scrum Board? Like blockers?
Experiment 1 - No! It's For Stories ONLY!!!

Are you insane?! The Scrum Board is for Stories only! Go put blockers somewhere else. Better, just give them to the Scrum Master, it’s their job to solve all of the Development Team’s problems anyway.

Experiment 2 - Hey man! Sure!

C’mon down man, it’s all groovy here. Do what you want. We’re cool, you’re cool, let’s all be cool. 

Experiment 3 - What Makes Sense?

What makes sense? Is adding the blockers (I’m assuming you mean impediments) to the Scrum Board going to make things easier for the Development Team? If ‘yes’ then add them. If ‘no’ then drop it.

Look, just have the Development Team make this decision. This is THEIR artifact, let THEM manage it.

(Technically the Sprint Backlog is the Artifact, and the Scrum Board is just ONE way to visualize the Artifact. But, for arguement’s sake, here, we can say that this is the Development Team’s artifcat to do with as they please.)

We need a Sprint Zero for analysis
Experiment 1 - Don't You Ever Say That Around Me Again!

You say Sprint Zero one more time and I’ll cut ya! You hear me?! I’ll cut ya!

Experiment 2 - That's Not a Thing

Sprint Zero’s not a real thing. It ain’t in the Scrum Guide, so it ain’t real.

Experiment 3 - What's the big deal?

Can’t analysis be done during a real Sprint? Like, say, Sprint 1?

While we’re at it, let’s try to build a thin vertical slice of functionality too.

Experiment 4 - Sprint Zero is Mandatory.

Some process heavy, and command and control weary, organizations have already come out and mandated that Sprint Zero is a thing, and it will be done before any Scrum Team starts Sprinting.

The response from many Scrum Coaches and Scrum Trainers is that all of the objectives of Sprint Zero can be done just as well during a real Sprint. So, why hide behind a concept that the creators of Scrum have openly decided not to add to Scrum, and which dilutes Scrum to the point of being detrimental to the organization, instead of being helpful?

Experiment 5 - Who Cares?

Who cares if you are doing a Sprint Zero? There will always be a ‘before time’. That time for Scrum Teams could be called ‘Sprint Zero’ or it could just be called ‘That time before we started using Scrum, but we were actively trying to get it off the ground.’

Who really cares? Are we seriously going to burn a ton of calories debating this horse manure?

Team Members keep leaving the room in various Scrum Events, because people walking by want to talk to them
Experiment 1 - So?

So what? Maybe there’s more important stuff to do than be a part of a Scrum Team.

Experiment 2 - She's a Witch! Burn Her at the Stake!

Fire that person! OK, maybe that’s going too far… Throw that person off of the Scrum Team in a public display that sends a message throughout the company that no one should EVER leave a Scrum Event before it’s timebox expires.

Experiment 3 - Maybe This Is a Coachable Moment?

We’ve got a Scrum Coach on the team, right? The Scrum Master? 

Maybe the Scrum Master should publicly tell the entire Scrum Team that it’s important to stay present, physically and mentally, throughout all Scrum Events, to maintain continuity, conversations, and avoid backtracking a conversation because someone missed something.

If it continues, maybe that person needs some 1-on-one coaching with the Scrum Master.

If it still continues, go ahead and burn her at the stake! 

(you know I’m kidding right?!)

It seems like we work around our infrastructure, instead of making it work for us
Experiment 1 - Hire Better

Hire better architects. That’s the only way we could ever have a better constructed and integrated infrastructure that suits our specific needs.

Experiment 2 - That's Not Agile

I’m pretty sure I remember there’s something in the Agile Principles about self-organizing teams and architectures.

But, I could be wrong. (I’m not wrong, it’s the 11th one down the page.)

Small side conversations seem to break out in all of our Scrum Events. This is annoying and disruptive
Experiment 1 - Not My Job, Man

That’s the Scrum Master’s job – to stop side conversations, and make everyone pay attention to me. 

Experiment 2 - We'll Just Talk Louder

It’s OK, you’ll get used to it eventually. Just talk louder so you send that reinforcing passive agressive message that you will not be interrupted or ignored.

Experiment 3 - Where Did That Working Agreement Go, Anyway?

This is another one of those elementary Working Agreement things. If it’s not in there, put it in there.

If this is already in the Working Agreement, shove it in their little faces!

Wait, maybe don’t do THAT. Maybe bring it up at the next Retrospective. Bring the Working Agreement with you. Work on this as a team.

I’d rather just be told what to do…
Experiment 1 - I'm Good With That. Go Get Me a Cup of Coffee.

You really want to be told what to do every single day? And how to do it too?

You sicken me. And, you intrigue me at the same time… How did you get this job?

Experiment 2 - That's Not Agile

Self-organizing Scrum Teams are (almost by definition) full of intelligent and creative human beings focused on using their creatity to solve complex problems in adaptive environments.

If you need to be told what to do everyday, and how to do it… maybe a Scrum Team is not your best work environment.

We spend more time in meetings and less time working now
Experiment 1 - Prove It!

I don’t believe you. Not even for a second. Prove it.

Experiment 2 - Let's Break This Down

SM: OK, I’m game.  Let’s break this down – let’s analyze this claim. You are doing 2 week Sprints, right?
DT Member: Yes.
SM: OK, How long are each of your team’s Scrum Events?
DT Member:
Sprint Planning: ~90 minutes per sprint
Daily Scrum: ~10 minutes daily
Product Backlog Refinement: ~ 7 hours per sprint
Sprint Review: ~60 minutes per sprint
Sprint Retrospective: ~45 minutes per sprint
Infrastructure Meetings: 4 hours per sprint
Management Meetings: 10 hours per sprint
Impediment Update Meetings: 2 hours per sprint
Project Status Meetings: 3 hours per sprint
That’s 29:55, almost 30 hours of meetings! Almost HALF a sprint!

SM: OK, I’ll go along with some of that. I don’t like that your Retro is so short, but we can address that another time. From your list, Scrum doesn’t require anything after the Sprint Retrospective. You’ve ADDED all of that stuff to Scrum. Scrum didn’t ADD anything to that workload, because it’s not necessary. Self-organizing teams solve their own problems as best they can, they create their own architectures, they work on developing a self-managing style of working, and they DO NOT give statuses outside of the Sprint Review. So, let’s talk about what you’ve artificially added to Scrum, and why.

We keep adding a week to each sprint, and we still can’t complete an entire Sprint’s work
Experiment 1 - That's Not Scrum

Stop it.

That’s not allowed, so just knock it off.

Experiment 2 - Make it Shorter

Fine. Your Sprints are now half of the length they used to be. NOW try to get something done!

(evil laugh)

Experiment 3 - Make Product Backlog Refinement Better

Start utilizing your time better in Product Backlog Refinement.

If you don’t have a Definition of Ready, make one. And use it properly.

Experiment 4 - Make Sprint Planning Better

Start utilizing your time better in Sprint Planning.

If you don’t have a Definition of Ready, make one. And use it properly.

If you don’t track Velocity, start. And use it properly.

Experiment 5 - Make the Daily Scrum Better

Start utilizing your time better in the Daily Scrum.

Everyone must speak.

Follow those outdated and crumbly old 3 questions as a crutch to eventually start discussing your problems and planning the day ahead of you.

Experiment 6 - Make the Sprint Review Better

Start utilizing your time better in Sprint Reviews.

Seek advice from Stakeholders.  Ask them to help with Organizational Impediments

Experiment 7 - Make the Sprint Retrospective Better

Start utilizing your time better in Sprint Retrospectives.

Have open conversations about the true impediments the team is having.

Stop focusing so much on Team Dynamics, start focusing on the TRUE PROBLEMS the team is experiencing.

If you are not incorporating the Stakeholder Feedback from the Sprint Review, start.

If you are not coming out of the Retrospective with a clear plan of fixing one problem that the team has the skill and power to fix, start.

Experiment 8 - Why Are You Extending Each Sprint?

Let’s do a deep dive into why you believe it’s necessary to extend each Sprint, instead of declaring a short term failure, and collaboratively trying to figure out which behavior(s) would solve the underlying problem of not completing anything.

I keep seeing emails to large audiences and we are all referred to as ‘Resources’ or by our employee ID’s. I want some recognition!
Experiment 1 - So? You ARE a Resource

That’s the way we’ve always done it here. You ARE a resource. What’s the problem with that? We have a department, just like every other company, called Human Resources. Nothing wrong with that.

There’s also, so many employees at this company that have the same or similar names. After a couple hundred thousand names, it’s just easier to refer to your employee ID’s. There’s no ill intent here.

Experiment 2 - Do You Know How Much Work That Is?

You couldn’t possibly know how hard it’s going to be to change how we do things like this? It’s going to take major changes to Outlook, and our HR applications,…

Too much work. Sorry. Next!

Experiment 3 - Let's Work On This Together

No joke, this is extremely hard to fix in some very Agile companies.  The companies that are willing to work with you on this will move very slowly. Not because they don’t want to fix this, but because it’s one of those things that is engrained in everything they’ve ever done, ever.

Start with small obstacles to overcome. Add titles to job families. Add job familes, retire others. Get HR to join the Agile revolution. Get HR to change their name to something more acceptable (People Ops).

It’ll be a long slog, so put on your determined face and your thinking cap, because you’ll need them.

It’s not impossible. But it’ll be difficult.

Still Need Help?

If these suggestions do not solve your problem, please accept our apologies for any dysfunctions that your Scrum has revealed to you. You may find related organizational dysfunctions in the section Advice & Preventative Maintenance