View stunning SlideShares in full-screen with the new iOS app!Introducing SlideShare for AndroidExplore all your favorite topics in the SlideShare appGet the SlideShare app to Save for Later — even offline
View stunning SlideShares in full-screen with the new Android app!View stunning SlideShares in full-screen with the new iOS app!
scrumbut [skruhmbut] noun1. A person engaged in only partially Agile project management or development methodologies2. 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 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.
ScrumBut ≡Quick FixesThe problem arise when we try touse quick fixes to adjust theprocess.
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)”
"Were 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 whats in each sprint ... we havent read the books yet ... our team has 30 people ...
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
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 arent adhered to 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
ScrumButs can come from many sources Teams can’t fit testing into the same Sprint as development The Scrum Master tells the team what to do and how to do it 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 have them once a week, unless we need them more often)”
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.
But Scrum … Yes, these are bad situations. But lets look at the flipside - lets 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?
Scrum Zombies …Yesterday I zoodled Yesterday I zoodled Today I’ll zoodlle Today I’ll zoodlle No problem No problem Yesterday I zoodled Today I’ll zoodlle No problem
But Scrum says we estimate I have personally been around agile teams that dont 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
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.
But Scrum says we need aScrumMaster 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 dont. Im not even going to get into the whole certification battle. Little known fact - Patrick Duffy is a Scrum Master.
But Scrum says once we commit, thebacklog doesnt change 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 dont. Im not even going to get into the whole certification battle. Little known fact - Patrick Duffy is a Scrum Master.
But Scrum says once we commit, thebacklog doesnt change Right, because market events and competition only happen in nice, predictable cycles
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.
Which is worse ? Which is worse - Scrum but or But Scrum? They are both horrible. One is giving excuses why you cant try and change; the other is giving excuses why you cant change what you are trying. Both are pointless..
Final thoughts The reality is developing a software product is hard. It requires thought, inspection, change, and risk. You have to think.