Agile methodology is a widely used system of project management. While there are many facets of it, this article intends to explain the values of short cycles and how to apply it in your own projects.
An issue with Waterfalls…
Most of us have been involved, or even headed our own, Waterfall project. A Waterfall project is where you start building your project, with your nearest goal not being any clearer than the project is ready to go. Waterfall means that once you have your plan in mind, you try to build the whole thing in one go.
The problem that we face is that if the project takes any length of time, we, or others involved, make changes to how it should work. Small surface changes are fine, but often these changes will affect the basic architecture of the project.
On with Agile…
In Agile, we use small cycles of development, called iterations. Each iteration will select only a few features, usually of the highest priority first, and make sure they are working. The objective is that each SMALL iteration will be completed, and can be tested by the project owners at each pass.
When they try it, they can make requests for the next iteration. These requests can be to either make changes, fix bugs, or change the priority of existing items. But once the next iteration begins, and the tasks have been selected, it is locked down. The developers need to be able to focus on these tasks, and architectural plans without interruption until the completion of these tasks.
Many teams make the mistake of allowing changes during these iterations, but the development teams should strongly protest. The PM’s and involved business side should be making plans for the next iteration based on reports, and not pushing immediate changes during daily updates.
On the individual level, one thing I like to do, is to select a single task, simple and high priority, and finish it before jumping on any other task. Then test it. I have been applying this to all my projects now, and had excellent results. Because I don’t have multiple tasks going on, I can walk away from a project for a while, come back, and I will either know the one tasks I was working on, or most commonly, all previous features are completed, and I can do whatever I want to next.
One common feature that has spawned from this is a clear version history in all my personal projects. I use this numbering system: #.#.#[.#]. The first number is the release version. It is always 0 when I first start, and goes to 1 when I make the first release. The second number is the feature or bug number I’m working on under the current release. 0.1 is the first starting item, usually just creating the project, and potentially adding one class, or shaping the UI on one form.
The third number is the date or time. If the project is very small, I might just include the hour and minutes, but usually this is the date, as in 4 digit year, 2 digit month, 2 digit day. Finally, I have an optional trailing number for multiple releases during the same time, particularly for testing.
One thing this has helped show me is how much time it really takes me to build something. I’m often caught by the idea (at least in the past) that a certain project will only take me a couple days to finish. If I measure in hours, I might imagine 12 hours of dedicated work. But when I look back at my version history, I begin to see a different tale.
The project starts out great, but then reduces in speed. For my personal projects, that is mostly because of real life, such as I have a real job, or I need to make dinner, or I’m heading out for a little while. It even is because I have just lost interest in the project for a little while. But it gives me a good look at the reality of how much time it takes. Even If I really only worked on it for 2 hours, if it took me 2 weeks to finish it, that’s really how long it takes.
But at work it’s a different story. I often start to see a loss of time near the end of a project. What I began to realize is that management increased the amount of time spent on meetings. Literally, 2 extra 30 minute meetings where added to check on statuses, but then an extra thirty minutes of time was spent to make sure the information was ready. Of course email distractions also increased because of the number of important emails being sent around, and the massive of numbers of people being added to the email chains.
By taking an agile approach, at least for yourself, you will begin to notice how you really work, including an additional level of focus and speed in projects. The version history, gives clues to how things really operate and the single task orientation allows for focused approaches that leave you with clean places to work, and re-evaluate your needs often.
