I’ve been working with a team at a company in New Zealand recently, mentoring and coaching their implementation of Agile practices.
Last week we had a series of workshops to scope and define a new project. This is a major rewrite of all their branch systems, with an SOA link to the core legacy system backend. The basic architecture has already been defined, largely based on the existing technology environment the company works with.
The team consists of project manager, iteration manager, developers, testers, business analysts, the project sponsor (senior manager responsible for the branch network), a branch manager, and four branch staff members– one from head office, three from branches around the country.
We started the workshops with the project sponsor setting the scene – explaining his vision for what the company is trying to achieve. We then used a brainstorming approach to define the key success criteria for the project. Each person wrote their own understanding of their key success criteria for the project on post-it notes which were then stuck onto a flipchart. We grouped and clustered the statements, following which we agreed on the key drivers for the work (which is more important – deliver on time, meet budget, meet functional requirements, meet quality needs …).
Once we had a common understanding of the goals and drivers for the project we spent the bulk of the afternoon of the first day identifying key stakeholders, constraints, assumptions and risks – again using a brainstorming and discussion approach. We ended the day with a set of flipcharts around the room that identified the overall scope of the project, key success criteria, assumptions, constraints and risks (with trigger points and mitigating actions identified for the currently agreed most important risks).
We then defined the key features that the new system needs to have in currently understood priority order. This formed the basis for the next day’s discussion about specific features and releases. The second day started by reviewing the wallware from the first session, double-checking that we had a common perspective. A number of items were reprioritised at this point as people had pondered them overnight.
We then took each feature in turn and broke it down to the level of user stories. Some of the stories were in the <as a> <i want> <so that> structure, but most were simple one-line statements of high level requirements. We then prioritised the stories and roughly grouped them into three releases.
It is understood that the releases are not fixed, but this is an initial starting point. We focused most of the teams’ time on features and qualities which must be delivered in the first release, which has a clear target date. The remaining features have been identified and ordered, but only in a loose fashion – this is expected to change as we actually do the work.
One clear outcome that has already been of benefit is the way expectations have been set. The project sponsor acknowledged that their initial goals were unrealistic, and already expects to either cut scope or spend more money than was originally allocated.
The business analysts have found that their role is largely facilitating the workshops, and asking a lot of “what if” questions. They are also taking responsibility for recording the decisions that are being made in the workshops and keeping the team focused on the task at hand.
The next step is to take the top 10 or so stories and expand them in detail. A workshop has been scheduled, involving the same team for next week. The technical team are setting up environments and doing all the iteration zero tasks in the meantime, so we’ll be ready to start work with the workshop.
I’ll post another message explaining what happens with the next workshop – we’ve labelled it “story elaboration” and the intent is to expand on the stories so the team can start work on iteration one immediately after the workshop. The key user representatives will be collocated with the technical team for the duration of the project and there is strong management support, so the project should be set up for success.
Many Thanks to the team – you know who you are!
Posted by Shane Hastie