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. 

Comments

Post a Comment

Popular posts from this blog

Solving `Empty reply from server` in DotNet Core

tldr; If you’re getting  curl: (52) Empty reply from server  check that you’ve configured Kestrel correctly. Long version I’ve started playing with Dotnet Core and Docker and have had a few issues getting started. I’ve had a little bit of experience with Docker, though only a little. I’ve worked with DotNet previously but never with Core. Environment The setup I’m using is a Windows laptop running Vagrant. Via Vagrant I’m running an Ubuntu Virtual Machine with the Docker run time installed. Feels a litle like inception. Key Problem The key problem that I’ve had getting started was having my Docker container not responding correctly to my curl commands. I get this: curl: (56) Recv failure: Connection reset by peer curl: (52) Empty reply from server Given that I’m not all that familliar with Docker or Dotnet Core I decided to remove one of the variables and set up a simple Express app in a different docker container. This validated that the commmand I was using to run
Read more

Testing functions that use local storage with Jest

Testing functions that use the browsers local storage API seems easy when you know how. Here's a quick run down on how to mock it out with Jest if, like me, you're not familiar with how to test it. In the end it's very little code. Consider the following TypeScript code. import { get, save, key } from "./storage"; describe(save, () => { let setItem: jest.Mock; beforeEach(() => { setItem = jest.fn(); Storage.prototype.setItem = setItem; }); it("should call set item with predefined key and json object", () => { const valueToStore = { value: "toStore" }; save(valueToStore); expect(setItem).toHaveBeenCalledWith(key, JSON.stringify(valueToStore)); }); }); The key lines are in the beforeEach call where the setItem function of the Storage prototype is assigned to an instance of jest.fn() . This allows us to make assertions on what is passed to the local storage setItem API.
Read more

Building a verify JWT function in TypeScript

# Verifying an RS232 signed JWT JSON Web Tokens (JWT) are used as a way to verify the identity of the caller of an API. **The best way to verify a JWT is to use a verification library.** I wanted to have a look at some of what those libraries are doing under the hood by putting together a function that will return if a given token is valid. In this blog I'll go through what I have done to get a validation function working. To simplify things assume: - That the signing algorithm is RS232 all others are considered invalid. - That the public keys are available on a JWKS url provided to the function eg [https://klee-test.au.auth0.com/.well-known/jwks.json](https://klee-test.au.auth0.com/.well-known/jwks.json) - I only want to know if the token was signed by a key available at the above url. I wont be checking if the token has expired, if the scopes or other claims are valid. # Break up the token A JWT is made up to 3 parts. The first thing to do in validating the token is to brea
Read more