My friends who are Scrum trainers seem to be getting more and more annoyed with fake Scrum—a twisted perversion that people think is Scrum but isn’t—not at all what the Scrum Guide says or what they teach. 1/4
In other words, the same destruction of meaning that happened to "Agile" has happened to "Scrum." Even certification doesn’t seem able to stop that decay—you’d think it would slow the entropy down a bit at least, but it doesn’t. 2/4
Even the certified ppl ignore what they learn to get certified & descend into fake Scrum. People seem determined to twist things around to look like whatever’s familiar to them. Maintain the status quo at any cost, even when the status quo is a sh**t show that nobody wants. 3/4
This change stuff is _hard_. 4/4
• • •
Missing some Tweet in this thread? You can try to
force a refresh
You reward "high performers" on the team. Performance goes up! Do it again. Performance goes up, but not so much. Do it again. Performance goes down. So, reward the high performers even more! Performance plummets. What’s happening?
In systems-thinking terms, we’ve been looking at the "reinforcing loop." People who aren’t being rewarded have a loop of their own that you’re not seeing, however—a "balancing loop."
Somebody else gets rewarded even though their work doesn’t seem to justify that. Grumble and put up with it. They get rewarded again! Now I’m getting angry. And again! Why bother to put any effort into this job at all?
There are better ways to plan than estimates, and that applies to all sorts of estimation, including "velocity." However, getting a manager to stop demanding them is another issue entirely. The problem is not the estimates.
A company that’s project, rather than product, focused will demand estimates, but the problem there is the project thinking, not the estimation.
Similarly, a company with the sort of management that demands estimates (or accepts clients that demand estimates) is also probably not particularly agile friendly, so that issue has to be addressed. These are all very hard problems, of course.
Don’t make a story smaller by "splitting" it into a front-end and back-end piece. That’s called "horizontal splitting," & it’s never a good idea. The problem is that you’re not done until you deliver value to your customers. 1/4
Horizontal splitting does nothing but delay value delivery, so it’s not really splitting at all. It’s an anti-pattern. You want to narrow scope instead. 2/4
Look at your story. Every variable (every choice, every option, every place that something can change the outcome) is a different story. Replace all variables with one constant. That’s a story. Change a constant. That’s another 3/4
When you work in a mob and people come and go during the course of the day, you have to decide how to handle disagreement. 1/5
The easiest path is to just trust everybody else to make good decisions and have a working agreement that says that you'll abide by those decisions if you weren't there, even if you disagree. Everything’s an experiment, after all. 2/5
Worst case it that you have to redo something. If you work in the small, the consequences of that are also small. 3/5
IMO, becoming "Agile," whatever that is, is not a worthy goal. Our goal is to be a successful business, and doing that usually involves providing valuable software to our customers sooner rather than later.
A goal of "doing Scrum" or "becoming Agile" is just a distraction (as compared to a goal of solving our customer’s problems or achieving strategic ends or improving our organization).
Inappropriate goals create massive disruption (e.g. as an army of Scrum or SAFe trainers run roughshod over the organization) and usually solves none of the most pressing problems that the business has.
A common flaw in stories is the form "Someone <in role X> wants to do <some task>" I’m happy for them. Glad they want to do that 😄. The story, however, describes what they actually do in the domain. "Someone <in role X> does <some task> because…"
Or better yet: "In order to <get this valuable result>, someone <in role X> does <this domain-level activity>."
Don’t make that a required template, though. When it comes to stories, templates (especially the Conextra template) are _never_ a good idea, IMO.