What practices are we talking about? 100% pair programming. 100% TDD. One week iterations. Daily pair rotation. Standups every day. Planning meetings and retrospectives once a week. And a fixed 9-6 weekday-only schedule to avoid burnout.
-
Show this thread
-
Pivotal took a page directly from the XP (eXtreme Programming) workbook. Their CEO, Rob Mee, had worked with some of the signatories on early agile projects, and had been putting it all into practice continuously since then.
1 reply 2 retweets 25 likesShow this thread -
I *loved* working like this. Agile is basically a set of attention hacks for me. For example - when I’m pairing I’m not on Twitter or email - all I’m thinking about is the problem at hand. Devs at Pivotal paired 8 hours every weekday, modulo standups, planning meetings, & retros.
3 replies 11 retweets 96 likesShow this thread -
I’d never worked in a way that seemed so likely to produce the _right_ product. That’s the motivator for me - building things that are useful and get used. I’m not motivated by the act of writing code (tedious, error prone) nor by new technology (unless the payoff is clear).
1 reply 8 retweets 105 likesShow this thread -
The agile/XP/Pivotal way of working is not without its issues. But the positives were so strong, relative to my previous experience, that it took me 5 years doing full-on agile to even start to see & articulate & connect the problems.
1 reply 5 retweets 50 likesShow this thread -
So let’s start with the obvious issues: - Very few people can pair that much. My job was essentially talking for 8 hours a day. - Many people can’t do a 9-6 fixed schedule. Parents, in particular, because no daycare place stays open past 6. This is ultimately why I left Pivotal.
8 replies 19 retweets 224 likesShow this thread -
- Many people have motivators that don’t mesh well with this system, including pushing frontiers via more research-y code, being in solo ‘flow,’ & using new technology. - Full-time pairing is hard across time zones. Having everyone in the same time zone is often unrealistic.
5 replies 12 retweets 150 likesShow this thread -
That’s the obvious stuff. Most of it can be solved by employing small-a agile, rather than a program like scrum or XP, so that the process adapts to the needs of the team.
1 reply 5 retweets 60 likesShow this thread -
The way I usually approach this is to have folks articulate what they’re trying to get out of a practice that’s not working for them. Then we brainstorm other practices that might have the same effect AND work better for that group. I’ll give you a quick example.
2 replies 5 retweets 54 likesShow this thread -
When people do pair programming, their goals are usually some subset of these: - focus - avoiding silos - code review - onboarding - cross-training - fewer rabbit holes There are other ways to get all those things.
6 replies 20 retweets 126 likesShow this thread
Sometimes it's just "this problem needs a bigger brain than I have in my head" or "I can see that by myself I'm blinded by bias and need some help to think through the problem", but those situations are not the majority of software dev.
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.