Agile Projects

August 2018

Agile projects are all the rage these days. Some advocates believe that ‘going Agile’ means faster delivery. While it can, several key concepts are important to consider when planning and . Let’s frame this around the Agile Manifesto.

“Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.”

Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

© 2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this notice. “

Individuals and Interactions over Processes and Tools

This is meant to mean that the development process should not be overburdened with processes and tools. Individuals who interact can enhance creativity and innovate. Enthusiasts who are passionate about using Agile methods often go a bit too far, and abandon formal processes entirely. During a lengthy project, requirements, analysis, design, build, test and implementation artifacts need to be created. They are just not created in linear fashion, or all at once, as they once were in waterfall projects. As information relating to these artifacts are uncovered in a Sprint, they need to to be captured. By the end of the last Sprint, the artifacts should reflect what was uncovered during all the Sprints. In the end, the system needs to be documented, so that others may maintain it (often, the client who paid for the solution to be built). Otherwise, the development team may never disband and head onward and forward to the next development project. If they do leave without leaving artifacts behind, all those conversations and collaborative design sessions leave with them.

Working software over comprehensive documentation

Working software, once it has been fully tested, will undoubtedly stop working as changes are inevitably made to it. Looking at the code, one can see exactly what it does. The more important question, is why is it doing what it is doing? Without knowing the ‘why’, extending the design or changing the design is very difficult. This is very similar to being given one page out of a very long book, and being asked to change what happens on that page, without the benefit of reading the pages on either side, or any other part of the book. The story may not hang together. While I’m not advocating writing down every last detail that can be determined by reading the code, designers need to document why they have settled on the particular design and how the other parts of the system interact with the one being examined. Similar to the Individual Interactions over Processes and Tools discussion, adding designers mid-project (to catch up or increase development velocity) is very difficult if the newcomers have nothing to read. In that case, the only thing they can do is start engaging in conversations with the current team, slowing everyone down.

Customer collaboration over contract negotiation

Watch out for this one. Friendly customers, like friendly card players, change when there is money on the table. Negotiating new features into the development effort sounds like a great idea, and often, it is. However, if the team is of fixed size (typical of Agile projects), and the budget is of fixed size (also typical of Agile projects), features should be kept in priority order. High priority scope additions should have corresponding low priority scope deletions of approximate equal sizes. Otherwise, the amount of work gets bigger, while the team, timeline and budget remain the same. This is a recipe for “unfunded overtime” to deliver the expanded scope. Collaboration is a wonderful idea, but there is a built-in imbalance of power between the client and the delivery team. The client controls funding, sets completion targets (built around business plans such as new service launches), and has the say on whether or not the final product meets his needs. True collaboration implies both parties are equals: they have similar stakes in the project outcome and final product. Since there is an inherent imbalance, there must be some degree of negotiation of scope (feature list and stories), cost and timelines.

Responding to change over follwoing a plan

In waterfall projects, change is often viewed as bad. Some organizations go as far to measure project success by the amount of change introduced by either the project team or the business sponsor; a project with a high degree of change is often viewed as ‘out of control’. Agile projects, on the other hand, not only accept there are changes, but embrace it. Organizations that start down the Agile path still want to know how long a project will take to execute, what will be delivered, and how much it will cost. The project manager still needs to have a plan that shows this information: without it, the project will never get off the drawing board, or it may be stopped as the accountants see how much funding is being consumed, without a good idea of how large the final bill will be at project end. To build a plan for an Agile project, the feature sets and features must be estimated. They must be prioritized and grouped into sprints. Sprints are typically grouped into iterations or releases. Releases represent deployable versions of the system which may have key high-level functions (e.g., Reporting). During a Sprint, there will invariably be movement of features to the next Sprint. If a feature continually gets moved enough times, it eventually moves into the next Release, or maybe off the feature list entirely. The point is, there must always be a plan, or a structure of Sprints, Iterations, and Releases to house current features, next features and distant features in perspective.

Conclusion

While the above discussion may be a bleak portrayal of what is meant by an Agile project, the important take-away for the reader is to realize that Agile doesn’t mean Wild West where code is the only thing and all documentation is bad, nor does it mean that the documentation is more important than the system itself. The PM, Scrum Master, Development Team and Product Owner need to strike a healthy balance between what to document, how detailed to document, and when to document knowledge gained about the system while it is being developed. Having a system that only the original developers can enhance as new requirements surface is not acceptable. No one should have to throw away an entire system and build a new one just because there are a few new features it is missing or were not envisioned at development time. The ability to make enhancements in a timely manner is directly related to the how quickly a fresh set of eyes can understand how the system hangs together and why it was designed as it was. The code can only tell you what the system is currently doing.