ScrumBut

(You use Scrum, but…)

ScrumButs are reasons why teams can’t take full advantage of Scrum to solve their problems and realize the full benefits of product development using Scrum.”
Let’s talk about the elephant in the room…

First of, I would like to dedicate this post to all the brave Scrum Masters out there, battling organisational defects day in, day out. It takes a lot of courage to be touching the raw nerves, breaking through status quo’s, being the wrecking-ball, opening up rigid mindsets, being radically transparent and exposing toxic politics and powerplays. We’re on a journey to creating better, healthier environments, not just for ourselves, but our legacy too.

Some of you might be operating in an organisation that wants Lipstick Agile only, or companies that hired Scrum Masters, only to then learn they actually don’t want to actually Scrum. Then there are tons of anti-patterns to watch out for.

A lot of times you will feel misunderstood. Even worse: your efforts will be misinterpreted or twisted. You’ll encounter those who are so set to proving you wrong, they’ll create Frankenstein versions of your well-intended initiatives. But unlike others, you don’t settle. You won’t compromise.

Yet, compromises are a dark second nature to Scrum. Every Scrum journey is about dragging the organisation through its own mud.

“Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. 
Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.” — the Scrum Guide.

Most organisations will call the journey towards Scrum, Scrum; this inadvertently will cause Scrum to be associated with all that mud. 
“We do Scrum BUT….”


So I started collecting some of those big buts. Get ready for a rant and the ultimate cringe.

A short disclaimer: some of these might be prone to heated debates; please don’t take these too seriously; there are many different takes one can have on these and a lot depends on context.

Your Scrum organisation might do Scrum but…

General Scrum

Waterfall practices

So you scrum but don’t deliver a working increment?

  • “The client wants a big design up front (BDUF).”
  • “We are doing a pitch first, which involves only design.”
  • “Stories should contain Functional and Technical Designs.”
  • “We’ve already planned the next 6 sprints.”
  • “Our backlog is a requirements document.”
  • “Our backlog is prioritised/organised using MoSCoW and T-Shirt sizes.”
  • “Story points? Sprints? Backlog? Our clients won’t get that. We will just do fixed scope/time/hours contracts.”
  • “I am a [product owner/project manager/agile coach/ scrum master/business developer/account manager/program manager/portfolio manager/team manager] (choose all that apply).”
  • “Let’s do a [Design Sprint, Sprint 0, Architecure Runway, Pre-Sprint, Discovery Sprint, Planning Sprint].”
Evil Agile terminology facade

Not multi-disciplinary

  • “The Development Team only consists of software developers.”
  • “Our [QA/Design/UX/Architecture/IT] (or insert any other SILO here) team [….]”
  • “I am a [designer/developer] so I will only [design/develop].”
  • “[Johnny] will work on story [X] alone, because he alone can.”
  • “Two developers on one task/story? that’s way too inefficient.”

Our management doesn’t (not self-organising)

  • “We can’t trust the team with authority to self-organise yet.”
  • “We don’t involve the team in making initial offers to clients.”
  • “We’ve already told/promised the client that…”
  • “The Product Manager is the Product Owner … but then so is the client….. and all their stakeholders. In fact… who ever contacts our management will get priority.”
  • “When the Product Owner declined [x], the client/stakeholder tells management to tell Product Owner that […]”
  • “[Jenny] is the Product Owner, but she will need to get an approval from management before she can […]”
  • “We (management or PO) will just put [urgent request x] on the Sprint Backlog.”
  • “Developers shouldn’t interact with the [client/user/stakeholder] only the [Scrum Master/Product Owner].”
  • “We’ll just tell the team to […]”
  • “Management tells Team B to do whatever works for Team A.”
  • “We’ll prioritise our work by which stakeholder is most angry/upset/vocal/frustrated/likely to contact management.”
  • “Estimating with the team is inefficient.”

The routine

  • “We just have daily scrums.”
  • Scrum events take too long…
  • “The Sprint can’t start because [x] is not clear.”
  • The Sprint will take longer because [y] is not done.”
  • “Our sprint is 6 weeks long.”
  • “The Sprint can’t start because not all items in previous sprint are done.”
  • “The team hasn’t delivered its commitment, so they have to work overtime.”
  • “The Sprint Review can’t start because the team isn’t finished.”
  • “Coaching/training should be done in during Scrum events… or how about late night pizza sessions?”
  • “Use the retrospective time to fix issue/do task.”
  • “The estimate is too high! a. Its just copy paste right? b. you’ve done something similar before right?”
  • “I need [more info] before I can [start].”
  • “Person [x] is not here, so there is not point to have [insert scrum event here]”
  • “We should have a meeting about [….]”

The metrics

  • “The team’s velocity is not increasing so they are not improving.”
  • “We’ll add more capacity to increase velocity to meet client’s demand.”
  • “We can’t wait for team estimates: the client wants ballpark figures today.”
  • “Estimates are deadlines.”
  • “Estimations are done only by the [Solutions Architect/Business Analyst/Senior Developer].”
  • “We don’t have time to do estimations.”
  • “Our burn-down chart looks more like a burn-up chart.”
  • “Our burn-down only burns-down on Friday.”
  • “We use commitments, instead of forecasts.”
  • “Story Points=hours right?”
  • “How many hours is a Story Point?”

Resisting change

  • “We’ve always done [x] this way …”
  • “We shouldn’t try to change [current way of working] now.”
  • “I will only do [tasks] that have been defined in [tool x]according to [format y].”
  • “I am [senior], so I don’t have to do [mundane tasks].”
  • “We can’t start (work on story/sprint) because we don’t have all the details.”

Tooling

  • “We don’t need physical whiteboards/scrum boards because we use Jira.”
  • “We use Jira ergo, we are Agile.”
  • “The teams all MUST use Jira.”
  • Jira.” (yes it deserves its own ‘but’)
  • “We can use Skype so we don’t really need get together.”
  • “The client reports a ticket in discovery tool [A], with links to tool [B] which includes attachment from tool [C] which we then [copy/synch] to tool [D] where we refine them before they move to the Scrum teams tool [E] and developers then create tasks in tool [F] but also keep track on them on the post-it wall.”

Practices

  • “We all talk about automated testing but never really apply it. We don’t do manual testing either because it should be automated.”
  • “Which of these fourteen Sprint Goals should we do first?”
  • “This is only 15 minutes work, so no need to go through all the DoD’s right?”
  • “Learning/training?! do it in your own time.”
  • “We don’t do any documentation because the Agile Manifesto says so.”
  • “We don’t have time to work on technical debt.”

Spikes, Stories, Definitions of Done

  • “A Story is the same as Product Backlog Item, right?”
  • [Johnny] added criteria: “Conversion increases by [insert randomly made up percentage here].”
  • [Jimmy] added: ‘etc’.
  • [Jenny] added: ‘See attached powerpoint.’
  • [Johan] added criteria: ‘Must be live this evening!’
  • [Jacob] added: DoD: ‘The [product owner/user] likes it.’
  • [Jessica] added: DoD: ‘There are no bugs/defects.’
  • [Joanna] added user story: ‘As a product owner I want a green buy button so conversion goes up.’
  • [Jill] added user story: ‘As the marketing department we want SEO we we get more exposure.’
  • [Jaimie] added user story: ‘As the marketing department we need the email blast to go out this afternoon.’
  • [Jason] added bug: ‘The system is missing [never mentioned before feature], it should have gone without saying this should have been part of [x], please have it ready by [tomorrow]!’
  • [Jessie] added user story: ‘Oh, just one more thing […]’

Missing any?

Just drop yours below in the comment!

Ready for more?

Liked this article?

Please clap 👏 . and share the article!