Thoughts in the Wilderness

Well today we had our first retrospective, a day before the end of our first sprint.  I used the tried & true format of “What went well” followed by “what went not as well”.  We scheduled an hour for the meeting.

As usual, people had a lot of trouble coming up with positive things to say, and not much trouble coming up with negative   One person refused to write anything positive!

It came together pretty easily that the topic that concerned the most people was “requirements”, or rather the lack of them.  There was a fair bit of conversation, which could easily have got out of hand.  In fact, it did for a little bit when one person tried to hijack the meeting for a topic other than the one we agreed to talk about.  I redirected that to another 1-on-1 meeting between the 2 of us later.

I tried to keep it in front of everyone that we wanted to come up with concrete actions that could be used to address the problems.  This worked ok to keep the conversation on topic, but no-one really suggested any actions except for our manager.  Being that she is the manager, no-one was seemed ready to contradict her suggestions.  They were good enough action items though, so I went with the flow.

The organization is very document-centric, which bothers me.  Rather than talk about ways that the developers could *pull* requirements through 1-on-1 conversations, there were a lot of suggestions on how we could better use email and documents on SharePoint.  Ugh.  I’ll have to live with the document-centric viewpoint for a while I think.  The best I can probably hope for, short term, is to find ways to make the documents useful to the team.

In the end, we finished on time and came out with some actions that we are taking to address our requirements-concerns.  Nobody was insulted or put off, and the team is fairly positive.  I’m pretty happy with those results.

In software development, a kanban board is a way of putting your todo-list (backlog) on a whiteboard using one post-it per item. I have been experimenting with my own style of kanban board for some time now. Its benefits are:

• measures velocity (how quickly the development team can deliver new features)
• measures the impact of bugs on the development team
• measures the quality of planning and estimates
• over time, allows you to fine-tune the overhead of planning and estimating
• allows client to prioritize as often as they want
• provides detailed visibility into what developers are doing (information radiator)
• does not require fixed iterations

The above benefits are substantial, especially considering that the technique adds almost no overhead. It requires a short daily stand-up meeting of developers, in front of a whiteboard. It requires you to breakdown features into small, manageable chunks. If you already do Scrum, that adds zero daily overhead, and may well allow you to subtract some.

The technique works well for generalist-style teams of developers. (A team of 5 specialists working individually on separate parts of the application will not get the full benefits of the technique).

Moving on. Materials you will need:

• large whiteboard with colored erasable markers
• post-its (size 3×3 inches are ideal)
• sharpie or other bold pen to write on the post-its
• small colored stickers (at least 3 colors)

The technique is very simple, but it has multiple dimensions. I will explain it in terms of those dimensions. First dimension deals with the flow of post-its on the whiteboard.

Each post-it will represent a system feature. For planning purposes, you should aim to size the post-its to around 2 development days, i.e. it should take a single developer no more than 2-3 days to develop the feature. That said, the technique allows larger post-its (with increased risk). Simply use a different colored post-it for features that are too large (we use pink for large, and yellow for normal). You can also mark an existing post-it with a red-X to indicate it is too large.

The whiteboard will be divided into several sections. Post-its flow from left to right and never back.

The first area is the “broader backlog”. For each planned customer-identified feature, place a post-it in this area. Large (pink) post-its are acceptable in this area.

Next is the “release planning area”. Its purpose is to group together the features that will be in the next release of the software. In order to transition to this area, large pink post-its must be discarded and replaced with smaller post-its, as much as possible. This implies some sort of planning and estimating meeting. The technique allows for variances in post-it sizes, so do not stress estimating too much. Just break it down as much as feasible. Later on you will have a measurement of estimate quality, and can use that to motivate spending more or less time estimating and planning.

For Scrum users: There is no need for the 2-day items to be customer-focused. At this point, if your client agrees, then you can break-down into technical tasks.

For each release, count and record (on the whiteboard) the initial number of post-its. We will call this the “size of the release”. Later, once we have measured velocity, we will be able to simply divide the size by the weekly velocity to reach the estimated weeks until release.

Next area of the whiteboard is the “current backlog”. This is a prioritized area where higher priority items are towards the top, and lower priority items towards the bottom. The area is limited in that there is only space for 7 items. (7 is a good starting number – you can tweak the number later). The area represents a “turnaround guarantee” to the client. We will say that the client can put anything (sized appropriately) at the top of this area, at any time, and we will have it done within X days. The X days is calculated based on the team’s velocity. For example, if the teams velocity is 1 post-it per day, then we will completely empty the current backlog (max 7 items) in 7 days. Based on this, we can guarantee (not 100%, but close) a turnaround time of 7 days.

When I said “the client can put anything” in the current backlog, I really mean *anything*. The item can be a bug, a new unforeseen feature, or whatever. It does not matter. They write it on a post-it, and put it in the current backlog.

Developers pull items from the current backlog, usually from the top (high priority) down. If possible, they should avoid pulling more than one item at a time.

Next whiteboard area is the “developer assignment area”. Each developer has a small box with their initials. When they pull an item from the backlog, they place it in their box.

Next area is the “impediment area”. When a developer cannot proceed on an item (waiting on purchase of 3rd party component for example) then they move it out of their box into the impediment area. Next to the impediment, they write the reason. While impeded, the developer stops working on the item. They can pull another item from the backlog. Impeded items are escalated as needed. Once they become unimpeded, they are moved directly back to the developer that was working on them.

When done with an item, the developer can move it to a “done” area. This is drawn like a weekly calendar, and the developer simply places the done item on the day on which it was completed. Done items stack up beneath each day (and provide a surprising sense of accomplishment).

If you have additional steps between the developer saying they are done and acceptance of “doneness”, you can add those as areas in the whiteboard. The following is important though:

• If an item needs to go backwards (from tester to developer for example), then the post-it should not move backward – rather create a new post-it and leave the existing one where it is. (This is important to our effort to quantify the effect of poor quality).
• Someone must be responsible for removing items from every area. For example, if no-one is actually doing work on assuring quality then do not invent a quality area.

And that is how the post-its flow. Pretty simple, but by itself, it does not give you much.

The next dimension is the colored stickers. Each post-it is decorated with stickers, in the following way:

• blue - bugs. When an item has been assumed to be done (placed in the “done” area), but a bug is discovered, then a new post-it is added to the current backlog with a blue sticker (don’t move the “done” post-it back).
• green - missed requirements, or post-its that are “broken out” from larger features during development. Green items can sometimes represent just-in-time work-breakdowns. For example, a developer can take an existing post-it in his area, break off another post-it (with a green sticker) and place it in the current backlog.
• red (optional) – for each day that a developer works on a post-it, it is decorated with a red post-it. Too many red post-its is often an indication of a problem that needs to be escalated.

The final dimension is the measurements. There are 3 measurements, taken weekly (first thing on Monday works for me). The me
asurements are all performed by counting post-its in the “done” area. Once counted, the post-its are removed from the white-board. They are:

• Velocity. Count each post-it, except for those with blue or green stickers. Higher is better.
• Estimate Quality. Count each post-it with a green sticker. Higher is worse.
• Product Quality. Count each post-it with a blue sticker. Higher is worse.

And that’s it, in a nutshell.

Velocity is measured relative to the release planning area, which is the only way that is meaningful to a client. Use velocity directly to plan releases and choose a max size for the current backlog area.

Estimate quality is a measure of the risk of using your velocity for planning purposes. Each point was an unknown at release planning time. We did build the risk into the velocity, but a high enough value is…risky. If that is a concern, then you need to spend more effort planning and estimating.

Product Quality is a measure of how bugs are affecting your ability to implement new features. A high value means that you should put more effort into improving quality before saying something is done. This is almost always a good investment.

For me, 2007 was mostly about learning the best way to run a development team in a way that adds the best value to the business.

I became convinced that it is not enough to optimize development locally – to achieve the best value, we must treat development as part of a manufacturing-like process. In doing so, we can understand that requirements are like inventory – they go stale and lose value if they sit around. We also can understand that we need to link the day-to-day tasks we do to business value. Finally, how we define “done” is one of the fundamental questions for any development team.

I already was using Scrum, but began experimenting with Kanban Boards. This showed me that sometimes planning meetings are wasted time. Estimating has value only as much as it assists in release-planning. My newly-won experience is invaluable in knowing how much planning and estimating is appropriate for a given situation. I feel like I could easily fulfill the role of ScrumMaster on any team, or else introduce existing teams to more optimal ways of doing things.

One of the lessons I have learned from being a Software Architect is that you cannot always dictate architecture, but you can guide it by providing simple and effective ways to do things. There are some very strong strategies that can be applied to achieve good long-term viability of software. To this end, I registered a new domain (perfectapi.com), and put up a website on that domain. I did not find the time I needed to do it justice though.

My idea was to try and apply my own hard-learned lessons of software development in a way that improved the architecture for others. This is not a pipe-dream – it has been done before, most recently with Ruby-on-Rails. If you can find the correct paradigms, you can quickly create a community that can be very effective at developing new applications.

In 2005, I had decided not to work on web applications anymore. ASP.NET was just too complex, too barebones to develop seriously on. Ruby on Rails is probably ok, but it has a Unix-like learning curve (I’ve grown used to Intellisense). In 2007, Silverlight was introduced. I have not worked with Silverlight yet, but the feeling I get is that it will change the paradigm enough away from the horrible POST-RESPONSE loop of web development.

Personally, it has been a difficult year. My lone-wolf tendencies have hurt family life, and I find myself with too few friends. I have put on weight. Work was all-consuming at times. It is not that I work long hours – it is just that the hours I work are very intense and stressful. Plus, there is just too much to know – it is a truly exciting period in software development.

I will find a new job in 2008. I hope that it will allow me the freedom to relax more with family and friends.

At my job (a software development company), we use a variant of Scrum to manage our development. We have short development iterations of 2 weeks, at the end of which we deliver something of value to the business.

Since we started though, it has been difficult for the business to accept our output as complete. We did not have any formal acceptance process, or acceptance tests. The result was that we were seldom able to promise a completed feature in a single 2 week sprint, because the acceptance criteria were not clear enough. Each feature evolved to where it needed to be over several sprints, severely impacting our long term planning.

Code quality is good, due to a focus on unit tests, but we struggle to quickly bring a completed user-valued feature to market because we are not able to home-in on what the completed feature should look like.

In recent retrospectives, the team decided that we want our user-stories (planned work items) to be more completely defined. We will require acceptance test documents before we start working on functionality!

A bold step, because it will increase upfront planning time. I was a little nervous of this, mainly because it sounds too much like waterfall – plan upfront, and then deliver per the spec.

I read something that calmed me though, and confirmed (for me) that we are on the right track. Mike Cohn writes that user stories should embody these 3 aspects:

• a written description of the story used for planning and as a reminder
• conversations about the story that serve to flesh out the details of the story
• tests that convey and document details and that can be used to determine when a story is complete

According to that definition, we have been missing a whole aspect of our requirements!

So, we are now using Fit to create automated acceptance tests during Sprint planning. This helps us better define what will constitute success up-front. We will spend more time planning, but we will gain in the longer term because we will be delivering completed client value at the end of the sprints.

Already, the automated acceptance tests have been improving product quality and team communication. We have gained a valuable set of regression tests for the system. But we have decreased productivity in the short term, because developers and testers have had to learn a new tool and re-invent the way we communicate.

Whether the promise of improved long-term productivity follows remains to be seen. I’m confident, but time will tell…