Probably the most straightforward way to bring some agility to your process is to introduce iterations to your development. It was the most obvious starting point for me and our team anyway. An iteration, as I see it in this post, has following properties:
* It has a fixed length. Typically the length is from one week to one month.
* A product increment is implemented within an iteration. The product increment should have some value to the customer or at least to some user. It should be also shippable meaning that it can be deployed into production if necessary.
* Iterations don't mean rework: Certain number of stories are completed within an iteration and after that they are not normally reworked in the following iterations.
I started writing down some of the advantages this kind of iterations bring along and here is the result. I have been reading Crystal Clear by Alistair Cockburn and some of the things presented here are from that book. Some of them are actual experience that we have gained when using iterations in our projects.
Project planning and control
Iterations are a tool to do project management. Traditionally, in the non-agile era, the project manager was the ultimate authority doing most of the planning, estimation, work allocation and so forth. This fuhrer-style management is not very motivating for the team members. Additionally, if the fuhrer does all this in isolation the resulting plans are likely to be suboptimal. Nowadays, in the Agile era, the whole team is involved in these tasks. The project manager (or the technical lead) is responsible for coordinating the activities. This management version is more effective than the traditional version in many ways and I will discuss some of those next.
Before the iteration is started you have a planning session where the whole team (plus other stakeholders) sit together to check priorities and do estimates. Usually some design is also needed when doing this: Stories are split into smaller stories/tasks that can be estimated more accurately. Involving the whole team in this planning activity is a good thing. It promotes motivation and team spirit. The team will be more willing to commit to the plans they have themselves created together with the customer. Our experience with this approach has been positive. The team involvement is one of the most valuable things that our agile-like-process has provided us so far.
Iterations provide a way to track progress. Only running tested software is counted as progress - Specification work, for example, does not count and neither do features that are "80 % completed". The remaining 20% may contain surprises, and it usually does, when we are talking about SW development. If you follow this rule of counting only running tested software, it is clear what was achieved in an iteration. At the end of the iteration you know the team's velocity and that gives you a good starting point to estimate how many more iterations are needed to complete the project.
Gantt charts?
My opinion is that Gantt charts don't work well as a project planning and tracking tool. In the projects I have worked in during my career, the "project plan" has almost always been in the form of Gantt charts. Perhaps the most important reason for this is that MS Project uses them by default. Software development is so unpredictable that the chart will be out of sync with the reality soon after the project has been started. The inaccuracy of typical estimations is another reason why the bar lengths in the chart either lose their meaning or cause unnecessary delay. The delay comes when the developer tries to change the reality in order to stick with the plan. A typical developer will use all the time that was allocated for him to complete a task either doing unnecessary polishing or by simply slacking off.
The iteration approach is much simpler and works in practice. It also helps in squeezing maximum productivity out of the team! There is no room for unnecessary polishing or slacking off. You will not be able to get as good results if you base your planning and tracking on Gantt charts.
Quality
Iterations are a way to get early feedback from the real users of the system. This requires that you either deploy the product increment to the customer's server (or users' workstations) or alternatively organize a demo for the users.
Iterations also provide early wins for developers. The team should produce working software starting from the beginning. To make this clearer, here is an example plan that does NOT use iterations correctly:
- 1st iteration: Functional specification
- 2nd iteration: Architecture specification
- 3rd iteration: Database schema
- 4th iteration: Infrastructure
- etc...
This approach will not produce early feedback or early wins. The developers have to wait until iteration 5 to see the first complete features. It is better to organize the development in such a manner that working features are created starting from the 1st or 2nd iteration. You need only enough planning, database tables and architecture to support the first set of features. More tables, more design, and more infrastructure is created as more features are implemented. The architecture also evolves when the project goes on. The first complete feature that uses all the application layers proves that the design decisions are correct and that the chosen technology can be used to create a functional system. You and your developers need this information as early as possible.
Process improvement
After the iteration you can have a session where you reflect what was good and what could be improved. You pick two or three things or practices that you think will improve the way the team works and develops software. The team will try these in the next iteration. And after the next iteration you reflect again to check if those practices were good or not and act accordingly. If the iterations are short enough the improvement will be fast!
I like this approach of trying things out. What I don't like is that there is some authority, like a project manager, or an Architect group, that comes and says that "from now on you will do this/that and, by the way, you will also use this framework because our architects decided so". Again I find that it is much better to have the team plan together how to improve their own way of working. The result is that the team will be more motivated to follow through.
Team communication
As I already mentioned above, iterations provide two points where a lot of teamwork is involved: The start and the end of an iteration. In the start there is the planning session and at the end there is the retrospective. Both of these provide an opportunity for the team to get together. This is of course more important if the team is distributed, like it has been in our case. If the team is collocated and sitting together (like it really should), the value of this is not so big because the team is already communicating a lot in the course of normal day-to-day work.
Recent Comments