Lessons in Agile

We have been using an agile based methodology at work for a few months now. Overall it has been a good experience for the developers and the upper management. From a technical management point of view certain areas have worked out very well, such as morning standup meetings and enforcing test and customer reviews. My biggest problem however is that we have used paper cards for the majority of tracking. This has made it quite difficult to plan, view and log work. In retrospect all this information probably needs to be backed by some kind of data store. One of our devs would spend quite a long time saving this info in Excel to produce burn up charts, but historical information was not centrally stored.

We are now investigating Team Foundation Server, though the price has really surprised me, and not in a good way. Hopefully using TFS we can track requests, work items, bugs and even feedback from a central store. I also really like the source control features, such as shelving and advanced branching - although I am yet to see this in a work environment.

Anyway back to agile. I thought I would document some of the lessons that we learned along the way:

• Morning Standups - otherwise known as scrums - are great. One of the common scenarios we have is that some devs will get caught up in the problem at hand. Anyone can just say "take it offline" (or similar) when they are not interested, ending that conversation and indicating that the relevant parties should continue after the meeting.


• As I mentioned, make sure you have a central data store for all the work that is carried out. While a card based system works ok for the work in progress, previous or upcoming work can be hard to track.


• Get a large board, with columns divided up into stages (Not Started, Development, Review, Testing, Customer Review, Complete), while on the other axis divide the rows up by developer. This should make each developer a lot more accountable for any work they have outstanding.


• Maintain good visibility for the team regarding where they are and what the goals are. This can be achieved verbally in the standup and also by generating a burn up or burn down chart that should be displayed near the tracking board. One of our devs was very good at this and it helps a lot when trying to motivate the team.


• Get card printed and make sure they are small enough! We used colour coded cards, they are very good and it is easy for anyone from managment or dev to understand. White for Functionality, Red for Bugs, Blue for Technical Debt (When a job will needs to be revisited) and Green for Infrastructure.


• Enforce testing. We used stickers (shiny stars - like back in school if you did well) on each card indicating the type of test. Red for manual testing, gold for unit tests and silver for selenium tests. Work should not be accepted until the tests have been written.


• Track work done! Both the time worked, time remaining and the stages the work item has been through (e.g. Development -> Review -> Development -> Review -> Test). This can be easily achieved by colour coded stickers on the top of the cards.


• Issue a priority for each work item. This makes it easy for devs in a self organised team to override each other without causing an upset. "Can you please work on this with me now, as you can see it is a priorty one bug and I need your input" won't result in anyone getting upset.


• Make sure you still do appropriate requirements analysis, agile does not mean that the development team can do it their way. Good requirements make for good acceptance criteria.