Scrum buts » but Scrum - which is worse?

Scrum buts » but Scrum - which is worse?

The term "scrumbut" could mean:
1. A person engaged in only partially Agile project management or development methodologies
2. One who engages in either semi-agile or quasi-waterfall development methodologies.
3. One who adopts only some tenents of the Scrum methodology.
4. In general, one who uses the word “but” when answering the question “Do you do Scrum?”

ScrumButs are reasons why teams can’t take full advantage of Scrum to solve the problems and realize the benefits.

But Scrum ...
- Yes, these are bad situations. But let's look at the flipside - let's look at 'But Scrum.'
- 'But Scrum' is when a person/team/organization flips off their 'thinking bit' and just burps up whatever Scrum tells them to do.

A5111c7645bdd0c23244f8c1aa6f8296?s=128

Fabio Armani

June 09, 2015
Tweet

Transcript

  1. ScrumButs » but Scrum Which is worse?

  2. scrumbut [skruhmbut] noun 1.  A person engaged in only partially

    Agile project management or development methodologies 2.  One who engages in either semi-agile or quasi-waterfall development methodologies. 3.  One who adopts only some tenents of the Scrum methodology. 4.  In general, one who uses the word “but” when answering the question “Do you do Scrum?”
  3. ScrumButs § ScrumButs are reasons why teams can’t take full advantage

    of Scrum to solve the problems and realize the benefits. § Every Scrum role, rule, and timebox is designed to provide the desired benefits and address the problems. § ScrumButs mean that Scrum has exposed a dysfunction that is contributing to the problem, but is too hard to fix. § A ScrumBut retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of the team.
  4. ScrumBut ≡ Quick Fixes The problem arise when we try

    to use quick fixes to adjust the process.
  5. ScrumBut syntax § A ScrumBut has a particular syntax: (ScrumBut) (Reason)

    (Workaround) § Example: “(We use Scrum, but) (the daily Scrum meetings are too much overhead) (so we only have them once a week, unless we need them more often)”
  6. "We're doing Scrum but..." § our sprints are 6-8 weeks long

    ... § we do two normal sprints and one bugfix sprint ... § we do all our planning up front ... § we skip the daily meeting ... § our managers decide what's in each sprint ... § we haven't read the books yet ... § our team has 30 people ...
  7. Some ScrumButs to avoid … § Goalless, soulless Scrum § Shooting the

    Scrum messenger § Planning paralysis § Mis-aligned stories § Command and control-style micro management § Individual heroics § Smoke and mirror demos § Lack of risk management § The vicious cycle of overcommitment
  8. ScrumButs can come from many sources § The business doesn’t want

    to be involved § Everyone wants their features first and can’t agree on a priority § Teams don’t know how to self-organize § People aren’t available to work on teams full-time § Timeboxes aren't adhered to
  9. ScrumButs can come from many sources § Teams don’t see a

    need for a daily Scrum § Teams can’t get a piece of functionality done in one Sprint § Teams don’t have the skills to “do” something § Teams can’t fit testing into the same Sprint as development § The ScrumMaster tells the team what to do and how to do it
  10. ScrumButs can come from many sources § Other managers can’t stay

    out of a Sprint § Important things come up that require interrupting the Sprint § The Sprints can’t start until all of the other groups do their up- front work § Other groups are building hardware or using waterfall
  11. Scrum changes § Sometimes organizations make short term changes to Scrum

    to give them time to correct deficiencies. § For example, "done" may not initially include regression and performance testing because it will take several months to develop automated testing. § For these months, transparency is compromised, but restored as quickly as possible.
  12. ScrumBut … § It’s a positive force and an important element

    of the Inspect & Adapt Loop
  13. But Scrum … § Yes, these are bad situations. But let's

    look at the flipside - let's look at 'But Scrum.' § 'But Scrum' is when a person/team/organization flips off their 'thinking bit' and just burps up whatever Scrum tells them to do. § Want some examples?
  14. Yesterday I zoodled Today I’ll zoodlle No problem Yesterday I

    zoodled Today I’ll zoodlle No problem Yesterday I zoodled Today I’ll zoodlle No problem Scrum Zombies …
  15. But Scrum says we estimate § I have personally been around

    agile teams that don't estimate all of their items in their backlog. Why? Multitudes of reasons. § A couple of examples: §  Teams break down their work far enough (day range) where the variance in the estimates would be minuscule. §  A team works really well together and can accurately predict how much they can get done, without worrying about points
  16. But Scrum says we need self- organizing teams § Yep, self-organizing

    teams would be awesome. There is a magic dashboard of work on the wall and people will just naturally float over and create uber teams to crush out work. § Most large organizations are still structured in classical, matrixed manner. Telling their IT departments to 'self- organize' is irresponsible. § Most people multi-task. Is it a problem? Sure. Is it a reality? § You betcha. Specialization is an output from our national hiring structure - just look at any job boards for confirmation. Good luck changing that inertia.
  17. But Scrum says we need a ScrumMaster § By no means

    do I have hard numbers to back this up, but look at it this way: If Scrum masters were making agile software development and delivery so much better, then given the rate of CSMs being handed out, we should have some bad bamma jamma software coming out from the majority of organizations. § But we don't. I'm not even going to get into the whole certification battle. Little known fact - Patrick Duffy is a Scrum Master.
  18. But Scrum says once we commit, the backlog doesn't change

    § Right, because market events and competition only happen in nice, predictable cycles
  19. But Scrum says our teams should be 7, +- 2

    § There are plenty of Scrum development teams out there working well with a size over 10 as well as split geographically. § A team that works well together is a team that works well together.
  20. Which is worse ? § Which is worse - 'Scrum but'

    or 'But Scrum'? § They are both horrible. One is giving excuses why you can't try and change; the other is giving excuses why you can't change what you are trying. § Both are pointless…
  21. Shu Ha Ri § The reality is developing a software product

    is hard. §  It requires thought, inspection, change, and risk. § You have to think.