By
With the popularity created by the Agile movement it is important that we as a community take a moment to get clear on a few things. First, Agile is not a methodology of any sort. It is a movement that consists of a 73-word manifesto and 12 principles. The manifesto and its principles as written were intended for the optimization of software development Projects. That said, the spirit of both the manifesto and principles can be applied more broadly and can be incredibly valuable to the success of Enterprise-Wide Projects.
Waterfall and the Critical Path Method
The Waterfall concept was created by a computer scientist named Winston Royce in the 1970’s when he wrote a paper called “Managing the Development of Large Software Systems.” The approach was to optimize the development of Software Systems given the technology that was available at the time. In a nutshell, the article outlined how software development should be completed in phases and that no work in a subsequent phase could be completed until the work in the current phase was done. Essentially, the project work would all be organized into a single linear work stream.
At no time was the Waterfall methodology adopted by the Enterprise Project Management community as it would be the least efficient way to complete a large-scale Project with multiple matrix, single disciplined teams, and external vendors.
The Critical Path Method was developed in the late 1950s by Morgan R. Walker of DuPont and James E. Kelley, Jr. of Remington Rand. Traditionally, the critical path method has been used on Enterprise Projects. The concept of critical path assumes that there are multiple work streams executing in parallel on every project. And that given the cost and schedule constraints of most organizations, the schedule of each of those work streams has been compressed or “crashed” to ensure that cost and schedule are optimized.
When people talk about Agile or Waterfall they are talking about software development frameworks, not step by step methodologies; and neither of these frameworks has anything to do with traditional Project Management, Enterprise Project Management, or the critical path method.
Scrum and Enterprise Project Management
Scrum is a software development methodology that has many well documented step-by-step best practices that can truly optimize an organization’s ability to deliver working software frequently.
Scrum best practices create velocity by requiring a dedicated cross-functional team that defines tasks no longer than 1-day in duration and meets daily to assess progress. With a dedicated team and work broken down into single day increments, it becomes very easy to see where changes can be made to increase the productivity of the team.
Enterprise Project Management works with multiple matrix or “non-dedicated” teams, breaks tasks down into a maximum of 12-hour increments and uses the critical path to forecast the impact of progress, lack of progress and Impediments. This approach to Enterprise Projects allows the Project Team to make daily decisions to achieve the realization of the Project Goal and Objectives, and ensure the closest possible delivery to the planned end date and cost.
In my humble opinion, Scrum is the most efficient way to develop working software. A development organization optimized with Scrum best practices is not leaving any time or money on the table. The only downside to Scrum is that it doesn’t address a company’s need to allocate funds and team members from Projects with surplus to Projects in need in a Program or Portfolio. Also, it doesn’t support the cross-organizational dependencies of matrix team members on Enterprise Projects.
**Note: This is not a criticism of Scrum. The Scrum Alliance acknowledges that there are activities necessary to support a Project that are “outside of Scrum.”
With that said… 120VC recognizes that Scrum is the hands-down winner when it comes to software development and that the Agile principles are ideal for any Project Management Standard. The 120VC Project Management Standard incorporates the Agile Principles in the context of an Enterprise Project. Combining traditional Enterprise Project Management techniques, Agile Principals and Scrum best practices has enabled 120VC to develop the first how-to Standard for a Scaled Agile Framework.
Our Scaled Agile Framework allows 120VC and our clients to:
- Take advantage of the efficiency and speed of change enabled by Scrum best practices.
- Overcome Scrums intentional lack of support for Program & Portfolio needs.
- Allow Scrum outputs to be used to manage cross-organizational dependencies efficiently, and…
- To allow for the allocation of funds and team members from Projects with surplus to those in need.
Wisdom Comes with Experience…
Agile and more specifically Scrum creates a time to market advantage, but that advantage comes at a cost. It is true that Scrum optimizes the utilization of team member time and expenses to create valuable results quickly. But more results, product, and working software cost more money, period! Before deciding to adopt an Agile or Scrum culture ask your team the following question: “How much change do we really need to introduce each year.” More change equals higher cost.
If you need to introduce change at a Google or Amazon pace to be competitive, then Scrum is the way to go. However, if you are looking at Scrum because the changes your team produces today are too slow, or simply don’t happen when or for the amount you were promised, the improvements you seek may be as simple as optimizing your current culture.
Making the decision to adopt an agile (high rate of change culture) because your team doesn’t handle their current projects efficiently would be like asking Kindergartners to learn how to fly a jumbo jet before they can move on to first grade.
Agile and Scrum are very effective at their intended purpose and not the solution to every problem. Before making the decision to completely overhaul your culture and become more agile, take a calm pragmatic look at what you really want to accomplish. Then, evaluate Scrum to ensure it is the right fit. One last thing to consider… If you ask a sales person that is selling Agile or Scrum if it is the right fit, what do you think their answer is going to be?
