Tag Archives: scrum

Don’t Give Up! A Story About Impediments

 

snail crawling on pavement

This snail thinks it’s speeding along. Do you?

Let’s talk about impediments.  “A hindrance or obstruction in doing something”.  From the Latin impedire, to shackle the feet of.  A thing that slows you down or keeps you from moving forward.  Simple as that.

And yet every day I go to stand-ups or Scrum of Scrums meetings and I hear people go around the room: “No impediments.”  “No blockers.”  Really?  There’s nothing standing between you and your ideal flow state where you code, test, or write stories all day in your dream office on your dream machine with no interruptions and churn out only the best bug-free features with no tech debt and no escalated support calls?  Are you guys hiring?  I wanna come work there!

Often when people say they have no impediments they mean that they have no unusual impediments.  Or they mean that they have none that they think anyone can do anything about. Other things that keep people from reporting impediments:

  • They’re embarrassing:  “We’re about to do some Angular and I don’t know anything about it.”
  • They involve interpersonal dynamics:  “There’s a person on the team who won’t explain their code to me.”
  • They involve money.  “This laptop is too slow.”

I have a true story about that last one.  Read it and let me know if that changes your mind about handling impediments.

So … slow.

When I train Scrum Masters I always stress their role as impediment removers.  Some take naturally to this part of the job, while others need some assertiveness training.  I myself tend to naturally avoid conflict so I often have to remind myself to practice what I preach and not shy away from the hard problems.

Anyway, there once was a newly minted Scrum Master who was very gung-ho about the role and almost immediately let me know that his team’s top impediment was that their laptops were too slow. I agreed and pushed a request for faster laptops up the chain.  And … not in the budget.  Also, I was told, the machines aren’t too slow: the teams have designed an app that’s too complex and thus puts a strain on the machines when running locally.  Which was true to an extent, but not that helpful in the short term.  I tried to push it a bit but got a very firm answer again: this isn’t going to happen.  Make do.

laptop with stethoscope and crumpled paper

Is it doing anything? I can’t tell.

Reader, I’m embarrassed to say that I gave up at that point because, well, that’s just how things are around here.  But my Scrum Master trainee didn’t.  He started to collect data from the teams:  mean time to open the application in the IDE, mean time to start debug mode, mean time to run all the unit tests, and so on.  He made videos.  He showed them to people. Eventually he found the company’s employee suggestions site and wrote a long and compelling case for better laptops, which included calculations of the cost of lost productivity versus the extra cost of a fast machine.  He then started networking with developers on other product lines and in other offices and got them to all go vote for his suggestion, which then became the #1 hot item on the suggestions site.

This got him an audience in front of the executive team, which was delayed but eventually happened.  Between this and some cajoling of a new development director, the first new and souped-up machine finally arrived.  Benchmarks showed it did indeed cut task times by a huge amount and as machines aged out they were replaced with the new spec, which made its way to the IT department as the updated company “performance laptop” standard.

This entire process took close to a year if I remember correctly.  The Scrum Master did not get a fat bonus or much official recognition for this, but I’m going to go out on a limb now and say that was one of the all-time legendary impediment removals.  No mandate, no seniority in the company, just good old-fashioned stick-to-it-iveness.

Are You Fighting That Hard For Your Teams?

As a Scrum Master. impediment removal is one of the single best uses of your time once a team is up and running with the basics of Scrum.  You are directly targeting waste and by doing so increasing your team’s velocity and most likely its morale.  Also, if you’re not a technical member of the team, you’re gaining the team’s appreciation and respect and helping the organization see the value of the Scrum Master role (Hey, it’s OK to have a selfish motive thrown in there).

Don’t get me wrong – it’s not always easy to solve impediments.  Many times even getting the team to recognize and raise them takes quite a bit of creativity and effort.  But don’t let that stop you.  You’re a Scrum Master – Master of Scrum!  So use your Courage and Commitment – two of the five Scrum values – and dig into those impediments.  What are you waiting for?

When Agile Isn’t

agile word tiles

How much can we take away before it’s not what it was?

OK, philosophy time: When does a thing change so much that it ceases to be that thing?

Let’s Play Football, or Something Kind of Like It

Let’s take American football.  If I tell you I’m playing football, but that we aren’t wearing helmets or uniforms, is it still football?  What if we are using tear-off flags on our waists instead of tackling each other?  Still OK?  What if we have 5 players per side instead of 11?  What if we don’t allow forward passes (they once weren’t allowed, actually)?  What if we use a round football?  What if we don’t keep score?  You get the idea.  There’s some fuzzy point where the Reasonable Person of jurisprudence would agree “That’s … not football.”

For a more entertaining example of the difficulty of precise definitions you can check out the Sandwich Alignment Chart.  Is a burrito a sandwich?  I’ll warn you: it’s a pretty deep rabbit hole.

It Says “Agile” On The Carton But It Smells Kind of Weird

pouring milk

Can I drink this? Seems dubious.

Those of us who have been coaching Scrum, SAFe, Kanban or other “agile umbrella” practices for a long time tend to have a pretty good sense of when the basic tenets are being violated.  It’s tough to call out, though, because we also tend to want to avoid prescriptivism; if a team finds some change to a process works for them, great!  They are self-organizing, right?  Yes, but1 it’s OK to probe a bit into the intentionality behind the way teams are working.  Are they fully aware of the Agile Manifesto principles?  Are they professing to do a specific agile flavor such as Scrum?  How did they arrive at where they are?

1(pretend I said “yes, and” if it makes you feel better)

There are plenty of ways to go about assessing a team’s agile adoption.  For example:

  • You could administer one of the many team health surveys, such as the Spotify squad health check, or roll your own.
  • You could do an agile maturity assessment.  Ben Linders has a nice article on this and provides a mother lode of assessment links.
  • You could retrospect with the team and discuss the various aspects of Scrum (for example) and how much they feel each ceremony, role, and artifact is adding value.  You might be surprised at what you hear.

The important thing is that you as a coach or other leader are hyper-aware of how things are going so you can present and facilitate the right learning paths for the team.

What Exactly Is This We’re Doing?

“We’re Agile”

The more specific you get with with what you’re professing to do, the more you’re on the hook for the details.  This is probably why many people stop at “we’re agile” which in the modern world is like saying “yes, we develop software”.  So I guess those folks just need to live up to the Agile Manifesto and its 12 associated principles.  As long as the team talks to business stakeholders every day, works reasonable hours, has regular retrospectives, has regular face-to-face conversations, delivers software no less frequently than every couple of months, and … yikes does it really say all that?  Yep.

“We Do Scrum”

Scrum teams try to live up to the Agile Manifesto while also adopting more specific roles, ceremonies and artifacts: Scrum Master, Product Owner, daily standups, sprint planning and review, retrospectives,  and prioritized product and sprint backlogs.  They also follow the Scrum Values: commitment, courage, focus, openness, and respect.

I’ve been accused of being a prescriptivist when it comes to Scrum, but that’s because I’ve been able to help a lot of teams by getting them back to basics and investigating why they felt the need to skip retrospectives, not make the backlog visible to the teams, or whatever else.  It’s been pretty rare in my experience that teams have invented a brilliant new version of Scrum and pretty common that they’ve been cutting corners or just are not willing or able to commit to the mindset required.

“We Do 4-level SAFe 4.0”

If you know SAFe, you know it adds a slew of details on top of plain ol’ Scrum or Kanban.  It does a good job of explaining how to scale agile to many teams and defines processes that handle economics, coordination, shared resources, and medium and long-term planning.  However, if you’re going to say you do SAFe you should have Release Train Engineers, ART Sync meetings, Weighted Shortest Job First story ranking, and all that good stuff. You also get the 9 SAFe Principles on top of the Scrum Values and Agile Principles you’re already following.  You are decentralizing decision-making, right (#9)?

Labels Schmabels?

Only you can decide how you want to label your Agile implementation or whether you even want to at all.  Personally, I try to take care to be specific, like “We have a pretty strong agile program.  Most of the teams do Scrum but we have some Kanban support teams.  We’re still releasing on a long cadence though because our CI/CD and test automation practices just aren’t there yet.”

If I name a specific framework like SAFe, you should expect that I have a thorough working knowledge of the theory and can reel off the ways we aren’t in alignment with it, and for each I have some plan to get there or else a defensible argument as to why we aren’t going to implement it.  I think that’s only fair to the creators of those frameworks.  If I make no pretenses about named processes (“we’re rolling our own”) then it comes down to whether we’re following the agile principles.

It’s the Thought That Counts

I don’t think it’s helpful to go around pointing out all the ways teams are doing agile “wrong”. The reality is that it’s possible to succeed with or without normalized story points, or with two- or three-week sprints, or with all sorts of other minor modifications and variations.  However, in the spirit of reflection – “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly” – I encourage you to be honest and open with yourselves and your teams about the current state of your agile journey.  Is it a work in progress?  Say that.  Does it feel like your agile implementation is in trouble?  Be forthright about that and get feedback from the teams and your leadership team.  And start with the values …

By far the most important goal for any agile team or organization is to work to embrace the chosen values and principles, whether it’s just the Agile Manifesto or the Scrum values or SAFe Principles.  Adoption of specific practices follows much more easily after that because (hopefully) they tie directly to the values and you can thus justify them in that light.  You can also self-evaluate your practices against the values.

In Closing: Is It Agile Or Not?

I have a hard time compromising on the Agile Manifesto and the twelve related values.  If there’s not at least an effort to live by those, it’s not Agile to me.  But certainly many companies happily implement Scrum, SAFe, or some other framework and just completely gloss over the underlying ideas.  That makes for a sort of Hollow Agile that often fails to deliver the expected results and leaves everyone feeling burned.

Don’t worry, there’s no Agile Police, so you can keep on keepin’ on without fear.  No one’s going to take your license away because you skipped a retro.  But I hope this post has helped you think about what it means to be agile and to frame what you’re doing more clearly to yourself and your teams.  Now get back out there and deliver some customer value!

What If Your Scrum Team Was Funding You?

(This one’s addressed at Product Owners or anyone who is from the “business side” of a company. Not the “business end”; that’s something else.)

money growing in soil

Convince your team like you’d convince an investor and you’re onto something.

Teams Will Build What You Ask … Useful or Not

When I think of what I love about Agile and Scrum, I think: self-organizing teams, empowerment, creativity, customer collaboration (over contract negotiation!), no titles for development team members, exploration, experimentation, ownership … all things that assert or strongly imply that the development team is the beating heart of the whole enterprise, and that the rest of us exist to support them and enable them to build great things to delight existing customers and attract new ones. But the team is busy building things, and there are business-minded folks who spend more of their day thinking about what to build next and why, so even with the best of intentions many companies start to slip into a pattern like this:

The execs set the goals … then the sales, marketing and product teams meet a lot and decide what to build at a high level … then the product owner and business analysts meet a lot and decide what to build at a detailed level and in what order … then we tell the development team what to do.

But we know we should empower the teams, so we give them some business context during planning or grooming, or occasionally do “innovation time” or let developers tag along to user feedback sessions.

Which is great. But.

If you give the team useless features to build, they are going to build them just like they’d build amazing useful fantastic great features if you’d thought of those instead. They are going to negotiate scope during sprint planning and then Commit and gosh darn it, they will burn those 35 story points of useless crap down to Zero with Zero Defects and every Acceptance Criterion will be checked off. They might not enjoy it, but you’re paying them a lot of money and they all went through grueling technical education and they are predisposed to write code and write it well. But guess what? They probably have ideas about what you should build, and questions that go beyond story grooming, but unless you have a phenomenally open work culture and great communication (good for you!) then those ideas may not be getting enough sunlight and so you’re missing out, and so are your customers.

Let’s Pretend

So let’s pretend for a moment that the development team has all the money. One developer won the lottery, another comes from old money, and the QA lead has reaped the benefits of 3 straight IPOs. But for some reason they all keep working and they’re funding your company. I know, it makes no sense … suspend that disbelief like when you watch those superhero franchise movies.

Everything else is the same as the real world. The Product Owner ranks the backlog and brings the stories to the team to size and refine, and then the team commits to the most important work. Except now when you introduce a new feature to the team, you have to start by convincing them to pay for it:

You: “So, we need to integrate with Yawp’s restaurant review platform.”
Developer: “Interesting feature, Bob. Tell me why I should spend my valuable time and money building this.”
You: “Well, we have a partnership with them and …”
Developer: “But won’t people just go directly to Yawp instead of going through our app?” (glances at smartphone)
You: “We don’t think they will … I really …”
Developer: “Do you have any data to support this hypothesis?” (looks distracted, grins at tester)
You: (flustered) “Well I could get something together.”
Developer: “Great, get back to me when you have something.”

and … scene. Ouch. Truly the darkest timeline.

But Seriously

If you were able to sell – I mean really sell – your feature to the development team, how committed do you think they’d be? Would they put in that extra effort to get over the line? Sure they would. How likely would they be to just deliver you something “pretty good” that is technically correct but just doesn’t wow you? Not very, right? After all, it’s their money riding on the outcome.

And what do you think they’d do if they had a different idea, maybe even a better idea? You know that one: They’d be sure to tell you and you’d listen! If you have money, people listen whether the ideas are good or not 🙂

*poof*

Well, we’re back in the real world. Phew! Shake it off, Taylor Swift, it wasn’t that bad. No one is really going to force you to sell the team on the value of your features. But you really should, shouldn’t you?

bored developers

If your team isn’t sold on the value of the work, it’s your job to convince them.

Decomposing Product Owners

Despite the title, this has nothing to do with a horde of zombie product owners shuffling through the streets in search of Scrum teams.  I want to talk a bit about how Scrum defines the Product Owner role and how this can differ from real-world product ownership.  Specifically, let’s look at the responsibilities of the Product Owner and think about how organizations might end up handing parts of the role to someone else, and what the effects might be.  Finally, I’ll talk about how we might influence an organization to move towards defining more by-the-book Product Owners, or failing that, how we might ensure that the people who together compose the role are at least working together effectively and presenting a unified face to their teams.

Wait … Who Is The Product Owner?

Several years ago I did some basic Scrum training for new Scrum Masters in an organization.  Scrum was up and running within the team, but I saw some possible dysfunctions, so I structured the training like this:   First, I would explain some role, ceremony, or artifact as I understood it, including the value added by it; then, I’d ask the new SM to compare that definition to what he or she saw within the team.  Was everything A-OK or were there differences?  For any differences, did they represent a conscious choice to improve the process a la the “ha” of “shu-ha-ri”, or were they problems to be solved?

We were chugging along and generating insights until … we got to Product Owner.  I talked a bit and presented a basic list of PO characteristics like this:

  • Owns the product backlog and works daily to refine it
  • Understands the market and where the product is going
  • Provides clarity of purpose to the team: sprint goals, release plans, etc.
  • Is available to the team on a daily basis
  • Respects the team’s focus during sprints

I should note at this point that the organization had classic Product Managers who had received some general Agile and Lean training and had been given the PO role, but retained the original PM title.  In addition, there were business analysts who worked in the backlog and did grooming with the teams, plus a Project Manager overseeing the various teams, functional managers, and a UX lead who had probably the most frequent and detailed contact with users (If you’re in a large company that started waterfall and then went Agile, this may sound familiar).

Anyway, at the end of this brief summary of the Product Owner role I asked a budding Scrum Master, “So, based on this, who would you say is our Product Owner?”

(pause … gears turn)

“Um … I dunno … [names Project Manager]?”

Well that’s not ideal, is it?  We had a couple of PMs who clearly owned the product and prioritization, and teams of developers and testers who were more than a bit fuzzy on how the various business-facing roles work.  As you might imagine, I observed quite a bit of churn around prioritization, requirements, and vision.  And not the good kind of churn: no homemade butter was produced.

All of the people in this story were smart and dedicated and had a pretty good relationship with each other, but somehow the teams were performing less than optimally.  They generally got the requested work done, but the creative spark and exuberant collaboration you’d hope to see in a Scrum team was not quite there.  So let’s look a bit more at how the Product Owner role can be delegated or diluted and what that might mean.

Product Owner vs. Product Manager

A lot has been written on this topic, so I won’t linger too long here, but I like to see Product Owners who operate close to the metal: They’re in the grooming meetings, they know the agile tools (JIRA, Rally, TFS), and they roll up their sleeves to rank a newly found bug against the upcoming stories.  The farther up the pyramid they are in the company, the less time they tend to spend rubbing elbows with the team, and that can lead to a “development versus business” mentality where the development teams feel like “they” pressure us into unreasonable commitments, and the product management organization feels like the team is not fully committed and is disconnected from the business’ needs (probably because they are!).

Just like some teams tend to place the Scrum Master hat on a tech lead, it’s tempting to give the Product Owner title to a relatively high-ranking person.  That’s not really necessary though; the PO just needs to have enough delegated authority to make priority calls as they arise.  Much more important is the physical and/or mental proximity to the team, and the ability and desire to rank work at the story and bug level.

Product Owner vs. Business Analyst

Product Owners have a tough job.  They’re expected to really understand customers and the market, which probably means flying to conferences, sitting in marketing calls and user feedback sessions, and the like.  But they are also supposed to show up for Scrum ceremonies, dig into the minutiae of the backlog, and keep up with the progress of the current sprint.  How is that possible?  I know that when I was a development manager and took on the PO role on top of that I spent at least 2 hours a day, every day typing stories into JIRA, writing acceptance criteria, and creating mockups … all before customer meetings, strategy sessions, and more.  I made myself very approachable to the development team, and they had questions.  Boy did they have a lot of questions.

Given all this, some companies hire business analysts to handle the detail work of breaking features into stories, writing out acceptance criteria, and the like. But the BAs typically don’t have authority to prioritize the work or make calls on functionality.  If they are the ones doing grooming sessions with the teams, that means there’s a lot of “let me get back to you on that” or “I’ll run that by [product owner].”  This doesn’t have to be game-breaking, but it’s a slower feedback loop than direct PO-to-team discussion, so it’s something to watch.

Product Owner vs. True Power

By “true power”, I mean “who really makes the calls?”  Is it the VP of Product Management?  Senior Product Owner?  Someone in the development organization?  Sales?  One of the Product Owner’s key jobs is to manage directional push coming from anywhere inside or outside the organization.  Unless the PO is also the CEO (not likely), that means he or she needs to absorb all those wants and needs and make sure the backlog paints a true picture of what is most likely to be coming up next.  If those with true power are going around the PO and setting other priorities for teams, it creates confusion and disorder.  It’s up to the PO to manage stakeholders and keep that from happening.

Out of Many, One

Let’s finish up by going back to the anecdote of the budding Scrum Master who couldn’t point to a single person who met the criteria of Product Owner.  What could we do to fix this? It might not be feasible to snap your fingers and realign the job responsibilities of the PO, BA, UX, and/or project manager, but small changes can make things a bit more clear.

The Product Owner should articulate the product vision to the team every sprint.  If the PO isn’t available every day, he or she should show up to sprint planning with a compelling story about what the team is building and why.  This shouldn’t take long and provides the purpose the team needs to get energized.

The Product Owner should delegate some authority.  An engaged development team has a constant stream of questions for the Product Owner.  If the PO can’t commit to same-day responses on most questions, he or she can delegate (to a BA or other proxy) to give the team a better contact point.  But this person needs to have some true power to make decisions that won’t get revoked as soon as the PO is back in the office.

The Product Owner should review stories for the current sprint early and often.  I’m assuming here that the PO shows up for planning and the sprint review – if that’s not happening it certainly needs to.  But the sprint review or demo is too late for clarification.  Even a globe-trotting PO should be able to VPN into the test environment from the road and play around with features that are under development, so that small corrections and clarifications can be made in flight.  The team can facilitate this by adding “Product Owner has had the chance to review the work” to the story-level Definition of Done and proactively notifying the PO when stories are up and working.  Note the wording– “has had the chance” means the team offered the work for review, not that the team waits for the review to close the story.  If the PO doesn’t get to it and gets a nasty surprise at the sprint review, well … revisions go in the next sprint.

Present a united face to the development team.  This is the most important.  A PO who has other people helping to guide the work for the team owes the team clarity on how all the roles fit together.  This means frequent repetition of whatever arrangements have been made:  “Hey everyone – I’m going to be at the Business Success Summit next week; I’ve asked Susan to handle any UI questions or priority calls.”  Ideally the PO and friends also appear together at key points.  It might be obvious in the PO’s head, but standing in front of the team along with the business analyst/project manager/whoever and saying “yes, this is the vision; yes, we are all in agreement” can be very powerful.

In Closing

I hope this has been helpful.  I truly believe having a single product owner who ticks all the PO boxes is the best and simplest arrangement, but I realize that in the real world the PO is sometimes decomposed into several individuals.  Think about whether any of the tensions and variations above match your current situation, and what you might do to move things back toward the ideal.  There’s power in realizing that problems exist, and if you can see them, it’s a good bet that others do too and that you can rally together to overcome them.