The paper covers two topics: Project Management and Agile Teams. Both go hand in hand, in that you can’t be successful in one without success in the other. As always, I welcome all comments.
Project Management, the traditional way
The "Traditional," or "Waterfall" method of project management has been in use, in some form, since the term Project Management has been around. The basic steps of this method, in software development are:
1. Plan – Simply planning and securing the resources needed for a project
2. Analyze – Gather the requirements for the project
3. Design – Perform the technical design or model for the project
4. Code – Write the software
5. Test – Test the software with some sort of QA methodology
6. Deploy – Deliver the project to the customer
7. Customer Acceptance – The customer accepts the project as complete
The term "waterfall" is used when viewing the above steps in the following chart:
The application of the waterfall method requires each step of the process to be completed prior to starting the next step. Think of the steps above as a container that can hold water. Once the planning step is full of water, it will then spill over to the next container, which will fill up, and so on.
There are several benefits to this approach of project management:
Once the Design piece is complete, a fairly accurate estimate can be given for the project in both resource time and duration.
Everyone on the team is working from the same analysis and design specifications, so everyone understands the "big picture."
When the project is deployed, the customer has a complete product with which to work.
There are also some disadvantages to this approach of project management:
High risk – Once the design piece is complete, and an estimate is give, there is a risk that the project will not continue. At that point, the time spent, even if funded, is wasted.
High risk – The possibility exists at any point in this cycle for a problem to be found that was not considered in the analysis or design phase. If this occurs, it may be necessary to back up some steps and start from that point again.
Due to resource allocation, there may be a lag from the time one step ends and the next step begins.
The customer must wait until all six development steps are complete before they have access to the product.
The customer is forced to do all of their testing on all features of the product at once, at the end of the development cycle.
The customer must wait until all seven steps are complete and accepted before they have a usable product.
Even with these disadvantages, there are some projects that will work perfectly well following the waterfall method. These tend to be very small projects - since they are short term, the risks, as shown above, tend to be smaller.
Project Management, the agile way
The Agile Manifesto was created in the late 1990s by a group of developers and project managers that realized a need in their community to simply make things better. They focused on massaging the traditional method of project management. Remember, when used on small projects, the traditional method works just fine. The basis of the agile way is "iterative releases," and when you take a new look at the project management chart, with the same steps, you can begin to see the advantages:
The only thing that has changed in the model is that instead of completing each step for the whole project before moving on to the next step, each step is done based on a single functional point. All the players from the waterfall method are still playing, but their playing with a much smaller ball. In fact, each feature should be able to go from the analysis phase to the deployment phase in no longer than two weeks (10 working days). Once of the fundamental reasons this works, is that it’s easier to work with a "thing" than with an "idea."
There are some pretty hefty advantages to this method, when compared to the waterfall method:
The customer now gets to try out each feature as they are completed. This allows them to add their input at the very early stages of the process, instead of at the end.
Resources in each category are not waiting around for all of the previous phase to be completed, which means that programmers are always coding on the project and testers are always testing, etc.
The interaction between the phases is on a much quicker pace – i.e. a feature is tested immediately upon its completion, while it’s still fresh in everyone’s mind.
The customer sees the progress of the project based on the functionality they see, rather than a "progress report."
Most of the risk that was stated as disadvantages from the waterfall method are gone completely, or greatly minimized.
Even with these advantages, there are some disadvantages:
The customer will no longer be able to get the "fairly accurate estimate" up front.
The customer has to accept that they will be testing and evaluating the features throughout the project’s life cycle, and be prepared to give feedback.
Project Management with Feature Driven Development
The third method of project management is called Feature Driven Development (FDD). The FDD method builds off the "Agile" method, but has one major difference: The planning and analysis are done in their entirety before the coding begins.
The two things that come out of the analysis phase of this method are an overall model of the project, and a detailed features list. The model is the 10,000 foot view of the project. The features list is a categorized list of features that are to be delivered. The features in this list are put into the following categories: Must have; Should have; Could have; Won’t have. The features are worked on based on their priority from this list. It’s important to note that once this features list is accepted by the customer, a "hard" need-by date for the project can be scheduled, with the understanding the there may be some of the C and S features missing.
An Agile Development Team
An agile team is a subset of a department of agile developers. It’s also a team where the most talented programmers are still programming, and not forced into a management or supervisory position. A typical agile department is set up like this:
The Manager of the department is responsible for resource allocation, staffing, and supervision of everyone in the department. When a project is required, it is the manager that will assign the project to a Chief Programmer.
The Chief Programmer is the person responsible for getting the technical aspects of the project completed. The CP will model the processes and features, and then pull resources from the Programming Staff, with the approval of the Manager.
During the project, the CP monitors the work being done, does some coding him/herself, and conducts code reviews with the programmers.
At the end of each project, the CP will submit a review of programmers’ performance for that project to the Manager. This provides regular feedback to the manager about a programmer.
The Programmer is a resource used to complete the project, under the guidance of the Chief Programmer. There can be varying levels of programmers (trainee, senior), and different areas of expertise (interface design, business logic, database). Because the Chief Programmer is providing the design for the programmer to work from, and because the programmer is working on individual features, they do not have to be product experts.
This team design does not force the best developers into supervisory positions. It keeps them where they are most useful (and profitable). Some studies have shown that the "A-list" programmers in an organization can have between a 10:1 and 50:1 productivity advantage over average programmers. Based on this, there’s no reason to force someone into a position outside of development. As a CP, they are working on the projects directly and are able to mentor others.
The agile development team will use development practices to obtain the goal of project completion. Some of these practices are:
Test Driven Development – Writing test cases BEFORE the coding for a feature is begun. You have to know what you’re trying to accomplish before you set out to accomplish it.
Pair Programming/Code inspection – Having two sets of eyes on every piece of code. This has been described as the single most effective way to catch bugs in software.
Refactoring – Software evolves as time goes on.
Collective Ownership – Everyone on the team is responsible for the entire project.
Continuous Integration – New features are added constantly. No feature should take more than two weeks from design to deployment.
YAGNI - You Aint Gonna Need It! The art of not writing software is as important as writing software.
Wait – Make final decisions as late in the cycle as possible. I.e. a GUI and business logic can be designed and written independently, and the last step can be how they communicate with one another.
Conclusion
The position of this document is that in order for us to write better, more robust, more bug-free software, we must adopt these practices. All groups within the Product Development department (Business Analysis, Software Development, and Quality Assurance) must change at the same time in order for this to work efficiently. The majority of work must be done in projects, and these projects must have a team of dedicated people working towards the goal of project completion. The Product Managers, the Developers, and the Testers would need to all be working on the project at the same time in order to create the iterative releases that are so vital to these methodologies.
