I'm going to ignore the high levels of content marketing here and share my favorite trick: minimize work-in-process.
At my last startup, we limited WIP (that is, the number of open tasks) to be smaller than the number of developers. You can see a picture of our task board here:
This was great. It really forced us to focus and collaborate. It helped management to accept the true capacity of the team, preventing them from flooding us with requests. It also let us get things done at a lively pace, creating a continuous sense of progress that built trust.
I've visited so many teams that have a dozen things going on at once, which leaves everybody scattered. Especially when people then sneak in another dozen "unofficial" requests because they have learned not to trust the main work queue. And then another dozen urgent bugs, most of which happened because of the chaotic work environment, because nobody has enough time to focus and do something right.
In some: if you want to get more done, do fewer things. And then fewer things still. It seems crazy, but it works.
Someone is from an industrial environment. Work in process, in the form of partially complete goods, is a curse of badly organized factories. It's more visible in a factory environment; you have to walk around the stuff on the shop floor. It also costs real money - you've bought the parts, but can't sell the product yet.
One form of limiting work in progress is this: if you want reliable software, insist that no new features go in until all the reported bugs have been fixed. A weaker form of this is to have a master branch, which gets bug fixes only, and a development branch, into which new features go. Merging can happen only when there are no open issues in the master branch.
This is the opposite of "shit early, shit often" development.
Spot on. The best team I ever worked with used Pivotal Tracker. When you delivered a story, you picked the next story off the top of the backlog. No cherry picking of stories.
We paired on all but the simplest stories. You were constantly learning new tricks from other devs and since you could only take from the top, you quickly got a taste of most of the major components of the system.
In short, you could actually take a fucking vacation because there's no longer the situation of being the only designated "backend guy". Everyone had some backend experience.
Very insightful and well stated. Doing fewer things is a great way to define focus. Too many tasks in progress seems to lead to cognitive drain, perhaps due to all the context switching.
I apologize if this is too far off-topic, but all this talk of "focus" lately keeps reminding me of A Deepness in the Sky, by Vernor Vinge, where a much more sinister (and more sci-fi) version of it is called exactly that - they forcibly "Focus" a group of people into the office equivalent of slave labor.
Haven't read it, but would highly recommend Cal Newport's book on the same subject. Made me really think about how I spend down time and it's affect on my ability to focus when I really need to.
just put everyone in a big bullpen, and make sure everyone sits as close together as possible for maximum collaboration -- that's basically what deep focus is, right? bonus points if you're right next to a heavily traffricked walkway, which will foster 'drive-by testing', or something. another CTO was telling me about drive-by whatever-it-was at the CTO conference in Hawaii that I attended last week. good stuff.
[+] [-] wpietri|9 years ago|reply
At my last startup, we limited WIP (that is, the number of open tasks) to be smaller than the number of developers. You can see a picture of our task board here:
http://williampietri.com/writing/2015/the-big-board/#toc4
This was great. It really forced us to focus and collaborate. It helped management to accept the true capacity of the team, preventing them from flooding us with requests. It also let us get things done at a lively pace, creating a continuous sense of progress that built trust.
I've visited so many teams that have a dozen things going on at once, which leaves everybody scattered. Especially when people then sneak in another dozen "unofficial" requests because they have learned not to trust the main work queue. And then another dozen urgent bugs, most of which happened because of the chaotic work environment, because nobody has enough time to focus and do something right.
In some: if you want to get more done, do fewer things. And then fewer things still. It seems crazy, but it works.
[+] [-] Animats|9 years ago|reply
One form of limiting work in progress is this: if you want reliable software, insist that no new features go in until all the reported bugs have been fixed. A weaker form of this is to have a master branch, which gets bug fixes only, and a development branch, into which new features go. Merging can happen only when there are no open issues in the master branch.
This is the opposite of "shit early, shit often" development.
[+] [-] aantix|9 years ago|reply
We paired on all but the simplest stories. You were constantly learning new tricks from other devs and since you could only take from the top, you quickly got a taste of most of the major components of the system.
In short, you could actually take a fucking vacation because there's no longer the situation of being the only designated "backend guy". Everyone had some backend experience.
[+] [-] lockedoutwhoops|9 years ago|reply
[+] [-] drvdevd|9 years ago|reply
[+] [-] zipfle|9 years ago|reply
[+] [-] brian-armstrong|9 years ago|reply
[+] [-] borkabrak|9 years ago|reply
Great read.
[+] [-] therusskiy|9 years ago|reply
[+] [-] zlalanne|9 years ago|reply
https://www.amazon.com/Deep-Work-Focused-Success-Distracted/...
[+] [-] IpV8|9 years ago|reply
[+] [-] alexmorenodev|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] thefastlane|9 years ago|reply
[+] [-] maxxxxx|9 years ago|reply