2-3 Final Project Milestone One: Scenario Selection – Information Paper

Agile

In 2001, there were several methodologies in use that were considered agile. These methods were evolving, combining, and testing new procedures for software development projects. Traditional project management (TPM) methods and techniques reflecting the waterfall model were seen as inappropriate for the needs of software development. Agile methods were proving to be more effective in capturing changing requirements and quickly shifting to deliver a timely, functional product that provided value to the customer.

On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground . . . What emerged was the Agile Software Development Manifesto. Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened. (Highsmith, 2001).

The key elements of this manifesto are stated as follows:

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more. (Beck et al., 2001)

For TPM projects, the expectation is to have well-defined, unchanging requirements. However, Agile Project Management (APM) was designed to expect and welcome change. TPM works well for projects in which both the solution and the goal are clear. If the solution is not clear, then APM is the more appropriate approach (Wysocki, 2010).

Agile presumes that significant unknowns are intrinsic—the key knowledge is generated by development and feedback—and therefore uses multiple short feedback loops with continuous communications and just-in-time planning.

In Agile, there is a self-organizing team that owns the task and the project outcome. There is frequent stakeholder collaboration, continuous knowledge sharing, and a specific product owner.

Scrum

One type of methodology is Scrum. Scrum focuses on short iterations called sprints. These sprints are typically time-blocks of two to four weeks. A sprint is a concerted effort by the team to deliver a product to the customer. There are periodic Scrum sessions or meetings (usually daily) where the project deliverables are broken down into intervals and product increments.

In Scrum, there is no title of project manager. Instead there is a Scrum Master. The Scrum Master facilitates the daily project communications and solves problems that interfere with team’s ability to do work on the project. The key roles in Scrum are product owner, team, and Scrum Master.

Triple Constraint in Project Management

There is a project management saying: “Do you want it fast, cheap, or good? Pick two!” This adage illustrates a fundamental in project management called the triple constraint (time, cost, and scope). A PM must manage customer expectations and design projects to make the best use of time, money, and scope to achieve delivery of the product. This relationship with time, cost, and scope drives the identification and planning for risk management in TPM (Turla, 2015).

In TPM, the scope is constrained. The requirements are fully defined at the start. The project is designed to deliver the full product as documented in the requirements and described in the scope. Risks must be identified and managed; change must be minimized. The schedule and cost must shift in order to deliver the product as described in the documentation (Wysocki, 2014).

In Agile, the requirements are not fully defined at the start. The cost and schedule are constrained. Within each of the iterations, there is feedback from the product owner in which a determination is made: what can be delivered in that iteration based on the time-block schedule and the cost. With multiple short iterations, the process adapts to change. The result is minimized risk, and delivery of the project within cost and schedule based on the value determined and prioritized by the product owner (Sylvester, 2013).

References

Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., . . . Thomas, D. (2001). Manifesto for Agile Software Development. Retrieved from http://agilemanifesto.org

Highsmith, J. (2001). History: The agile manifesto. Retrieved from <http://agilemanifesto.org

Sylvester, T. (2013). Waterfall, agile and the triple constraint. Retrieved from http://agilemanifesto.org/history.html

Turla, P. (2015). Project management: When they want it fast, good, and cheap. Time Management Made Easy. Retrieved from http://tom-sylvester.com/leanagile/waterfall-agile-the-triple-constraint/

Wysocki, R. K. (2010). Adaptive project framework: managing complexity in the face of uncertainty. Boston, MA: Pearson.

Wysocki, R. K. (2014). Effective project management: traditional, agile, extreme (7th ed.). Boston, MA: Wiley.