Home | Next >>

The release starts here

I am keeping a diary of the main events during a software release as they happen.

Right now, we are moving (in the client's methodology) from feasibility to detailed design.

For a few weeks now one release has been almost finished and another almost started. For the first time in this cycle I have been able to devote most of my work time to the getting the new release underway. There are several of us working on the new software. Some familiar friends and some new faces. There has been lots of requirements capture by the marketing and analysis teams. There has been a significant amount of thinking during a technical feasibility phase. We have had two workshops with a mobile device vendor who will be building one part of the solution.

The project has been picking up momentum and we need to get started and get started in the right way. It would be very easy to let the waterfall culture kick in at this point and the end of feasibility be swiftly followed by a long detailed design phase. I don't what this to happen. I want this to be the best release we have done to date and I want to deliver it using the best practices at my disposal.

I want to get to a product backlog for this release as soon as possible. I do not want to try and produce a detailed construction plan which requires precise estimates for every deliverable before we start.

We need to supply designs which show our partners and internal clients the responsibilities of the various components which we are in the process of specifying.

While feasibility is coming to conclusion I have started a separate activity with the three other designer / developers on the team. We have this week to produce a set of use cases describing what it is we are delivering and what we expect our partners to deliver. We also are going to produce sequence diagrams showing the interactions between the platforms and components. Hopefully these two activities will drive the definition of the responsibilities, give our solution architect confidence that we are proposing is fit for purpose and enable us to create a prioritiesed backlog.

We spent most of today round the white board elaborating the use cases. Some of the team members have spent a lot of time in feasibility and found this exercise frustrating as they feel they already explored these areas. Others who are newer to the project find it useful. I think it is essential to get thee use cases understood at a high level before continuing. I  think the feasibility stage has produced a mix of very abstract analysis and very low level designs. I do not think he have a holistic view of the solution we are building at any level.