Blog

Lightweight Planning

It was not appropriate to deploy to the ‘real’ customer every iteration for a few reasons, so we bundled new functionality into several releases, each being 2 – 3 months long.

We would have release planning meeting at the beginning of every release, and normally also halfway through to keep track of how we were doing. Such meetings were typically between 1 and 2 hours long. The process would be:

– One of the BA’s would read out the ‘release level’ stories one by one

– For each story each developer would write down an estimate in rough ‘ideal days’

– Once all the stories were read out each developer would sum their estimates

– We would then go around the room and all the totals would be written on a whiteboard.

– From this, we would see a basic idea of how much work the team thought there was

This process was not at all in depth, but it was only meant to give a ‘finger in the air’ estimation. Keeping the meetings short also kept the developers from falling asleep. 🙂

Before each iteration planning meeting (IPM), the project manager, the 2 BA’s and 2 of the developers would have a quick look through the upcoming stories to pick candidates to discuss at the IPM. This decision was not final – it was just an optimisation so that we’d have a first cut of stories to discuss in the IPM proper.

The IPM itself would normally be about an hour long. The sequence of activities would normally be:

– The Iteration Manager (one of the developers) would describe the results of the last iteration in terms of completed stories, total ‘ideal days’ completed, and stories remaining (‘hangover’).

– The team would estimate the remaining ideal days for each of the hangover stories.

– The Iteration Manager would give a rough amount of how many ideal days were left for new stories, based on velocity and how many pairs we had for the next iteration.

– One of the BAs would then describe a story. At this point a combination of 3 things would happen:

+ A discussion would spark up

+ The team would split the story (e.g. because of size)

+ The developers would estimate the story

– Once the story was estimated, another story would be played and the process repeated

– This story description / estimation process would continue until we were pretty happy we had the right amount of work for the iteration based on how many ideal days we thought we needed from the beginning of the meeting.

This process is very similar to what Martin Fowler describes here. Its not particularly precise, but we found it was good enough for our project to work, and at the same time meant that we weren’t bogged down by process.

Related to our planning processes were our tracking processes. These were also kept simple, and were based solely on completed stories (i.e. completed and remaining stories per iteration).

Lesson number 3 is then:

Keep your planning processes lightweight, and adapt them to suit the team and the project

For the last 9 months I’ve been working as part of the best project I’ve experienced in my career so far. The project has successfully delivered into production 5 times in the space of a year, with only 2 production bugs (each of which were fixed and deployed in less than a day). The real customers are happy due to the successful delivery (and relatively low total cost), and so are the project team due to being able to deliver successfully while keeping a sustainable pace and good team spirit throughout.

So, what’s been the secret of the team’s success? As I roll off the project, I want to write down some of the reasons before I forget.

Great People

The core team is 14 people – 1 Project Manager (PM), 2 Business Analysts, 1 tester / admin and 10 developers (including 1 developer taking an iteration manager role). Everyone on the team has been top quality. The most important attributes throughout the team have been:

– Desire for team success over personal achievement

– Knowledge and acceptance of own abilities and limits

– Willingness to speak up

– Willingness to accept the team’s decisions over personal choice

Individually, the PM is the best I’ve ever worked with. The way he has worked with the business (in areas such as expectation management) has been crucial to both the happiness of the business themselves, and the rest of the team.

Its interesting to note that even though there have been 10 developers thoughout, there has been considerable rotation of who the 10 people are. This has been possible due to the qualities above, and also because of practices like pair programming.

So lesson number 1 for a successful agile project:

Create a great team, and focus on getting an excellent project manager

Use Business Analysts as Customer Proxies

Having an on-team customer is a great idea since it means that developers can quickly get feedback for questions about how a story should be implemented, and also the customer can give early feedback for how a new feature is being developed. (Note I say ‘on-team’ rather than ‘on-site’ purposefully to show that the customer is part of the core team – a ‘pig’ rather than a ‘chicken’ in Scrum-speak.)

The problem with using a ‘real’ customer though is that ‘real’ customers also need to do ‘real’ work, and so there is a a conflict of interest between getting their ‘real’ work done and helping the team deliver the project. (This reminds me of the ‘context switching’ problems Tom DeMarco talks about in his book ‘Slack’). There’s other problems with using ‘real’ customers too, but this to me is the biggest.

So on our project we haven’t had an on-team ‘real’ customer. Instead, we have 2 Business Analysts that act as ‘customer proxies’. The BA’s need to do (at least) the following:

– Talk with the customer groups to come up with a set of features

– Figure out how these features can be coalesced into a set of stories

– Communicate effectively with the developers to explain the problem domain, and the stories to be implemented

– Work with the customers to get early feedback (e.g. from UAT)

Having the BA’s as part of our core team has allowed us to keep open and active channels of communication, enabling early and relevant feedback to issues.

Lesson number 2 then is:

Use a pair of on-team Business Analysts instead of on-site customers

These 2 areas have been about people, and team structure. I think they’re the most important lessons I’ve learned from the project. In later entries I hope to talk about areas such as how planning worked, day-to-day team practices, and development practices.

When you want to work on a web application in Visual Studio the default behaviour is to use a project that uses Frontpage server extensions. (Web applications include ASP.NET projects or Web Services.) There are big problems with this:

– Every development environment must have IIS setup, even if its used for working on part of the app separate from the web project.

– Every development environment must have IIS setup, even if an alternative ASP.NET runtime is being used (e.g. Cassini)

– Every environment must have a virtual directory set up with a common name (this is similar to the Common Absolute Paths Anti Pattern)

– Source Control Integration is often problematic

The solution to this problem is to just use plain DLL projects. You’ll need to explicitally add references to the System.Web assembly, but that’s basically it. You’ll probably want to change the Debug and Release ‘output’ paths to just ‘bin’ aswell, since that’s the default for web apps.

One restriction is that out of the box Visual Studio won’t allow you to create a new aspx/asax page and associated code behind using ‘Add new’ on the project for a DLL project. There’s a work-around, but it needs to done for every developer environment. Here’s how:

– Go into C:\Program Files\Microsoft Visual Studio .NET 2003\VC#\CSharpProjectItems\WebProjectItems\UI and open the ui.vsdir file

– Copy the lines that end in WebForm.aspx, WebUserControl.ascx, HTMLPage.htm, Frameset.htm, StyleSheet.css, and the ‘mobile’ types if you want them too.

– Paste the lines into C:\Program Files\Microsoft Visual Studio .NET 2003\VC#\CSharpProjectItems\LocalProjectItems\UI\ui.vsdir

– When you choose ‘Add new item’, the web templates will now appear in the ‘UI’ subfolder (you may need to restart Visual Studio first)

2 notes – if you installed Visual Studio somewhere else you’ll need to adjust the paths, and you should also backup the us.vsdir file you are changing. (Thanks to Owen Rogers for pointing out this workaround)

Some other behaviour you get for free when you do use web projects is:

– Hitting F5 launches a browser window at your default page

– You can debug the server side of your application

If you switch to using DLL projects you can still debug your ASP.NET hosted application by using one of the following alternatives

– The easiest way is to manually ‘attach’ to the ASP.NET worker process (In Visual Studio, go to ‘Tools -> Debug Processes’, and select ‘aspnet_wp.exe’). This process automatically starts the first time you access a ASP.NET resource. Doing this will mean you can debug the server-side of your application as normal.

– Alternatively, you can set the debug properties on the DLL (right click on the project, select ‘Properties’, then select ‘Debugging’ in ‘Configuration Properties’). Set ‘Enable ASP.NET Debugging’ to true, set ‘Debug Mode’ to URL, and set the ‘Start URL’ as required (there seems to be a bug in VS where you need to reopen the properties box to be able to set this last property.)

Benefits to this scheme beyond solving the original problems are:

– Since all source is developed under one tree it is much easier to work on 2 copies of the same project on one machine

– Similarly to the above point, it is much easier to work concurrently on more than one branch of the same project on one machine

– Its faster – visual studio just needs to use file access

– Its simpler – developers are already used to working with dll projects so they don’t need to learn anything new.

– You can compile, and run tests that don’t depend on retrieving web content, without having IIS running.

Some projects I’ve worked on in the past assume that certain files can always be found at an absolute path, eg ‘c:\program files\some cool library\library.dll’. Such files may be dependencies, or deployment target locations. This is a situation to be avoided!

The main reason this is so bad is that you may not actually have control over such paths when your application gets deployed. For example, many IT operations departments use ‘C:’ just for the Windows O/S, and put all other files on a secondary drive (e.g. for backup purposes). If your project assumes absolute paths, such problems may not arise until you finally reach production.

However there are other problems, like what happens when you want to work on 2 versions of the app at the same time (e.g. trunk, and branch)?

But there is good news – you don’t need to hard code absolute paths into your system! Alternatives are:

– Use relative paths. As an example, setup your source control directory structure such that you always know where your dependencies can be found relative to your project’s source code. (This may mean you save third-party binaries in source-control but this is not a sin!)

– Use deploy-time configuration. Get your build environment to generate environment-specific distribution files where parameterised paths are expanded to absolute paths at the last moment.

– Use environment variables, like path. This is a ‘last-chance’ option since it is system-wide, rather than application-wide in scope, but stops you having to hard code paths in your application at least.

To check that a project I’m working on isn’t using absolute paths, I tend to do one of the following things

– Have 2 copies of the development tree checked out on my machine. Switch between them occasionally and check nothing breaks.

– Have my continuous integration and ‘development test’ environments specifically use different paths to that of the development team.

A couple of weeks ago I was at XP 2004. Due to my goldfish-like memory I’ve already started forgetting what happened, but here’s some things I do remember:

• It was good to meet new people, like Angela Martin, Rick Mugridge, Charlie Poole and the Exoftware folk
• It was good to catch up with people I’ve met before like Josh Kerievsky and hang out with my fellow Fowlbots Chris Stevenson, Chris Matts, Ivan Moore, Martin Fowler, Owen Rogers and Steve Freeman
• Hot Topic number 1 – the customer role (including a great panel.) Chris Matts has blogged a tonne about this so go read it!
• Hot Topic number 2 – acceptance tests. There’s a still a huge amount of debate about what an acceptance test is, and how to implement them (e.g. Fit is not a panacea).
• Talked with Charlie (NUnit) and Owen (fellow CruiseControl.NET project lead) and others about .NET tools. We’re going to work more on Mono compatibility if we get some time
• I presented my paper on Enterprise Continuous Integration. The demo I gave is available here, the paper is available here.

Those Atlassian boys have done it again. First I became a fan of Jira, and now its looking good for Confluence too.

Confluence is at its most basic another wiki clone, but its a nice looking, easily editted one at that. After a few minutes using it though you realise why its going to blow all other Wiki’s out of the water, with features like:

– arbitrary page hierarchies

– exports (of whatever selection of pages you want) to pdf and html

– separated ‘spaces’ for topic consolidation and security

– rss feeds for various events

But then after a few minutes more you suddenly get the ‘wow factor’ when you start using its dynamic macros – inlining things like

– search output, child page lists, etc.

– abitrary RSS feeds

– Jira issue reports

… etc. They’ve even done their own implementation of Fit called FatCow which you can just use like any other Macro. You can write your own macros too, just to add insane power to the application.

Its not perfect yet, but for a 1.0 release it has a very ambitious feature set so I’ll let them off. Things that could be better:

– RSS and blogging features need some work – these are powerful things, but really they could be better (e.g. blogging in a context smaller than a space, better (or maybe more obvious to use) RSS outputs)

– Usability is good, but it still takes a while to get going as a new user. Jira’s got better on this front, so I expect later versions of Confluence will be easier for newbies too.

We’re using it already for CruiseControl.NET – check out our space here.

I’ve been using Mozilla Firebird as my browser for a while now. Its had (another) rename and is now called Firefox.

One of the best things I’ve found with Firefox recently is Type Ahead Finding – just start typing and Mozilla will highlight a link. To skip to the next result, hit Ctrl-G; to open the page hit Enter; to open the page in a new tab hit Ctrl-Enter. I’m not normally a keyboard shortcut fan, but this really speeds up navigation.

Oh, and Flash works now. 🙂