- Fixed price
- Fairly fixed functionality
- The client prefers a RUP-like delivery
- A virtual team - i.e. team members are distributed across the globe
- The entire team shares responsibility (flat organization)
- Very detailed project status always available
- Challenges detected very quickly
- More freedom = more innovation
- The process is very visual
- There are great tools available to support the process!
The client prefers a RUP-like interface
We divided the project into the four phases: Inception, Elaboration, Construction and Transition.
The Inception phase worked as one would expect for a project that starts with a bid stage.
The Elaboration phase however was shortened considerably. I, as the technical project manager and lead system architect, created the SAD (Software Architecture Document) and SSDS (System Software Design Specification) documents containing the basic outlining for the entire project. This step is necessary for a fixed price project either way for us to be able to deliver a detailed time estimate to the project manager and steering committee. We also communicated to the client that the design will continue to grow during the Construction phase.
The Construction phase was broken down into four client deliveries. Internally, we broke down these four client deliveries into 16 Scrum sprints of three weeks each. We will thus have 4 internal deliveries for each client delivery. The time estimate from the elaboration phase contained a rudimentary break-down of activities. These were fairly easily broken down into product backlog items (PBI's). A product backlog was thus easily created. And as the four client deliveries each had a "theme", it was also fairly simple to decide PBI priority.
The roles of project manager and technical project manager still exist in the project. I still do believe that a project manager and a steering committee is important for a successful project, at least for my company since we deliver projects as a service for our clients.
Fixed price and functionality
The product owner became an internal role - the technical project manager (me). One of the developers became the Scrum Master to separate concerns and to delegate responsibility.
Fixed price means that we as developers are restricted when we do our sprint planning meetings. We are free to move time from one product backlog to another. BUT - as soon as we find that we need more time (i.e. the time estimate was wrong) we need to escalate this to the project manager in the form of an "overrun risk".
In Scrum, the work spent in itself is not very interesting, only the estimated time left. However, in fixed price projects, we also need to measure time used. When we spend considerably more time than the allotted (estimated) time on a sprint task, we need to report this as "overrun" to the project manager.
We also need to consider change requests. A Change Control Board (CCB) is available and handled by the project manager and the technical project manager together with the client. Generally, the developer need not be concerned about this process. When the client requests a new feature, the CCB manages this, and finally a new PBI is added to the backlog.
Virtual team
No matter what process used, the team will deliver better when they are gathered at one location. However, this will not always be possible for a number of valid reasons.
In my project we all meet regularly at one location, especially during spring planning and retrospective meetings. We run daily Scrum meetings as usual, but over conference phones.
We also use a tool to manage the Scrum process. The burn-down chart and sprint task board are both virtualized using Team Foundation Server (TFS) with some open-source add-ons. More on this environment in a later post.
To summarize, a Scrum-like methodology gives your team a lot of power and freedom. I believe it is possible to use this method in most scenarios. And I think your developers will truly love to work in the environment that the system gives you!
0 comments:
Post a Comment