exortech's Journal

RipTown going ahead and QuickStart kicks off
Monday began with the usual team leader meeting. I presented a graph demonstrating how the short build times that we achieved have led to a fewer broken builds per day and overall more successful builds per day. There's still more work to do on build improvement (we're still up around 25 minutes), but at this point we should probably wrap up the work considering it to be good enough (replacing the installer projects with NSI would make a big difference allowing us also to use the nant task instead of devenv).

Over lunch, Josh, John and I met with Derek and Corey from RipTown. They're keen to move ahead with a new engagement and we've agreed to get two ThoughtWorkers on the ground as soon as possible. Prior to the meeting, Josh talked about the importance of emphasising that starting the engagement is aligned with starting a new project. This matters because it sets the expectation that we are not just doing staff augmentation, but that the client is starting something significantly new by partnering with us. It also puts us in a better position to assess and define the charter and scope of the project.

In the afternoon, I worked with Boris to create a query that would identify all unindexed foreign key columns in the database. The goal is to identify any columns that may cause deadlocks or may be performance bottlenecks.

Tuesday was the first day of Karla and Nicola's QuickStart-lite. On the whole, things went pretty well, though the most important parts were the unplanned discussions that happened. Because we haven't been running regular retrospectives, the group had a pretty large accumulated backlog of unresolved issues and this workshop was the first opportunity to discuss them. Particular points of interest:
- we constructed a stakeholder map and ranked stakeholders by their level of "disenchantedness". We spent some time exploring what it was that made them disenchanted with IT and our sense was that it was caused by two factors: the frequency of IT delivering features that solved their problems, and the rate at which we created new problems for them. Stakeholder influence was also directly correlated to how far downstream they are from the customer (with accounting, as usual, at the bottom). More discussion is needed on how to balance the needs across all stakeholders.
- we reopened the old nugget of projects vs releases vs products. This was probably the most comprehensive discussion that we've had on the subject. The prior definition of a project was a chunk of work that would fit into a release. This directly contributed to larger releases because there was a certain fixed scope implied in the project name. In order to move to shorter (monthly) releases, we need to decouple projects from releases. Projects are still needed to communicate and track the delivery of a chunk of scope (at least as long as our stakeholders are outside of the team).
- we also tackled the question of who should manage the release. Because of the division within IT between development and QA, the current situation is that the project managers manage "projects" (aka development and analysis) but QA manages the release. This creates some real problems for managing the whole release cycle. There was fairly broad consensus (with a bit of hold out from QA) that Joy needs to be able to manage the release and we had some discussion of what needed to be in place for this to happen.

Current Mood: calm
Current Music: None

Advertisement