Early this year, I set up a traditional agile wall board for my last client project, and this post is a modified and expanded version of an internal post that I had written about this experience at my consulting firm employer, which I will likely modify once again for our public thought leadership blog space.
Initially, the only real option in terms of where to place the wall board was on a pillar that sat between my cube and the main corridor of the floor. It provided seemingly unlimited space from floor to ceiling (depending on how far team members would want to stretch in either direction), and gave some visibility to the project, since the pillar sat just around the corner from management offices, restrooms, the coffee area, etc.
Within a couple days, however, I was asked to take it down due to the apparent fear that the Post-it notes might cause the paint to peel, despite the fact that they are specifically engineered not to cause paint to peel. The backup reason that was given behind this request was that the wall board was seen as a potential distraction to the floor, and others might do the same thing if it was permitted to remain in place.
So to comply with the wishes of a few folks at the client firm, I took it down essentially immediately, and inquired about alternative options that I might take in lieu of using the pillar. An available white board was quickly provided, which I soon set up and placed in an even more visible location on the floor, perched on a desk across from me so that everyone in the entire (very large) room could view it.
Prior to setting up the initial wall board on the pillar, I thought it would make sense to add some value by turning it into a heat map. Essentially, a range of colors that represent task sizes from low to high on the Fibonacci sequence so that folks can eye-ball not only tasks, but relative sizes of tasks at a glance. For my implementation of this agile wall board hack, I ended up moving from the traditional yellow Post-it notes used on the pillar to super-sticky Post-it notes.
This wall board variation is just slightly different from orthodox agile wall boards. Just a simple change that I think adds value to the reguarly held scrums (not ad hoc scrums that I have seen on some teams) that I typically hold on a daily basis, or in the case of the current project, twice per week. In looking to determine whether anyone else had created a similar wall board variation, I happened to come across an interesting website called Agile Board Hacks that I recommend anyone in the software development space to check out.
While I did not come across anything similar to this heat map variation, this website does offer quite a few ideas in terms of conveying information to a team in an agile manner. There are at least two agile wall board hacks on this website that I personally think jump out in terms of potential to add value to the types of projects on which I and other consultants in my space are engaged: "Who Knows What?" and "Are We Gonna Make It?"
The former provides a grid that lists team members and the areas of specialized knowledge that they provide (as well as the extent of their knowledge), so team members know who to go to without resorting to tribal knowledge (and whether the team will experience some level of pain when these individuals are away from the project). And the latter shares team feelings about their project committments from a range of "Very scared that we will not achieve everything that we have committed to by the end of this iteration" to "Very confident we will all deliver everything that we have committed to by the end of this iteration".
In looking back at the agile wall board for my last client project, I recall the significant expansion with regard to the number of tasks being added over time, and we were getting to the point where the "in progress" tasks were being outweighed by the "to do" tasks. At least a portion of tht team was aware that this was the case because most of the "to do" tasks were on the critical path. So I thought it would make sense to add a little marker on each of these tasks to make them stand out. If you take a look at the pic below, these critical path tasks can be identified with red stickers labeled "CP".
Simple change, but I think this adds value in part because it shows the conflict to some degree between the waterfall approach and the agile approach. We do not have control over the database that I was typically used to having, so tasks that depended on these database related tasks needed to wait. (The design aspects of these tasks are included in these as well, so we could not simply mock these items out like we had done earlier in the project for other similar tasks.) And, by the way, my apologies on the resolution of the above photos. (For anyone who considers cell phone cameras equal to real cameras, at least those currently available with most cell phones, they should compare these photos taken with a premium Android smartphone and those taken with a real Canon camera below.)
Later in the project when the "complete" section began to start overflowing, I started consolidating or layering tasks so that more of them could fit. As the wall board filled up, an additional value add came to mind. The distribution of tasks by weight over the course of the project could be visualized. While we did tackle one of the larger (purple) tasks early in the project, the weight of tasks (dominated by yellow) leaned toward the last several weeks. And looking at the tasks that were remaining to be completed, it turned out that the last portion of tasks looked very similar to the first. The interesting thing for me is that this more-or-less bell curve was not planned.
One of my colleagues inquired as to why tasks moved to the "complete" section continue to remain there over time, whether doing so creates issues with regard to available real estate for other tasks either not yet added to the wall board or not yet moved to the "complete" section, and what criteria I had used to determine the duration of time that these should remain.
In response, I mentioned that the wall board was not created just for the portion of the team consisting of our consultants, but for the client to view all core tasks across the course of the project as well. At least in our situation, I did not see the value in focusing on tasks that are just "in flight". The tasks that are yet to be completed, as well as the ones that have been completed, show the full picture of the project.
While I have seen focus placed on "in flight" tasks before, once the tasks are removed from the wall board they essentially disappear, at least for those not intimately familiar with the project. Keeping tasks on the wall board helps enable a one-stop-shop to remember who worked on what (and in the case of this particular project, helped me write a constructive performance review for a team member). Whether the wall board has room or not is not really a concern of mine, but I can understand why some audiences might wonder, but not ask about it.
After coming up with this agile wall board hack during my last client project, I have since started work on a new client project, and after several months construction is now in full swing. One aspect of this wall board variation that can be easily be missed in the above project snapshots is the fact that the location of tasks are in movement, and at least while tasks are still being defined and more well understood with regard to how each relates to individual team member velocity, the tasks themselves are in movement.
In my wall boards, I have decided to focus on actual construction tasks from a technical perspective, rather than more fuzzy tasks that attempt to focus on end user functionality. Such functionality of course needs to be reflected in the wall boards, because these are the goals of the project, but each of these is tied to the project by technical dependency. Creating tasks based solely on use cases or stories from my experience seems to have more value for maintenance projects rather than new development projects.
And regardless of whether end users claim to have a strong hand in changing requirements throughout the course of projects, this happens to be the case more often than not, and is one of the primary drivers for agile software development methods. It seems odd that many businesses which want to preserve the liberty of changing requirements at will, with no repurcussions such as expanded budget or increased timeline, are the same businesses which insist on waterfall development methods.
For my recent agile wall board, I have emphasized the fact that larger construction tasks will be refactored to a point where they reach a stabilized point that best communicates what is really being worked on and helps show project progression.While for the most part such tasks might originally be posted as purple or red tasks (relatively higher on the Fibonacci sequence), in most cases these should be broken down to tasks that have lower effort estimates, so I have added a label at the high end of the effort range to indicate that this is the case. You will notice that over the course of the following wall board snapshots, that not only are tasks added and promoted over time, tasks themselves are refactored over time.
One perfect example of this break down activity is work on the design and creation of the database to be used for the web application, which consists of over 100 database tables. Fortunately, I am a strong advocate of database schema versioning in addition to source code versioning, and have led the use of Liquibase on multiple large projects because of my experience. In leading the design and creation of a single script for both SQL Server 2008 R2 and DB2 iSeries, this break down was especially necessary because presenting this work as a single red task would result in the need to keep this "in progress" task in place for quite some time while not showing interim project progress.
In this case, this task was sensibly broken down into "design" and "creation" tasks, and additionally broken down by database tables that are to exist on SQL Server only, database tables that are to exist on DB2 only, and database tables that are to exist on both SQL Server and DB2, which I have been referring to as the "core" tables. Now, there are options on how tasks can be broken down, and this process is really not much different than traditional equivalents. What is important for all agile wall boards is that they provide value to the development team, and that individuals are communicating valuable input rather than just going through the motions of doing so.