The Project Board - How we implemented an Agile product road map.
Recently I gave a talk a the Newcastle Coders Group around the agile process that I and my colleagues have built up at work. This talk covered a few areas but the key take away point that seems to interest people is how we applied agile techniques to higher level projects so that we could have a shared language with the stakeholders outside of the development team and our business could better understand what we're doing.
One of the problems that we've repeatedly encountered over the years is that stakeholders outside of our Product Development Team (PDT) are baffled when we say that we are running out of work. We're faced with responses like "How can you be running out of work? We've told you about all these things that you haven't done yet!", and of course we experience the counter point to that, "Why haven't you done this thing that I want yet? You can't be that busy", the inevitable answer to which is "Because we're busy doing the other thing that you/someone else wanted." I'm sure that sounds like something you've heard as well.
We've been building visibility into our process as best we can, We've got JIRA in place that's mapping our day to day work, but the business doesn't really care when User Story X or Y is done. They just want the whole Feature Set. So we felt that we needed to find a new way of communicating the work that we're doing to the people that are interested in our longer term plans not the day to day.
Enter... The Project Board!
The project board is a special Kanban board that we've put together to provide visibility into what PDT is doing for those people that are not interested in knowing what we're doing day to day. The board has five columns which track the progress of a project from being an early idea through to a marketable product.
The first column is the Backlog. The Backlog is a catch all. If someone brings an idea to PDT it gets dumped here and prioritized. If an estimate is required its done in T-Shirt sizes. There is no limit for number of items that are in this column, because it's a catch all. The projects that are in here are not ready to be worked on and don't even need to be well formed ideas.
The second column is the Dev Queue. To transition into the column an idea needs to be estimated and tasked up to the extent that PDT can pick it up and run with it without needing to do a whole lot of analysis. The requirements are pretty large to get here because we need the stakeholders that are external to PDT to know what is required of them to get an idea to the point that PDT can work on it. Because PDT always needs to have a next job to go onto in order to keep them utilised there is a one job minimum on here
The next column is Development. Because of the requirements to get into Dev Queue to get into this column all an item needs is to be at the top of the Dev Queue column and for PDT to have enough time to get to it. The Development column has a two job upper limit here and a one job lower limit. As we're trying to manage the Development process the limits here are the key ones. We need to make sure that PDT is kept at the highest level of productivity that we can manage.
Once PDT thinks that it's done with the project the project it is pushed through to Release Candidate Testing. This is the point where PDT is trying to release control on the project, PDT need to have the release notes written and the application/feature set documented. While its here there is still some discussion and support of the RC testers so it's not entirely out of PDT's hands.
The last column is marketing. Here it's completely out of PDT's hands and through to the people who will sell and support the product.
I'm sure that the idea of managing higher level projects using Kanban is not a new one. It is however one that still needs to be spoken about in the development community. By using the techniques that we use day to day to help our productivity in a way that targets the more business minded we are able to find a common language that helps us all communicate.
In the end good communication is the key to developing good software.