Let the Dogs Make Their Own Food:

Agile and Iterative Approaches in Technology

Deployment, Use and Management.

In 1994 the Standish Group shocked the IT community with the publication of the CHAOS report;

'a staggering 31.1% of projects will be canceled before they ever get completed'

and

'only 16.2% of software projects.. ...are completed on-time and on-budget.'

For those initiatives that do make it into production, 52.7% will cost 189% of their original estimates. Other studies report similar dysfunction for ERP projects.

Reasons often cited for failure focus on poor design/planning during initial project phases, and an inability to control development.

- Standish Group

In the 1994 report the success rate was 16.2 percent, while the 2006 Standish Group report revealed that 35 percent of software projects started in 2006 can be categorized as successful, meaning they were completed on time, on budget and met user requirements.

- Standish Group

Three reason cited for the improvement,better project management, iterative development and the emerging Web infrastructure.

- Standish Group

So, why iterative development in project management?

“Managers have a better understanding of the dynamics of a project. Iterative development,” Johnson (from Standish Group) said, “makes it easier for people to get what they want. Part of the education process is that people are better able to articulate what they want out of a project.”

- Standish Group

Agile Project Management allows existing business processes to be modified and new business processes to be developed at the same pace as the same pace as the user can articulate themuser can articulate them.

Jim HighsmithAgile Project Management

Agile Project Management (APM) is a stark departure from traditional front-loaded project management processes, where success often hinges on the ability to identify all of the system's needs before development begins. The fundamental difference between front-loaded and lightweight approaches used in APM boils down to planning vs. practice.

Front-loaded project management (such as Prince2, PMI’s PMBOK, or processes based on the Software Engineering Institutes's Capability Maturity Model) starts out with a heavy investment in 'planning.' Needs analysis, requirements gathering, gap analysis, resourcing, etc. all take place before development begins and are expected to remain consistent: an “engineering process.”

Planning is emphasized to mitigate risk and the key to successful technology development. Rigid procedures are needed to regulate change...•Hierarchical organizational structures are means of establishing order•Increased control results in increased order•Organizations/processes must be rigid and static hierarchies•Employees are interchangeable “parts” in the organizational “machine”•Problems are solved primarily through reductionist task breakdown and allocation•Projects and risks are adequately predictable to be managed through complex up-front planning

Changes are discouraged and may result in financial penalties.

Success in front-loaded projects is often defined by how well a project adheres to the plan, not on the quality of the work or the value of the finished project.

In contrast…

Lightweight approaches, such as APM, do not attempt to plan for the entire project, but rather provide practices for undertaking tasks as they are identified.

APM addresses needs for which there is evidence for implementation, rather than perceived or anticipated need.

Light-weight approaches accept that change will occur based on new information, technologies, etc.

This is why lightweight management practices are sometimes called evidence or event-based processes.

APM practitioners argue that there are no new projects. Rather new systems or services are simply extensions of the organization's current scope of services.

Small iterations, executed as the environment demands, results in a broader set of services/systems and greater usability among the campus community.

Risk is lessened by building upon existing systems that extend current features and functionality.

Feedback from users add functionality through time. The issues raised are based on real-world use of existing systems. Once the web page is up, users recognize the need for a uniform look and feel. Once more people are online, users need more than just content, they expect interactivity (forms). As more content and functionality comes online, users need content management Administrative content leads to academic content management, and so on. Each enhancement is only an incremental advancement in functionality and technology. The majority of staff, skills and infrastructure needed for the enhancement are already in place supporting the existing service/system.

Initiatives may not be rooted in existing services. Therefore their development may require staff, skills, or infrastructure not currently available within the IT department. This is a huge risk as there is no one who can accurately assess the departments ability at successfully implement the initiative. Interestingly, because the staff will need to learn and implement many of the critical technologies required to implement the initiative, time frames and total costs will be same as in the evolutionary approach. Again, however, because development will focus on discovery rather than application, it can be presumed that costs, time and overall, risk, will increase beyond the comfortability of senior management, end-users and your own department.

Principles

•Collaboration/Transparency•Emergent Design/Evidence-Based Decision Making•Project Management & Product Management•Incremental & Iterative Development•Operational Budgeting vs. Long-Term Budgeting

Tactics & Tools

•Collaboration/Transparency – Open Documentation (Confluence)– Scope of Services (Operational Budget)– Organization & Audience Analysis (Templates)

•Emergent Design/Evidence-Based Decision Making

– Help Desk (JIRA)– Performance Metrics (Systems Monitoring)– Service Agreements

Tactics & Tools

•Project Management & Product Management– Discussion/Work Groups (Confluence)

*** NOT COMMITTEES ***– Roles, Responsibilities and Accountability

(Scope of Services & Operational budget)•Incremental & Iterative Development

– Readiness and Prioritization (Rubric) – Project Goals (Use Cases & Story Telling)– 3-6 Month Cycles (Decision Gates)–

Who is using APM?

SunGardReference No.: 2007/05/16/PB

Opening Date: May 16, 2007Job Title: Senior Development Project ManagerHow to Apply: Per Brandt

Responsibilities:The group also manages the resource planning and are currently implementing a new agile process for managing development projects.

Requirements:Experience from some agile process like Scrum is a plus

Who is using APM?

• Automotive & Aerospace

• Construction

• Medical/Pharmaceutical

• Software Development

References• Agile Alliance (http://www.agilealliance.org/)

• Agile Project Leadership Network (http://apln.org/)

• UCLA (http://www.aitb.ucla.edu/research_areas/Increase_Product.htm)

• Queens University (http://www.its.queensu.ca/uis/resources.shtml)

Thank You.