Empowering Teams with Agile
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.
A sculptor has a process of his own. he sketches his projects first; he builds a completed version out of plaster before even starting with the final material. It is best to leave him alone to carry out his work. Imposing an exterior model on his efforts would only result in frustration, poor quality, and delay. Like designers and artists, programmers can and should be trusted to make correct product decisions.
Refrain from relying too 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. Estimates should be as accurate as possible but only as precise as necessary to keep the estimation cost low. There will always be bugs in your software. There will always be tweaks to be made to your user experience. Because there is always more work to be completed, you will have to make a judgment call about when to stop. So, “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.
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).
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.
Software Development demands Ownership. Success is a combination of opportunity and Ownership. Success ensues after we take responsibility for attaining it. Accepting responsibility leads us to change current circumstances. The rewards of complete Ownership and taking responsibility will appear in the form of new possibilities. What we want or what will be beneficial to us are the things worth focusing on.
