A reader brought up the point that going "too" light and agile makes it very difficult to get other developers involved in the project or to hand the project off to a whole other development team. Furthermore, how are requirements efficiently tracked at all if we just have a few simple checklists to start with. In other words, how do we ensure the "survivability" of the project if the key people involved get hit by a bus and just how much documentation is appropriate? There certainly has to be enough useful documentation for a new developer, or team, to pick up the project, understand how it works, and make a change to it without being completely afraid of breaking something. Furthermore, there has to be enough useful documentation for both the client and other stakeholders to know the general scope of the project, know what requirements have been implemented, know what changes have been requested, and what requirements are left to be done.
Defining Useful Documentation
The key here is defining what is "useful" documentation. Obviously, the documentation requirements must fit the task at hand; but for most business applications, even very complicated ones, I find a light and agile approach to be superior to a document driven approach. By no means does "light and agile" mean "no process and no documentation." The key emphasis, instead of being on documentation, is on delivering production-ready code that's clean, well-designed and well-documented. With respect to requirements, instead of focusing on the whole kit-and-caboodle, the focus is on keeping the picture in mind while focusing on the next highest priorities that will deliver immediate value to the client.
A Simple Case Study
To demonstrate, here's a simplified case study of my current project which I feel has been more successful than any other that I have personally led. Specifically, it has had the fewest found bugs, has been the easiest to maintain, and has resulted in the highest client satisfaction I have experienced. Now there are a couple of exceptions to this project which have worked in my favor... The project was not fixed bid nor even phased bid - it was budgeted for a given year with a commitment of delivering a number of defined releases for the given year. This budgeting approach has made the the client/provider relationship much more cooperative since the client doesn't have to worry about getting hit with change orders and the provider/developers are less pressured to deliver fragile code. Additionally, the client understood, from his own project management experiences, that requirements change often - no matter how well they're defined - and so was more open to accepting agile techniques. But, to make things a bit more tricky, the client in question is a state's transportation management company which has plenty of governmental oversight and auditing requirements. An agile process was still appropriate and acceptable in this scenario.
Estimating and Project Kick-Off
To come up with an original estimate, our company and the client started with a project charter which included: purpose, vision, driving factors to create the product, benefits of the end product, stakeholders, critical success factors, goals, scope (both in and out of scope items - very important to define what's out of scope), constraints, risks, assets, the process that will be followed (defining what type of agile techniques will be employed; defining what a release, iteration, and user stories are, etc), and commitments to communication (how requirements, changes and bugs will be tracked, etc). The project charter was eight pages long (including the title page, TOC, and change log page) and required almost no maintenance throughout the lifetime of the project.
With the project charter as a guideline, a four-printed page Excel doc was created which defined the major releases (e.g. budget management functionality), the major themes within each release (e.g. reporting), and the anticipated high-level user stories within each theme (e.g. integrating a third party reporting tool into the product). Finally, each user story was given a relative estimate in "points" of work, a priority (must have, want to have, and nice to have) and the associated risk. The following is a description of the purpose of the "points" system... (the next paragraph is taken from a book I'm working on in my spare time - i.e. when I'm not tinkering with my Lego Mindstorm NXT kit ;)
Of particular interest in
Agile Estimating and Planning is the author’s suggestion of using “points” to estimate work instead of hours or days. With this approach, a unit of easy-to-estimate work is selected to act as a baseline for other estimates. This baseline unit of work may be given a points-estimate of 3, for example. Other units of work are then compared to the baseline unit of work and given estimates relative to that baseline. For example, if the login process is expected to take 3 points of work, then the shopping cart may be expected to take 8 points of work – or almost three times the effort as the login process. As the difference between 5 points of work and 6 points of work is unrealistically predictable, a points-scale is adhered to; an example scale is the first few above-zero numbers of the Fibonacci sequence: 1, 2, 3, 5, 8 and 13. After the highest value / highest risk work units have been estimated, a project schedule can then be organized by determining how many points can be completed in a given iteration and then assigning units of work to the iterations, accordingly. If the project team realizes that it’s delivering fewer or more points per iteration than originally expected, then only the points completed per iteration needs to be adjusted to fix the schedule; the tasks themselves don’t, necessarily, need to be re-estimated. As the schedule progresses, it becomes evident how many hours of work are in one point.
With the project charter and releases-themes-user stories docs in hand, we were fully prepared to provide a relatively accurate estimate, know exactly where we needed to start (with the higher risk must-haves in the first release), and had a well-defined direction for the entire project. This entire process took a couple weeks of effort and we were ready to begin development. Keep in mind that this was anticipated to be a one-year project, so the initial charter/requirements phase could take just a few days for a smaller project.
Developing the Project
Once development began, we spent a couple of weeks creating "architectural spikes" for the highest risk factors in the project. An example of this was writing a bit of code that would communicate with multiple databases concurrently. This served two purposes. First, it allowed us to define architectural requirements to accommodate these high risk items; therefore, we didn't have many "we have to change everything" situations which adversely affect schedule and budget. Second, it allowed us to provide better estimates for the items we would be tackling during development.
After the high-risk architectural spikes were proven, we were able to begin iteratively defining, exploring, coding and, most importantly, delivering the product. If at the beginning of a new release, we'd meet with the client for a couple of days to discuss goals of the release, any necessary changes to the charter/reqs doc and define highest priorities and risks. Each release planning meeting would take about two days and occurred every couple of months. Then at the beginning of each two-week iteration we would review what was accomplished during the last iteration, explore and document new ideas/changes/bugs that were discovered, prioritize and estimate the next iteration with a focus on items that would provide immediate business value, and get back into development. Documentation of all of this consisted of lots of white board activity and simple user stories tracked in the very simple, and free!, requirements-tracking tool called XPlanner (http://www.xplanner.org). The exploring/documenting/planning phase of each iteration took about 2-16 hours. (The initial project iterations took a couple days of planning while later iterations - after a month or two into the project - began taking only a couple hours.) The key to all of this is that the requirements were never defined in complete detail until we were actually into the development itself. To assist, daily 10-15 minute meetings would be held with the client (over the phone since he was offsite) to discuss progress from the day before, goals for the current day, and requirements that needed further analysis. The following is a description of what user stories are...
A user story is a unit of work as defined by the eXtreme Programming approach to software development. In
Extreme Programming Explained, 2nd Ed., Kent Beck describes a user story as being “customer-visible functionality. ‘Handle five times the traffic with the same response time.’ ‘Provide a two-click way for users to dial frequently used numbers.’” Stories are given short descriptions and are defined early in the development cycle. They’re essentially bits of functionality to be expanded upon with further discussion. Auer and Miller, in
Extreme Programming Applied, concisely defined a story as being “the simplest thing that can possibly work to make everyone in the room agree that they have a placeholder for something that needs to be done.”
Maintained Artifacts
Throughout development, the only document that was created and maintained, besides the very simply defined requirements in XPlanner, comments within the code itself, the unit tests (which are a very legitimate form of documentation) and checklists for planning meetings, was a developer's guide to the application. This document is given to new developers and exists in the case of any buses hitting me. The guide includes: location of source and data repositories; locations of executables and third party tools; description of application setup and deployment with system prerequisites; how-to for deploying updates and nightly process changes; project architecture consisting of coding standards, general architectural approach, project layers and packages (data, presentation, etc.), database standards, and table descriptions; descriptions of third party components and what they provide; and integration concerns with third party applications (e.g. an external budget and scheduling tool). After one-year of development, this document is 32 pages long, has been internally approved by the client's internal IT department, and requires about two hours of maintenance every month. One of the key elements of this document is describing well-defined design patterns used throughout the project.
Besides the client and myself, there has been no QA department available to assist on this project. Besides using best practice architectural techniques, the entire project has been developed using test-driven development so that a regularly executed NUnit process helps determine if new bugs have been introduced to the code. This is a vital element to being able to hand the project off to another developer and give that developer confidence in making changes to the code.
Assumptions
Now there are a few caveats to this entire approach. It assumes that most of the project is automatically tested with unit tests. It assumes that defined design patterns have been consistently used to more easily describe the architecture and individual packages within the application. It assumes that requirements may be changed regularly without incurring a penalty to the client besides having to drop lower priority requirements; replacing lower priority requirements with changes and new discoveries ensures that the schedule/budget will not usually be greatly affected.
Year in Review
This approach allowed us to go live with production code only a few months - on a 12-month project - after the initial, explorative meetings and regularly deploy changes and additional functionality to the end-users. (We could still have gone live after the first month with very limited functionality.) This approach has provided almost immediate benefits to the client's organization without having to wait for long spans of time. This has also allowed the client to end development at any time once he feels that an appropriate level of benefit has been achieved. Finally, at all times, the client has known exactly where development is and a sense of how successful the overall project will be when finally completed. I'm happy to say that the 12-month project has been extended another 12-months to accommodate a completely new suite of functionality. Perhaps I've just gotten lucky...nah ;)...I have to attribute much of it to using agile techniques, test-driven development and well established design patterns to boost maintainability.
Billy
Copyright 2007 by Billy McCafferty, All Rights Reserved