Why should you look at Agile Development for Software Projects?

If your organization applies a waterfall project management approach successfully then don't change. The use of an agile method should be motivated by challenges in your current approach.
If a project does not deliver the requested product within the agreed upon time and budget on a regular basis then you should be looking at Agile Project Management. I've been involved in countless projects (big + small) at various companies (e.g. Fortune 500 and midzide) during the last 17 years and I see the main advantages for Agile Project Management for Software Development Projects  in the following points

• Agile Projects have a lower risk than waterfall projects because in agile the hardest, riskiest problems (e.g. architecture, integration etc.) are addressed first. Therefore early in the iterations (e.g.sprints) it is possible to see what the true team spirit, individual skills and available tools are like.
• Agile Projects work with change and not against change like waterfall projects. In a Project many requirements change for various reasons. To try and address all possible scenario's upfront is not only challenging but, especially in bigger projects, impossible.
• Agile Projects are less complex because the complex projects or phases are decomposed into mini-projects that are manageable
• Team Confidence and Customer Confidence in the team are increased because the Customer can see early visible progress. This is a psychological factor that is important for individual satisfaction and team building.
• A partial product is available early. The Product is integrated and tested and gives the client a chance to confirm that this is the direction they want to go.
• Agile Project have a higher predictability. In waterfall projects the planning is done in the early phases where you tend to have less information and therefore the planning has lower reliability which means schedules can vary widely. In agile projects you need to schedule less during each iteration and have a tested software at the end.
• Agile Projects have a higher quality. This is because the testing needs to happen early, often and with less functionality because of the short iterations. In waterfall projects the test plans can be massive (several thousand test cases) and when one functionality changes it might impact other (already tested) functionality.
• Early customer feedback ensures that the final product better matches what the client really wants. After every iteration the customer sees and evaluates the product. This gives the client more opportunities to correct course. In waterfall projects the client only sees the product once everything is developed. If anything needs to change that would be expensive because of the complexity. 
• Agile Projects ensure a better communication between project teams and client. Since the delivery cycle is shorter and the product has to be ready for release the team and the client (business requirement) need to work closely together. If anyone procrastinates tasks it will be visibile quickly.
• Agile Projects tend to have an increased productivity because every 30 days some Software is released to production. This clearly drives the focus towards that goal whereas in waterfall projects the release date might be so far out that it is considerably more challenging to focus on it that much.

In case I wasn't clear, please take the above points seriously into consideration before you run the next waterfall project for Software Development.

Quality for Software Development Projects

Let's first clarify what is meant by Software Quality. High Quality Software needs to be reliable, supportable, maintainable, scalable, portable and easily integrated with other tools. Please note that there are a number of definitions that cover Software Quality. Check this link to see a starting point to learn more.
To get to a high quality Software Product we need a Test plan (check also the posting on Quality Management from November 27, 2009). The test plan needs to cover at least

1. Test Cases for all the functionality (Use Cases) that was developed
2. Unit, Functional, Regression, Performance, Failover and Usability Testing. For some of these tests you probably use tools like LoadRunner from Hewlett-Packard to simplify the testing
3. Assign Test Cases to Testers
4. Inform Testers how to report issues?
5. Inform Testers how Software Developers follow up on reported issues and provide a status of the fix to the Testers
6. Assign Test Cases to Testers

In addition to the test plan you want to make sure that your Software Developers follow some generally accepted Software Engineering Standards (e.g. IEEE, ANSI, ISO) .

The critical question is how big is the Test Plan. Do you have 50 Test Cases or 5000 or 50000. The more test cases you have the trickier it will be to ensure the desired quality. In addition to the number of test cases it is important to consider that a fix for test case 1 might break something for test case 2. Therefore we can conclude that it is desirable to have fewer test cases.

Example:

Software Developer 1: develops code to extract data from SAP into an Excel File

Software Developer 2: develops code that sends the file from Developer 1 to another IT system

If Developer 2 writes extensive code but finds out later that Developer 1 extracted incorrect Data then his work was not used efficiently since the code needs to be changed again.

Hence the next conclusion is that the earlier you find an issue the less impact it will have on your next development steps since it can be corrected earlier. Check this link for more info (start with slide 5)

What Project Management Methodology do you use and what does the above mean for your Software Quality approach?

Traditional Project Management:

Disadvantages

• The Test Plan can be very large (e.g. several thousand test cases) since it needs to ensure that the existing functionality as well as the new functionality is working as expected. The sheer size of the test plan is usually a challenge for the Test Teams.
• Problems are found late in the process (when the development is done). To do code changes now becomes expensive.

Agile Project Management:

Advantages

• If the Quality Assurance Team Members are included in the Software Development Team from the start they will find issues earlier. 
• The test plan is smaller since it contains only test cases that can be released within a sprint (e.g. 30 days).

Conclusion: It is beneficial to use an agile Project Management Methodology for Software Development Projects since you can find issues early and so you can fix them early which means you save money.

To check the conclusion above use Agile on one your Software Development Projects and compare your Post-Go Live Issues to traditional projects. Nothing speaks louder than a KPI.

How to do a Project Review for an Agile Project

The Project Review is supposed to provide an opportunity to uncover issues and challenges that come up during the execution of a project. It doesn't matter which Project Methodology (agile or traditional) is used to determine what went well and what needs improvement to bring the Project to a successful completion.

Project sponsors are interested to get the results they signed up for and they want to get some confirmation that their Project is on the right track. They are not that much interested in the Project Methodology that is used as long as they get the results they want on time.

The best time on agile projects to perform the Project Review is between one of the earlier sprints. The reason for this is that there is more time remaining to influence the project favorably. The Project Audit will be most effective when it is conducted by an outside facilitator. This ensures confidentiality for all stakeholders. The “venting“ that might happen during the process is an important part of the overall audit.

Some differences to traditional projects are

• Every sprint should have produced shippable code. What is the business value of the shipped features vs. the costs?
• How many tests were performed for the shippable code? 
• How much technical documentation was created?
• How much End User Documentation was created?

The agile Project Review would look like this

1. Determine goals of Project Review? 
2. Research the Agile Project

        - Measure how agile teams plan their work
        - What is the organizational attitude towards Agile?
        - Measure how much work is completed in each sprint
           (Burn up chart per sprint)
        - Review the Product Backlog . How good are the functional
           and non-functional requirements documented?
        - Review Sprint Backlogs
        - Get feedback about Daily Scrum Meetings
        - Review existing Reports (e.g. how often is the Product Backlog
          Burndown Chart updated)
        - Review available documentation from previous Sprint Retrospective
           meetings
        - Conduct Interviews with all stakeholders (e.g. SCRUM
           Master, Product Owner, Team)

   3.   Prepare Project Review Report

         - Identify issues and challenges
         - Identify lessons learned
         - Prepare recommendations to address issues, challenges
            and concerns
         - Present report to Agile Team

Here is a link that has some more info on agile metrics

How to inform Project Sponsors about the status of a Project?

As mentioned in a number of previous posts, communication is the key to a successful project. The objective is to share the right message with the right people in a timely manner. The messages (e.g. reports) that you can share depend on the Project Management Methodolgy that is used.

Agile Project Management (e.g. SCRUM)

• Product Backlog at the start of the previous Sprint
• Product Backlog at the start of the new Sprint
• Changes Report (Shows what has changed between the 2 reports above)
• Product Backlog Burndown Report (measures amount of remaining backlog work

Note: In addition to the formal (written/static) reports above there is also a more dynamic way to provide information

• The daily scrum which is open to everyone and provides daily up-to-date information. (e.g. face-to-face)
• The Sprint Review meeting provides monthly information into whether the project is creating valuable functionality.

Agile Project Management is all about sharing information early and often. More information can be found here.

Waterfall Project Management
You should have a regular report with a standard format. This format should be consistent throughout the project. The wording in this report has to be short, precise and easy to understand by someone who is NOT intimately familiar with the project. Refrain from putting in Team specific vocabulary (e.g. IT, Sales etc.).
Here are the proposed sections for this report:

• Start with a short Project Description: This should be a 2-3 sentence summary of what this project is about.
• Project Info:  should show Project Name + Project Manager Name
• Project Status: this should provide a short status overview of the triple constraint items (Scope, Cost, Time) and Quality. In order to communicate the information clear and quick you might want to use a color code (Green = ok, Yellow = some issues, Red = serious issues)
• Milestone Information: This shows the major milestones for this project and if they are on track with a short Milestone Status (e.g. Done, Work in Progress)
• Key Issues: Shows where and from whom you need help to address an issue with a short Issue Status (e.g. need xyz in order to close abc) and a due date
• Accomplishments: Give credit to the team! This is the place to promote what the team did.
• Next Steps/Priorities: Shows what needs to happen next.

This kind of report is sent to the project stakeholders on a regular basis (e.g. weekly, bi-weekly, monthly). You might want to add information that shows how the different items have developed compared to a previous report.

To ensure you get the right message to the right people in a timely manner check with the project stakeholders

1. How do they prefer to get notified? Is an update via email ok? Is a face-to-face meeting prefered? If you need a meeting, who should be in the meeting etc.
2. How often do they want to get notified? daily/weekly/bi-weekly/monthly etc
3. What format do they prefer? e.g. PowerPoint, .pdf file etc.

If you follow these simple instructions you will be more successful in communicating with all your project stakeholder.