Offering regional and national programs, CIO (and CSO) events bring together some of the most respected names and thought leaders in information technology and security. Presented by CIOs and other senior level executives, these invitation-only programs offer timely topics and strong networking. Learn More »
Webcast: In the Google Apps Cloud: How to Achieve Your Business Objectives
Dec 3rd, '09, 1 - 2 pm US/Eastern (GMT-5)
Join Council member Brent Hoag, Director, Global IT, at JohnsonDiversey, as he discusses the adoption of Google Apps which has helped meet four corporate goals; sustainability, simplification, increased employee productivity and global collaboration.
Webcast: Collaboration Initiatives: Benchmarks & Best Practices
Dec 15th, '09, 4 - 5 pm US/Eastern (GMT-5)
Join Council members Ruth Thorpe, VP & CIO at the U.S. Pharmaceutical Operations of Sanofi-Aventis, and Gary Kuyper, CIO at Bethany Christian Services, as they speak about their collaboration initiatives and experiences in how and why they chose the social networking and collaboration tools they are using and their business goals for collaboration, and facing culture change challenges.
Data Overview: Collaboration Initiatives Field Guide: Benchmarks & Best Practices
This appendix to the Council Field Guide provides an analysis which discusses benchmarks for collaboration IT implementation costs, adoption rates and payoffs. The overview identifies top IT and business goals and satisfaction rates for collaboration initiatives as well as best practices and lessons learned for implementing collaboration IT.
Learn more about the CIO Executive Council »January 23, 2008 — CIO —
Traditional software development happens sequentially with clearly defined stages and phases. Sequential development is popular because it is easy to follow from a team member perspective. Team members follow exact steps for every project and quickly learn the process.
In an Agile process activities are frequently concurrent and often repeated. Team members focus on providing value and using the process and steps that best support the project. Applying Agile processes and techniques is not intuitive for team members with a background in sequential software development.
To address this issue I will present the Agile concepts from a sequential phase perspective. If you are familiar with traditional software development you will find the phase descriptions intuitive.
Before we continue, let me expand on what I mean by a generic Agile development process. Scrum and Extreme Programming (XP) are popular packaged Agile methods. These packaged methods come with several Agile practices and a suggested process for using them. Our generic life cycle will be different in that it will allow a development team to pick and choose the Agile practices that work best in their environment.
XP and Scrum are superb Agile packages with strong followings and demonstrated success. Many companies have deployed these packages successfully. An issue with selecting a package, however, is some practices may provide minimal value in your environment or be difficult to implement on day one.
Consider the XP practice of Test Driven Development (TDD). This is an excellent practice that provides benefits such as minimizing the time needed to trace down bugs and quicker deployment of code. No one can deny the value of these benefits. What can be challenged is the complexity of implementing a TDD process.
A TDD process requires a disciplined development team and a mindset change. The development team needs to grasp the value of TDD and support it on a daily basis. This is a stretch for a team that is just learning the value of Agile principles. From my perspective you would not want to attempt to use TDD during your initial migration to Agile. TDD could be revisited once the Agile culture has begun to take hold and the team owns the new process. For reasons such as these, you will select the Agile practices that work best in your environment.
Related, an important aspect of our process is the menu system. We will outline a core flow that all projects should go through, but the required path will represent the least common denominator. It will be low on formality and best used on projects that need to be completed in a few days. The menu will provide options that the team can select as needed, or as the project requires more structure. To see an example, let’s look at the menu that Acme Media will use in table 1.
A key to being Agile is using the practices that best support a given project. In this example from Acme Media, the team should perform the tasks first list for every project. The steps in the second list are optional.
| Required of All Projects |
|---|
| Project worksheet (charter) |
| Operational worksheet |
| Feature card/User Story exercise (cards optional) |
| Optional Processes and Documentation |
|---|
| Elevator Statement |
| Document answers to Feasibility Discussion Guide questions |
| Cost/benefit analysis |
| Feature card documented. |
| User scenarios |
| Use cases |
| Prototypes and/or mockups |
| Stand Up Meetings |
| Iteration plan |
| Maintenance plan |
| Additional documentation as required by the team/project. |
| Pair Programming |
| Detailed schedule |
| Launch Plan |
| Information Radiator |
| Demonstrations |
| Action items from project retrospective |
Figure 1 illustrates the Agile phases and their relationship to each other.
The 5 phases we will discuss are feasibility, planning, development, adapting, and deployment:
The feasibility phase is used to determine if an idea has enough merit to proceed to planning. An individual or small group will scrutinize the idea for customer value, company value, and risk.
If an idea is viable it will proceed to planning. The project team will be assembled at this time and the team will work together to identify features. Features will be examined for value and risk and eventually estimated so they can be assigned to an iteration plan.
Development iterations convert the iteration plan into working code. Features are built, tested, and demonstrated to the customer and stakeholders at the end of each iteration.
The team adapts between development iterations. Customer feedback is used to adjust the plan for the forthcoming iteration. The team also uses this window to evaluate their velocity (pace) and they adjust iteration capacity accordingly.
Now let’s examine the feasibility phase in detail.