Sprinting

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

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.

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.

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.)

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.

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.

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.

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.

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.

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.

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 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!

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.

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).

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.

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.

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.

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.

Use abstract estimates like Woodland Animals, or facial hair.

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.

See what happens.

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.

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.

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.

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?

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.

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.

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!

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

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?

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!

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.

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.

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

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.

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?

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.

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)

THEY ARE NOT THE SAME!!!

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

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.

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

Be careful who you call offshore.

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.

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.

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).

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.

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.

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.

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.

(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).

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.

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.

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

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.

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!)

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.

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

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.

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?

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.

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.

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.

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.

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).

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!

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. 

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.

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.

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.

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

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)

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.

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.

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.

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.

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.

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!

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.

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.

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.

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!

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

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.)

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

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.

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?

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?

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.

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?!)

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.)

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.

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.

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.

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.

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

(evil laugh)

Start utilizing your time better in Product Backlog Refinement.

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

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.

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.

Start utilizing your time better in Sprint Reviews.

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

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.

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.

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!

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.