I’ve been doing some reading on Agile software development lately. I’m going to list and describe both the manifesto and the principals in my own words. First the manifesto:
- Individuals and interactions over Processes and tools - Use the best tool for the job and try not to let company software restrictions or policies get in the way. If the team only knows Jenkins then it’s probably wise to let them use it. Use whatever process works best to get results and don’t follow rigid, pre-prescribed procedures that may not apply to your workflow.
- Working software over Comprehensive documentation - Focus on the end result rather than artifacts that nobody will ever use or look at. Spend your time writing the code rather than writing and re-writing detailed specifications. Documentation for end-users is important and if the code is high quality it will, to a certain extent, document itself.
- Customer collaboration over Contract negotiation - Contracts are rigid, set in stone. They often spell out exactly what features must be in the software - no more, no less. Instead, be flexible and let the customer “be part of the team.” They may want a new feature that takes 30 minutes to code so why not do it? On the other hand, if the customer wants a new feature that sounds simple the developers can talk directly to the customer to explain why the seemingly simple feature will take hundreds of man hours to implement. The same logic can be applied to prioritizing bug fixes.
- Responding to change over Following a plan - Change happens often so roll with it and adapt rather that always being tied to a master plan. If a customer needs a new feature or you dream up a killer new feature that will differentiate your product, implement it even if it’s not part of the master plan.
Next, the principals:
- Customer satisfaction by rapid delivery of useful software - The waterfall process waits until the whole thing is “done” before giving software to a customer. Agile instead makes what they can, releases it, and then improves (iterates) on it. With agile it may not be feature-complete when it is released but it gets it into the hands of customers quickly, allowing them to use (and help test!) it.
- Welcome changing requirements, even late in development - Embrace change. A customer may push for a critical feature or someone may think up a killer feature. Don’t let a rigid plan stop you, add it! Was the software designed poorly or did someone realize a better way? Don’t be afraid to start over and “do it right.”
- Working software is delivered frequently (weeks rather than months) - Add features and fix bugs using quick iterations/sprints rather than large quarterly patch bundles. Fast bug fixes and feature releases make customers happy and give developers a sense of accomplishment and progress.
- Close, daily cooperation between business people and developers - Use the daily standup or daily scrum to work closely with the business to ensure their goals are being met. A large customer may request a feature that should take priority or the developers can talk directly to the business to explain why a requested feature will take a long time (or may be impossible) to implement. Break down the communication barriers, remove the middle-men.
- Projects are built around motivated individuals, who should be trusted - Let natural leaders emerge and trust that they will drive the project in the right direction. Sometimes the initiative for the project comes top-down from the business but if you find someone who’s really enthusiastic about the project let them go, don’t stifle them too much.
- Face-to-face conversation is the best form of communication (co-location) - E-mail and instant messaging cannot convey tone in the same way that face to face communication can. IM and e-mail are great tools but face time builds stronger teams and ensures messages are conveyed with little or no ambiguity. When you’re face to face you’ll never forget an e-mail or miss an IM - the conversation is right there in front of you.
- Working software is the principal measure of progress - Don’t get caught up in timelines, percent complete, or other metrics. Quantifiable data is a great thing, but at the end of the day getting software out the door is the goal and developers are working hard to reach that goal. Frequent status updates and “what percent complete is this task?” e-mails take valuable time away from coding.
- Sustainable development, able to maintain a constant pace - In a waterfall model feature deadlines may be unrealistic because they are modeled by a PM and perhaps without input from the developers themselves. Seemingly “easy” features may take a long time to realize. This may lead to many hours of overtime which in turn leads to burnout. In a waterfall model a final product may never be released if developers quit their job due to burnout, or, in the best case scenario, you need to bring in all new developers and the project falls way behind schedule. Listen to and trust the developers, they can tell you when they are working too hard.
- Continuous attention to technical excellence and good design - I gotta admit this one is somewhat vague and applies to almost any IT project. Perhaps what they mean is “revisit the design during an iteration/sprint if necessary, rather than have it set in stone at the beginning.”
- Simplicity—the art of maximizing the amount of work not done—is essential - Reduce overhead and busy work. Don’t spend time writing excessively details specifications or documentation or having pointless meetings. Don’t focus on keeping everyone 100% utilized all the time. When there’s downtime trust that the person will use it to contribute to the success of the project.
- Self-organizing teams - If someone thinks of a new software product empower them to run with it. Let them build the team because it’s their vision, they know what they need, and they know which people would be interested in helping, and thus driven to help it succeed.
- Regular adaptation to changing circumstances - This seems to be the embodiment of the principals. Agile by definition is quick change and adaptation.
It seems a lot of these principals mesh with many of the “business 2.0” books and articles I read, but at their core they also represent good old fashioned inter-team teamwork, communication, and working together to complete a goal.