In 2001, the Agile Manifesto introduced to software development was iterative and collaborative. However, too often the term agile is also applied to methods and processes that are simply reactive and disorganized. So what differentiates “agile” from “chaotic”?
Although I’m sure most readers are already familiar, standard project management methodologies include many standard tools; for example, project charter, communication plan, validation plan, project plan, working instructions, business requirements, performance requirements, etc. Typically when confronted with these documents, proponents of the agile method cry foul, “These aren’t agile! Don’t tie me down with paperwork!” While I’m fine with bypassing formalized documentation, I’m completely opposed to entirely letting go of the ideas these represent.
Here are a few guidelines, which I would encourage developers and project managers to never let go of, regardless of which methodology is being followed:
Know the Requirements
Creating software without requirements is the most heinous of all crimes. Joel Spolsky, in Joel on Software, points out that:
Failing to write a spec is the single biggest unnecessary risk you take in a software project. It’s as stupid as setting off to cross the Mojave desert with just the clothes on your back, hoping to ‘wing it.’ Programmers and software engineers who dive into code without writing a spec tend to think they’re cool gunslingers, shooting from the hip. They’re not. They’re terribly unproductive. They write bad code and produce shoddy software, and they threaten their projects by taking giant risks which are completely uncalled for.
It’s hard to state the case more plainly than that.
History & Traceability
Capturing the history of changes in documents and code is a necessity. By this I mean that if someone messes up a document or piece of code today, you should have the ability to revert to an earlier version. In Coder to Developer, Mike Gunderloy points out that there are three levels to source code enlightenment:
- Opening Your Eyes: This level teaches the value of code protection and code history.
- The SCC Journeyman: This level teaches the value of managing code by tree, that is, by version, release, and patch.
- Experts Only: This level teaches the value of security, pinning, moving, and renaming.
Whether a project is creating computer code or documents, having a history of changes and knowing who made those changes should never be questioned. Keep in mind, also, that having good source code control leads to cleaner code: instead of commenting out sections, feel free to delete with abandon, knowing that reverting to a previous version is just a click away.
An anonymous person once said, “Life is change. Growth is optional. Choose wisely.” Never is this truer than when managing change in a project. There are several reasons why change happens:
- Providing functional enhancements; for example, new technical features.
- Promoting improved understanding; for example, a cleaner graphical user interface.
- Limiting work based on new resource constraints; for example, an employee becomes ill.
- Refining product direction; for example, new market conditions provide opportunity or limit product viability.
Each of these may be good reasons to allow change to a project. However, nearly any event prompting change might be mitigated using an astute evaluation. For example:
- Are functional enhancements required in order to meet the minimum acceptable functionality or are they simply nice to have?
- Can improved functionality be introduced by means other than a change to the product; for example, is updated documentation an acceptable improvement?
Whatever path is chosen when confronting change, keep in mind the above two guidelines by keeping updated requirements, and managing change in a manner that is auditable and traceable.
Finally, whether your project chooses Agile, Waterfall, V-Model, or some other methodology, keep in mind that the rule of thumb in project work and software development is control and accountability. If you keep your eye on these two principles, you can be confident that your project will have every chance of success.