# Thursday, May 2, 2013

My reason for looking into this particular subject was being on a client site and sitting with a BA who was feeling a bit down hearted. She couldn’t figure out how she could properly communicate to the team how a bit of the system worked so they could refer back to it for a piece of work they were currently working on. I asked her why she just didn’t document it, her response to me was “but agile mean’s you don’t write documentation”. I must admit it through me when she said that. I had always without even thinking about the methodology itself provided anything I possibly could to help a team out when they needed it. If it made their lives easier to do a job and to burn through those tasks what was the harm in that? If in doubt on how to provide a piece of information to a team or if you are wondering if it adds value, why not ask them?

For example, sometimes to help a team focus on what they are building I usually suggest taking a wireframe (if you are indeed using wireframes) or rough sketch of what they are working on and place it on the wall. I may even suggest taking a copy of the PBI and sticking it next to it, the tasks that come off that PBI can float around the wireframe and you can use bits of string (nothing high tech!) to point at the various bits they are starting on. After a while the team would start doing this themselves and use it as a handy visual aid to what they were actually working on. In the morning stand-up's they could point to the bit of functionality they were having problems with (if any). This didn’t replace the task board it helped visualise an aspect of it that they were currently working on.

The approach worked well from a top down approach of development. Another approach I found worked after they had worked their way down the wireframes is doing a rough diagram of the stack that sat underneath that wireframe that they were currently developing. They could then point their tasks at what they were working on if it helped them to communicate to the team where they were or helped them visualise what they had to do next. When I say rough it would make sense for the team to collaboratively draw this in marker pens on a white board. By doing this it enables them to change or improve it.

Talking to others about this approach..

They found it was good as long as the wireframes the team were using were those they had contributed towards creating in the first place and that the team accepted they were not set in stone i.e. they could evolve with the teams input.

Using sketches instead of wireframes, gives the idea that the design is not permanent and can be changed at any time.

It was ok as long as the wireframes were modelling what had already been produced.

It was “taken to the team”, i.e. let the team decide if it adds value and or it helps them.

What are your thoughts, are there any visual aids as a developer you may have found helpful in the past?

Please note..
I must point out that I am not an Agile coach, but have worked as a developer, lead developer or architect on several teams in the past.

.
Tags: Agile

Thursday, May 2, 2013 11:37:13 AM (GMT Daylight Time, UTC+01:00)  #    Comments [0]