Was asked "Can Scrum Master be held responsible if development team is not delivering on time?" The whole notion of "delivering on time" flies in the face of basic Agile thinking. "On time" means that you're matching an estimate of a detailed up front plan. 1/5
Detailed up-front plans are the opposite of agile thinking. Teams learn as they work. The things they learn often "slow them down." If, for example, they learn that it's not worth building the thing they're working on, they'll stop working on it. 2/5
They won't deliver that thing at all, much less "on time." Do you really want to punish somebody for not wasting the company's money building something that nobody wants? 3/5
Holding the "SM" "responsible" is even more of a dysfuntion. First, it is NOT the SM's job to keep the team "on schedule," so it's like holding your accountant responsible for a plumbing problem. An SM is ***not*** another word for "project manager." 4/5
More importantly, a culture of blame and punnishment will destroy any agility you may have. Agile systems are built on respect and trust. I see neither in the notion of "holding an SM responsible for delivering" something of dubious value on somebody else's schedule. 5/5
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I don't believe that "bugs just happen." They are written by people. Sure, people make mistakes, so if you really want to reduce bug counts, work in a way that catches those mistakes early, 1/6
and also create a deployment system that recovers quickly and gracefully if any slip through. E.g., with mob/ensemble programming, you have multiple pairs of eyes reviewing the code as it's written (a 1-on-1 code review performed after the code is done doesn't do that). 2/6
A no-known-bugs-on-release policy helps people focus on quality. TDD introduces tests so early that bugs tend not to be in the code to begin with, and running those tests every few minutes or so makes them easy to fix when a test fails. 3/6
Some thoughts on retros (and a much longer thread than is my wont—sorry). A poll over on LinkedIn asked, "How long does it take you to prepare and create a retro?" There's an entire thread talking about the destructive implications of that question, so let's do that! 1/15
IMO, a retro is a conversation focused on improvement, maybe triggered by something not working or going wrong in the recent past. You don't plan how to converse; you converse. The conversation happens continuously as you work. It is not a meeting. 2/15
The process of continuous improvement is just that—continuous. It is not an event. 3/15
There are two approaches to making projections for business purposes. The one to avoid is estimation based on specification analysis. Unfortunately, that's what most ppl use, and it pretty much always fails because an up-front specification is invariably wong. 1/5
You need to deliver something and get feedback to validate the spec. Constant reestimation as you learn is both wasteful, and equally futile. More to the point they're useless for business projections given that they constantly change. 2/5
So, instead of making projections based on specification analysis, make projections based on flow metrics like throughput (stories completed per unit time) or lead time (time from initial idea to delivery). 3/5
People talk about mob/ensemble programming being intense and exhausting, but when I hear that, I think there may be something wrong with your process. Personally, I find mobbing relaxing. So, here are a few must-dos 👇 1/6
(1) You can't mob without psychological safety—if you feel like you can't speak up, even if nobody else has your opinion, you don't have any. Speaking up should be a stress-free activity. Mobbing should be like a relaxed dinner with friends, not a cage fight. 2/6
(2) People flow in and out of the mob constantly. If you're feeling overwhelmed, take a walk. Ofc, to do this, you can't be the only person in the mob with an essential skill, so teach others your skills! 3/6
I occasionally hear people diss mob/ensemble work on the grounds that they're "introverted." I'm a hard-core introvert. I love mobbing, as do many ppl I talk to. So maybe, the problem is in understanding what an introvert is. 1/5
I like Susan Cain's take on introversion (her book "Quiet" is worth reading). It's all about the need (or not) for stimulus. I hate large, noisy parties & restaurants. I'd rather relax over dinner with a few friends. 2/5
I don't need much stimulus, so I can focus well for long periods of time. I have no desire to bungee jump 😄. I speak in front of large groups of people all the time (I am not shy), but I recover in a quiet place, ideally with a few friends, but on my own if necessary. 3/5