Delivering software - retrospective-input tag

Distractions

Wed, 26 Nov 2008 22:35:00 GMT

We are still getting distracted from our main task. Two of the four developers have spent more than 50% of their time looking at a production memory leak. I am spending a lot of time doing interviews and attending meetings. All of it is important but it is impeding progress badly.

Welcome to the waterfall

Wed, 26 Nov 2008 22:12:00 GMT

We have made some progress in the last week of development but it has not been as I envisaged. We have spent a lot of time talking through the use cases and that has helped the dev team understand some of the issues facing us. Those use cases have been typed up using our standard template but they lack structure.

I traveled to overseas for a technical alignment meeting. 05:30 start. Back home at 21:30. Shattered. All for thirty minutes where I stepped through one of the sequence diagrams. It was helpful as for that one use case we have agreement on the design. Half an hour for an extended day (which took me another day to recover from) is not startlingly efficient.

What we have failed to do is produce the product backlog. Instead we have identified some massive issues around complexity and spent days trying to thrash them out. This has also involved presenting back to the stakeholders and trying to educate them on the relative cost in complexity in comparison to the possibly limited returns in functionality. We failed to make any impression and were told that they would reconsider but the the requirements would stand unchanged. Not sure who is doing something wrong here.

We are now slotting back into the feasibility process that the clients financial processes mandate. We are producing very short summaries of the options, impact on required functionality and potential risk (expressed as a percentage). We are doing this for the entire scope of the project (9 months). This does not feel agile at all as we are having to sketch out designs for the entire system. We cannot get round this as completion of the feasibility is a payment milestone.

I am also finding that the feasibility document in its current form has been overloaded with very detailed design narrative. The narrative captures the developers thought process through out the exercise. It makes the classic mistake of documenting parts of the solution we have since discounted because the author has a significant emotional investment in those words and cannot bear to see them all deleted. The detailed design narrative also needs to go (hopefully). I am thinking of it as necessary scaffolding for the developers thought process. It helped them organize their thoughts and was useful. Now it needs to be binned as it is already out of date and has no audience.

The release starts here

Mon, 17 Nov 2008 22:50:00 GMT

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.