Working Wall

One of the more prevalent off-handed comments I’ve heard a lot recently is: agile software development lacks focus and/or structure. It seems that there is a common perception that without an abundance of documentation and meticulously planned tangibles you don’t have structure.

The above photo shows a working agile environment; the whiteboard wall contains an ever-evolving selection of cards for business analysis, high-level developer tasks (planned / in progress / completed), QA items, and subsequent metrics. Also tracked are bugs, project velocity, anticipated project completion dates, issues, and ideas.

In experiencing “the wall” I would say that Agile has a lot of refined structure – in a lightweight kind of way. Less time is spent stressing over the initial planning and documentation and more time is spent trying to get an overall view for understanding, business value, and getting results quickly out of the gate. The documentation and tangibles begin to flush themselves out over time as you delve more into the project.

Personally, I had a rather interesting experience on my own project. My goal was to find order amongst chaos and create a series of user stories that would flush out tasks for the developers to work on. However, instead of jumping headfirst into the world of stories (which I don’t fully understand yet), I started out by initiating a conversation with a group of techs — about what has been done on the business analysis side of their project.

The conversation quickly evolved into a sticky note “question asking” session, then sticky ordering/grouping; it progressed to the point where we had a series of user stories and action items. What amazes me is that all of this spawned from a single conversational question rather than a long and very detailed spec requirements document. Thus, instead of spending weeks gathering requirements, we achieved the same results in one afternoon.