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
 

Keep Current with Allen Holub

Allen Holub Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @allenholub

31 Aug
I'm thinking about backlog refinement today. First, what does "refinement" mean? IMO, "refinement" is the process of adding stories, removing stories, changing priority, etc. It is NOT adding details to stories. That's just premature up-front design. 1/4
Some PO sitting in front of Jira adding details to stories is NOT refining the backlog, they're designing the implementation. Backlog refinement is an ongoing process because you're constantly learning new things about the connections between stories (and their value). 2/4b
That is, given that you're always discovering new stories and learning new things about existing ones that impact their value, modify the backlog by adding/removing/moving stories as soon as you learn so that you don't forget. Refinement is a process, not a meeting. 3/4
Read 4 tweets
26 Aug
What returns the biggest bang for the buck in Agile? That comes from doing the things that many companies resist the most. Trust the teams to do their work—no more monitoring "productivity;" no more asking for permission. 1/4
Give the team full autonomy to meet strategic objectives, including control over how they do their work and the tools they use (and if that involves doing something other than Scrum and/or dumping Jira, fine). Support them when they need organizational changes. 2/4
Encourage and suport direct communcation with customers. Make them fully cross functional and give them control from idea to deployment. Create a culture of learning and psychological safety across the org. 3/4
Read 5 tweets
21 Aug
We've all seen the "iron triangle" (cost, scope, time). If all three are fixed, your project is a death march to failure. The usual joke is "pick two." 1/5
The fourth factor, quality, is implicit becuase the people who came up with the metaphore actually belived that high quality was not negotiable. We all know how that worked out. However, the presence of quality actually renders the whole triangle thing untrue. 2/5
High quality is more a matter of culture and training than time. It takes no more time to produce quality code, it just takes knowledge of how to do that. High quality also shortens development time. 3/5
Read 5 tweets
16 Aug
The very notion of a "project" implies that somebody, elsewhere, has decided what's valuable, and that the team must accept that assessment. That is, if you have a project, then someone in management has decided that project is valuable enough to assign the work. 1/5
Imposed assignments from outside cannot reflect the current needs of the customers right now becuase there's an implicit time lag as the "project" moves though the system. The fact the decision was made elsewhere increases the odds that the work definition is stale. 2/5
The whole idea of a "project" works against your agility. 3/5
Read 5 tweets
9 Aug
The idea of testing being separate from dev comes, I think, from a few false assumptions (and is tightly coupled with waterfall thinking). The first assumption is that testing is a lesser art than programming. 1/9
You can’t waste the time of those highly-paid developers doing something as mundane as testing, so let’s throw the tests to low-paid “testers.” 2/9
That naturally leads to thinking of “testing” as a separate skill from development rather than being an integral part of it, and that leads to thinking that “testers” have some magical ability to see things and think of issues that the developers can’t conceive of. 3/9
Read 9 tweets
6 Aug
Organizations are Agile, not teams or departments. The metric that matters is the rate at which you get value into your users hands. That involves the entire "value stream," which encompasses every step an idea goes through from conception to delivery (& maybe after). 1/4
People want to focus on the engineering teams and "Agile" because that's easy, but the engineering teams are rarely the main obstacle to delivery. 2/4
Accounts Payable and Receivable are also very much part of the value stream (along with the approval processes that an invoice or purchase decision has to go through). 3/4
Read 4 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!