Improve Team Efficiency with Lean Processes

Processes are not free. It will affect productivity and morale — often. The lightest, leanest process you can get away with is always best — and you will be amazed how little process you need.

Programmers are self-managing and self-motivated. Resist the desire to track everything. Programmers thrive in a flat organizational structure. Allow each programmer to track their tasks with whatever tool they prefer.

Refrain from relying too heavily on long-term road-maps, as they are likely to change. Pick a release cadence, like once a month, and ship whatever you have. Pick a set of features and ship whenever it is finished. Market what you have, not what you will have. Do not force programmers to commit to completing certain features by the end of a sprint or a specific date.

It asymptotically approaches completion but will only meet it at infinity. There will always be bugs in your software. There will always be tweaks to be made to your user experience. There will always be code that needs to be cleaned up. There will always be more tests to be written. And there will always be more documentation to write. Because there is always more work to be completed, you will have to make a judgment call about when to stop. Therefore, “done” is a decision, not a definition. Do not attempt to collect metrics or enforce standards to automate this decision. Trust the intuition of your programmers in this matter.

Ideally, programmers work remotely or have private offices or both. Collaboration should be asynchronous and online whenever possible—allowing remote efforts to be on equal footing with on-premise work and giving permanent records to items discussed. Have everyone do meetings online, even if many programmers work in the same office. Use video/voice tools (Hangouts, Skype, FaceTime) sparingly.

Don’t waste time estimating, planning, or designing tasks as a team if those tasks lie within someone’s particular area of responsibility. Limit collaborative planning and design to specifying interfaces between individual programmers’ duties.

Others can contribute by submitting suggested changes that they can reject or accept based on their quality and utility. Make your product department a service organization. It provides programmers with feedback and information but does not direct or manage their work. Let programmers make the final calls about what features to build.