Agile Without a Project

Projects have a start and finish. For most software projects the project is considered finished either right before or right after it enters maintenance mode. Most of our applications are running in a maintenance mode and have been for a long time. Requirements for these are generally done as feature requests or bug reports. Running maintenance mode in an Agile manner is going to look different from running an actual Agile project.

If we were running the support desk in addition to being the development team I would have us model our maintenance projects after Kanban. The layout would consist of the developers pulling items in from a story collection. This collection would be ordered by the product owner much as the backlog currently is. Hot ticket items from the floor would be dropped into the top of the list.

Items would be pulled from that into a pre-development queue. This would be the location for items that needed more analysis based on conversations among the team. They could also be in a design mode, possibly waiting on user acceptance of the initial design. They could also need some simple clarification or be there simply just long enough for a developer to get a handle on the exact nature of the issue.

From pre-development items would generally be placed into development. While extremely rare it should be allowable for items to go back to the story collection or be dropped completely from pre-development. The more the development team is involved in crafting and estimating the items the less this should happen. In the development segment the item is obviously being built. This does not include testing, it is specifically for development. Any further analysis at this point becomes a blocker of forward progress, not a reason to send it back to the previous queue.

After development is testing. When bugs are found the item stays in testing and any analysis/development needed to resolve the bug becomes a blocker. Automated testing is an exception to this as it happens in development. Testing can be strictly functional testing with a second queue for user acceptance testing, or it can be all testing. Details such as this would be developed over time as we settled into the process. After this would be the production release, no more queues.

All of this would be represented in an analog format. Team foundation server would still be used for the development process, but there would be an analog counterpart to the project represented on a wall in a shared space. This would be maintained by the project manager/scrum master/agile coach/product owner or whatever other title we decided to give the person in charge of the process. The detail here is not important, but the idea that this analog part is not specifically maintained by the development team.

This process results in a continuous integration process that should always and rapidly be dropping the most high-value additions and/or fixes to the customer. I am not claiming this is exactly a Kanban setup. If we were to try this there are a lot of details missing from the narrative. Each stage has a specific number of items that can be in it which needs to be stated. There is an expected amount of time an item takes to get from the beginning to the end which should be known.

We do not run this way for a few reasons. We do have a support team between us and the end-user. Another reason is organizational, we have to stick to a two-week iteration schedule with releases lining up on iteration dates. Our team is also responsible for a project that is currently in active development, not in maintenance. While working on this application we have to continue to keep our maintenance products working while expanding their feature set as required by the business. The result is our current flavor of Agile and will be given a more detailed look in a future post.