Under a process like this, of course we game it. We move the “immovable” definition of finished when no one is looking. We work extra hours.
-
Show this thread
-
Imagine instead it’s the CEO’s job to set expectations with customers about when it’ll be available, based on how long it’s actually taking.
2 replies 5 retweets 60 likesShow this thread -
They can set an arbitrary date, but then it’s their job internally to negotiate a definition of done that will meet it. Without crunch time.
1 reply 7 retweets 49 likesShow this thread -
Yes, setting realistic dates & doing this internal negotiation is an art, and hard to do right all the time.
2 replies 6 retweets 59 likesShow this thread -
The important part is that the risk is shouldered by the whole organization, instead of solely by the individual developers.
4 replies 18 retweets 106 likesShow this thread -
Replying to @sarahmei
Fascinating. I wholeheartedly agree with this, but wouldn't have thought of this as a heuristic. Usually corps that try to make individual devs shoulder the risk fundamentally don't trust devs ("how will we know if they're doing work without
#accountability")3 replies 6 retweets 20 likes -
I've been using a "every task/project is assigned to at *minimum* two developers" policy for a few years. It's amazing how even that small tweak changes things.
7 replies 19 retweets 70 likes -
I find the very interesting. What kind of changes did you see as a result?
1 reply 0 retweets 1 like -
Replying to @HeroicEric @sarahmei
Mostly a big reduction in "blame" and a bigger sense of shared responsibility. There's less of a reliance on individual heroics, and there's almost never a point where a single person can be "blamed" for a mistake. The shift away from blame-based team dynamics is profound.
1 reply 2 retweets 18 likes -
I I wonder if that's part of the reasons why Pivotal does pairing all the way. I'm not sure because it's the first time that I read it; and of course it makes a metric ton of sense. Thanks for sharing!
1 reply 0 retweets 0 likes
I think Pivotal-style pairing has problems: not every problem is appropriate for pairing (although many are) and not every developer thrives in a pure pairing environment. I find that assigning tasks to pairs and letting them decide on work style ...
-
-
still results in a lot of pairing, but not 100%. But it still has a lot of the benefits around avoiding a "blame" based culture.
1 reply 0 retweets 1 like - 2 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.