Previously I have written about Q Branch within Readify. Since I blogged about it we’ve shipped two new tools, Q12, and Q13. Q12 is a worm which I alluded to in a previous post, and Q13 is a Code Review tool for Team Foundation Server which only just went into internal alpha testing this week.
As more an more Q projects are rolling out the door I am getting some more interest from various people in the business and it might actually turn out to be less skunkworks and more mainstream. This is cool because success means access to more resources and over the past two months I’ve had two separate people also involved in Q branch, each with good success.
With success though comes a few challenges. Q branch currently owns some applications that are now starting to get feature requests and it’ll be very easy to get bogged down in additional feature requests for already shipped products/tools. This has a knock on effect of restricting the amount of innovation that can take place.
I’m thinking that I need to communicate the process around Q Branch a little bit better, and in the spirit of Q Branch, I came up with this just now.
Let me expand on each of these boxes a little bit:
- Listen; you need to spend some quality time with people in the business, having empathy of the issues that they are facing and floating ideas with them about how technology might be able to help them.
- Backlog; I measure the new/derivative ideas that I have on a per minute basis, obviously I can’t do everything at once so it is important to maintain some kind of backlog and prioritise it. You should own the backlog but continue to listen about where the most pain is – don’t lock yourself into what the next thing is until you actually start building it.
- Build; come up with the simplest possible code that can address the business problem. You aren’t aiming for a complete feature set, you are aiming to provide something of value in a short period of time. Shipping is the number one feature!
- Beta; get it in the hands of the people that are going to benefit from it, sometimes you might need to go and sit with the users to walk them through it and help them for a period of time.
- Feedback; listen to the feedback and accept it all. Accepting feedback doesn’t necessarily mean you agree, add it to the backlog. If you don’t manage to get to it that is fine, but if there is enough passion about what has been delivered then that is a good sign.
- Tweak; take some of the feedback and tweak the code where feasible. It isn’t possible to do everything – what we are aiming for here is general refinement to get to a point where you can evaluate whether the project as a whole is viable.
- Evaluate; Q branch doesn’t do maintenance, so once a code base gets to a sufficient level of maturity you need to determine whether it provides enough value to pull it into the line of business application suite or somehow handball it.
- Handball; send it to your mainstream development team, open source it or shut it down.
Now that I have that spelt out I have to go and clean house because a whole bunch of things are currently in the evaluate phase and I need to handball them.