Implementing Agile – Part 1

Implementing Agile can be challenging but rewarding

Implementing Agile can be very challenging for many organizations (especially in Waterfall development cultures), but at the same time, it can be rewarding. This article covers a short history of Agile methodology, which became mainstream this decade to rev up software development with a faster approach. It defines Agile, its benefits, and covers techniques for using Microsoft Project for your Agile projects. Read on if you’ve ever wanted to make your transition to Agile easier.

A Short History of Agile

In 2001, new methodology pioneers met in Snowbird, Utah to share their experiences and to suggest ideas for improving the world of software development. They came up with the Agile Manifesto to streamline the development process. According to the Agile Manifesto (2001) :

  1. Individuals and Interactions were more important than the process and tools.
  2. Working software was more important than a lot of documentation.
  3. Customer collaboration was more important than contract negotiation.
  4. Responding to change was more important than following the plan.

The pioneers also came up with a set of Agile principles, which were broken into four major groups: customer satisfaction, quality, teamwork, and project management. For years, most organizations were very slow in trying the Agile approach, but in the past ten years, they began to have an Agile attitude and its usage has grown exponentially. Why do you think that is? User satisfaction! According to a Standish Group Study in 2015, it was found that 29% of traditional projects failed outright and were canceled, but that number decreased to 9% for Agile projects. I believe this is a direct result of Agile teams making immediate adaptations on frequent inspections of progress. Also, 60% of completed traditional projects were challenged because they had gaps between expected costs and actual costs, time, and/or quality.

Agile Project Management

Agile Project Management (APM) is a style of project management that focuses on early delivery of business value, continuous improvement of the project’s product and processes, scope flexibility, team input, and delivering well-tested products that reflect customer needs. APM is a lightweight model that uses informal communication style, is fewer document oriented, and uses less rules and practices. In contrast to a heavyweight methodology like the traditional life cycle Waterfall model that describes the various phases in a cascading serial fashion, APM is now becoming a common product development practice that involves building a product with the least amount of features needed (between 1-5) to get feedback for future development. The Agile method easily becomes your blueprint for starting the development process!

Agile approaches are a response for the need to modernize project management for small-scale projects where clients have difficulty defining the requirements. The bottom line is that it revs up your software development (i.e., proto-typing) with a faster delivery time and more flexible approach. APM is a great software development approach for software development houses like Microsoft, Google, Oracle, SAP, and web-design organizations. There is no question that APM will increase software development project successes, reduce defects/failures, and increase user satisfaction. According to a recent survey from PMI, 80 % of companies use Agile at least some of the time and 40% said they use it either often or always. Most of the organizations that are using Agile are at a “still maturing” level regarding Agile practices.

APM increases collaboration/ownership between the scrum master, product owner, and development team because they are working closely together on a daily basis. See the figure below for all the Agile roles. The Project Team consists of stakeholders/users that have an interest in the project and provide input. The Scrum Team consists of the product owner and the scrum master. The product owner is a subject matter expert (SME) that knows the business, and customers, and sets the product’s vision and priorities (i.e., roadmap and release plan). This prioritized wish list is called a product backlog. The scrum master is a servant leader or project facilitator who coaches (i.e., provides expertise on Agile processes) the Development Team and protects the team from organizational distractions. Also, this person facilitates consensus-building and stakeholder communications.

The Development Team is a hands-on technical group (e.g., programmers, testers, designers, and data engineers) that produces the overall product by pulling a small block from the top of the wish list, a sprint backlog which is derived from the product backlog, and decides how to implement these pieces. The development team usually spends 2 – 4 weeks, a sprint, to complete its work, but meets daily to access their progress (called a 15-minute standup scrum). The real beauty of these short cycles is that the customer gets to see their product as a work-in-process. Scrum is an iterative approach that came from the football game of rugby where a team works closely together on a series of sprints leading to a release of a product or some functionality and takes responsibility for the results. When the next sprint begins, the team chooses another piece of the product backlog and begins the iterative cycle again.

Agile Roles
Figure 1.1: Agile Roles


Waterfall Model Versus Agile

Agile can lead to higher product quality, increased productivity, customer approval, and team morale. Quality can affect risks because quality management on Agile projects basically reduces risks. Risks usually increase over time using the traditional Waterfall model, but that ratio is the complete opposite when using the Agile. Why? Because short durations or sprints (usually 2 – 4 weeks) prove the product is working. The following figure depicts this comparison and includes the return on investment (ROI). Agile can help increase revenue opportunity sooner and can help the self-funding of future development of new product features.

Risk Comparison
Figure 1.2: Risk Comparison

Defining the right development process for your business will have a weighty impact on controlling the schedules, costs, and quality of a product. The Waterfall development model is generally suited for medium to large projects with well-defined requirements.

The Agile (or iterative) development model is typically used to develop a product that has not been fully defined. This model is initially used to develop the known requirements. As the overall requirements become better understood and the product is further defined, the next iteration (or sprint) of the product is developed. Each iteration forms the foundation for the next. The fixed and estimated attributes between Waterfall (guess driven) and Agile (priority driven) approaches are completely the opposite as shown below.

Opposite Approaches - Waterfall and Agile
Figure 1.3: Opposite Approaches – Waterfall and Agile
Opposite Levels of Resources - Waterfall and Agile
Figure 1.4: Opposite Levels of Resources – Waterfall and Agile

Also, the Waterfall and Agile lifecycles are shown below. Always remember – whatever development process you use, it must be examined routinely for improvement!

Waterfall and Agile Lifecycles
Figure 1.5: Waterfall and Agile Lifecycles

Part 2 of this article will be published soon, in which I’ll explore the history of Microsoft Project or how MSP is adapting to Agile. We will also look at implementing the Agile methodology. Stay tuned!

References :

Related Content

Microsoft Project Training

Microsoft Project Courses :

Ronald Smith has over four decades of experience as Senior PM/Program Manager. He retired from IBM having written four books and over four dozen articles (for example, PMI’s PM Network magazine and MPUG) on project management, and the systems development life cycle (SDLC). He’s been a member of PMI since 1998 and evaluates articles submitted to PMI’s Knowledge Shelf Library for potential publication. From 2011 - 2017, Ronald had been an Adjunct Professor for a Master of Science in Technology and taught PM courses at the University of Houston’s College of Technology. Teaching from his own book, Project Management Tools and Techniques – A Practical Guide, Ronald offers a perspective on project management that reflects his many years of experience. Lastly in the Houston area, he has started up two Toastmasters clubs and does voluntary work at various food banks.
Share This Post
Have your say!

Leave a Reply