Sustainable pace

One of the great things about Agile software development that I’ve noticed is sustainable pace. Planning poker, point based estimation and velocity are all great tools for finding a team’s sustainable pace. Knowing a team’s velocity and consistent estimating by the entire team, allows a team to commit to as much work as it is (increasingly) likely to complete, and complete consistently.

As well as properly managed expectations, a sustainable pace has the benefit of ensuring the quality of a team’s work is consistent. When the team is working at such a rate, there is no crunch time, there is no working late. As developers, working beyond our capacity can result in long lasting problems. Beside the whole no life outside of work thing, it also affects the quality of our work. Which always results in cost later in the life-cycle, be it with maintainability or bugs that come out of last minute fixes.

So I sound pretty sold on this whole idea don’t I? Well I am, and I’m almost proud that one of my close friends always leaves the office at ‘hometime’. I taught him both he and his work would be better off than if he stayed behind to finish that last bit! Well this all bit me in the butt recently and it I’ve noticed it has definitely killed off a great part of the job. The Programmers Hi-Five.

So some 6 weeks ago I was handed a project that was ambitious to say the least. I was asked to take our biggest product, which made the most money, and was closely watched for compliance, and rebuild it. No pressure. Being such an important product it naturally followed that it was the most hideous piece of ill maintained code we had. Given said compliance issues we were also not allowed to deliver functionality incrementally, as it was all required to stay compliant. [see curse of the rewrite].

All of this was to be delivered by one of the hardest deadlines we had ever had. As a business there’s an awful lot of buy in in to the whole agile thing, It’s something I’m quite proud of, but this wasn’t very ‘incremental’. So with all of that in mind, I agreed to do the project. As much as I love what we do and how consistently we do it, I work best under unreasonable pressure. I don’t understand any other kind of deadline.

Oh and did I mention it was with a fresh team that hadn’t worked together before? All good fun.

Given a mighty fine team and even some license to rework our QA process we worked ourselves hard. Often staying late, sometimes because we were in the groove (the best kind of working late) and sometimes just to make sure we stayed on course (the worst). We even worked for a few hours on the weekend. Once.

I’m getting mighty long winded, so I’m going to try and summarise the rest:

Good things:

• Pushing ourselves that hard meant we achieved a lot in a short space of time.
• We had to work hard to ensure quality throughout, but that has certainly brought new in sight on how we can improve our QA process going forward.
• The team gelled very quickly. I don’t think we’re done, but I certainly witnessed us passing through forming and storming in an iteration.
• Programmer Hi Five. A whole lot of satisfaction when something came together. I don’t know why this doesn’t happen more often in the normal course of a project. My hands have never stung so bad.

Bad things:

• From outside of the team and maybe even from within the team at times, we appeared to not be in control. Almost firefighting. We weren’t (always) but I’m sure as a team we’d prefer to give the impression we knew what we were doing at all times.
• We don’t have a velocity. We worked too hard to be able to find a velocity, in the upcoming ‘normal’ iterations I have no idea how much work the team is capable of at a Sustainable pace.
• Left behind. The amount of work we had to do meant often more junior members of the team were left to fend for themselves.
• Cool down period. We need a cool down period, luckily this all happened at the end of the year. The only time for it if you ask me. Hopefully it won’t be difficult to ramp up after this.

So I think we should throw out sustainable pace once in a while. (I’m thinking once every one or two years). Just to remind ourselves of the fun we had as hackers, and why it’s so much better as developers. The Edge of Chaos is fun.

Our first good acceptance test

In an effort to get our teams understanding ‘Done Done’ we’ve started looking at acceptance testing. We’ve moved, over the last 18 months or so, from a traditional waterfall process to a full on Agile one, our final hurdle is the QA process. We still have a very waterfall-esque QA approach.

We’ve done lots in terms of getting QA involved early on, making environments available for the different stages of testing. But we still have a major problem where by all our QA tends to get done once the developers yell ‘FINISHED!’.

The problem is, we developers tend to lie. Not knowingly, more out of a desire to move on to something more interesting. So even though we may be making our burn down chart look a little neater, we’re in fact delaying the inevitable. QA return to us our shiny code, complete with bugs we never thought possible.

So recently, we’ve started looking at Fitnesse in an effort to bolster our QA efforts and also to bring more light on to the process that is QA. If we get more people looking at it, we can surely all help to improve it by offering new tests and finding ways to improve how the existing tests work.

I’ve known about Fitnesse for quite some time, since CITCON made it to London, my first open space conference. However, even then the general consensus was it was great, but quickly turned in to a beast to maintain. This problem still remains, as from the recent alt.net conference, Gojko himself said, it aint great, but it’s all we got.

I’ve waited too long for someone to come up with a better alternative (whilst keeping an eye on J Miller) we’ve started to give Fitnesse a go. I’m doing my best to ensure we don’t fall in to the pitfalls people have done before. My main gripe would have been the need to build fixtures. I have heard many a nightmare about the fixtures replicating ‘value’ already given by unit testing, fixtures being brittle, and requiring as much effort as production code to keep going. These are all things I’m tying to keep us from.

So recently my new team showed me our second good acceptance test, the first one referred to in the title that inspired this post was by another team which I used to experiment with. The approach I’m taking, is to use the FIT approach against the parts of the system that have to handle all the ‘scenarios’. We’re following a flavour of SOA that I like (not full on SOA, that still makes me uncomfortable). We’re also cleaning up some of the more terrible examples of misplaced responsibility we have. This gives us an opportunity to move domain logic from the ASP.NET front end (urgh) to the places it belongs.

The SOA gives us a nice potential for isolation. That means we’re able to get our examples from the business (or indeed from the beast that we’re rewriting) and feed them in, table like, to check the code we wrote was the right code! One thing I really don’t want to get hung up on is driving selenium or other slow front end tests from Fitnesse. That would just give us the illusion of acceptance testing when all we’d really be doing it moving are old fragile, brittle, slow selenium tests into a fancy wiki that no one would read.

But I’ll come back to that later. One decision which we’ve made, and now you might disagree with this, is to tie the fixtures directly beneatch the WCF contract stuff we have for the service. this means it talks to a more pure, less noisy version of the services the service offers. This so far has allowed our tests to read quite clearly in terms of what makes up a table. It has also hidden quite a bit of fluff we use to on all our services which qould give our fixtures another reason to be brittle.

It does however mean that we wouldn’t pick up an problems with the WCF layer we put atop. I’m going with this is an OK trade off considering how good it felt to see 400 test cases passing and 100 failing. I never thought I’d enjoy seeing red tests so much!

Me feels I need to be more specific (and more frequent!) in my blogging, maybe if I don’t let post sit in drafts for 2 weeks they’ll be better. Hopefully there’s more on acceptance testing to follow!

Agile session Alt.Net London

So to start the conference I chose to take part in a session about agile development and processes. I think mainly because I wanted a refresher on some of the points and to see if I could contribute. It’s nice to see plenty of people there new to Agile as I was at my first open conference. Learning the basics of the process, and making a good start. I was also interested to see how people had developed from their initial attempts at introducing Agile to their shops.

At one point there was a lot of talk about how we estimate, and I was surprised to see that everyone had assumed estimating in hours and half days. Assigning some time to points and then estimating with points. I wonder what happened to estimating by points representing complexity. At uSwitch, when we introduced planning meetings and planning poker, we started with 5 points to a day. This was mainly to get developers used to the idea of estimating in points and as a team. Over time in teams where this method had remained, they have naturally loosened the tie between the points and the number of hours they represent when estimating. They still use the rule to define how much capacity they have in a given iteration, 5*Devs* 10days = capacity.

For me and my teams, we’ve moved this to the next logical stage of entirely decoupling estimation points from time and tying them to the complexity of a task. Has this gone out of fashion and no one told me?

I think I’ll break this off into a separate post on estimating

Crystal and full project breadth

Ian Cooper shared with the group the method or agile flavour he’s using with his current team, it’s called Crystal and sounds interesting. It sounds like the emphasis of crystal is the continuous improvement and customisation of the process to your team and project’s needs. A quick bout of googling tells me that the following has not much directly to do with Crystal. From what I’ve been able to gleam (and it’s not much) Crystal is primarily focused on improving methodology frequently, aiming to minimise it’s weight.

The main point that Ian brought up that caught my attention was the move from the pure priority prioritisation to a more whole system or breadth approach with incremental refinement. Purely working of stories by priorities, apparently leads to systems that have a lot of work and attention spent on apparent high priority sections while those features and functions that the client may deem as a lesser priority are essentially neglected, typically tacked on the end of the project. This can lead to seemingly unfinished projects (my conclusion).

The three thirds approach that Ian described seems to encompass the entire system with increasing levels of ‘focus’. The first phase is the ‘Walking Skeleton’ this is just enough of the entire system to get something going from a technical perspective, this might take up most of the ‘framework’ stuff that one has to do to get a project going. Many people likened this to an iteration 0, which doesn’t deliver much or any business value but is necessary to build something you can demonstrate.

The next phase delivers the ‘First Business Value’ taking the walking skeleton and adding enough to actually add to what the business has, making a contribution.

Here is where my notes get a little woolly and I wish I wrote this post while I was in the room! The final phase adds all the other features, improves on the initial business value, works on feedback from the client on the second phase, and perhaps includes changes to requirements.

From the weakness of those last two paragraphs, I think I’m definitely going to do a little more research, so check back for a bit more bulk in later posts.

This notion of increasing the focus with subsequent iterations really did intrigue me, and I’m definitely going to see how I can apply it to our next project.