Author: Deena Chadwick

I have heard many times that the Agile Manifesto was created because Waterfall processes were so intricate and complex that most projects failed. This is not true! While using Waterfall as a leading methodology projects were completed, software was launched, and teams were successful.

So why is Waterfall not the popular process today? I believe there are three reasons:

1. Evolution of Information Sharing. The expansion of the information age allows for more collaboration and real-time sharing of information and updates.
2. No Tolerance Attitude. Process was so predefined that no one was allowed to veer outside of the process. Roles were defined, requirements are unchangeable, and sign off was final.
3. Lack of Good Old Fashioned Common Sense. Many developers were getting burned by the No Tolerance Attitude. They stopped using common sense to drive their actions and conversations. If a business rules document said that the name can only be four characters, then it was developed that way. When asked why the response was always “It was written in the requirements.”
   

So it was the development of Agile that introduced iterative development right? Wrong!  In the 1930s Walter Shewhart, a quality expert at Bell Labs, proposed a series of short “plan-do-study-act” (PDSA) cycles for quality improvement. The X-15 hypersonic jet in the 1950s was developed using Iterative and Incremental Development (IDD). Gerald M. Weinberg in an interview stated, “We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale, [at IBM’s Service Bureau Corporat].

So if IDD and PDSA were already known by leading experts in software and project development, then why was the Agile Manifesto written? Here is what happened, when 17 leading industry leaders gathered to discuss best practices they didn’t agree on much, but they all seemed to agree on four things. These four things were written up as a manifesto:

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

These are not written as processes, steps, rules, or any other methodology. They are principles that should drive all projects no matter the methodology.

Related Article: Agile is a Team Sport

So why do so many people call Agile a process or methodology? After the manifesto had been circulated, it was very much agreed upon by many. It also seemed to align with several processes being employed in the 1980s and 1990s. A development process created in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka was a variant of the Japanese Sashimi methods. These methods focused on speed and flexibility. Later in the 1990 Ken Swaber and Jeff Sutherland employed similar methods and referred to them by the sport they mirrored. Rugby. Scrum is a rugby term that means restart a game after a problem. Unlike Agile, Scrum is a process. It is meant to allow teams to adapt quickly to problems, interruptions, and late breaking changes.

So if your team is using Agile Scrum, this means that:

• You are thinking about common sense communication over processes.
• You strive for working software rather than over documented requirements.
• You value what your customer and users have to say rather than assume that you know more than they do
• You flexibly change and adapt as needed

So how does someone meet scope and deadlines when not one of these principles seems to align with tracking and managing projects or people?

Here is where things start to get complicated. Projects need to deliver. Deadlines must be met. People are not perfect, so they need oversight and management. Stakeholders, investors, and managers sleep better at night when they know there is a plan; each person has a clear direction, and that things are being tracked and reported on regularly. So in 2001, Ken worked with Mike Beedle to bring decision-making authority, planning and managing project into Scrum. This was defined in the book Agile Software Development with Scrum.

So now we have come full circle more than ten years later Agile Scrum.

1. Communication and Speed of Information Sharing. The expansion of the information age has provided us with amazing tools that allow instant information sharing, amazing wikis, and even collaborative documentation. However, information can only travel as fast as the person providing it. Information can only be ingested if someone is accessing it.
2. No Tolerance Attitude. Process for Agile Scrum has become so predefined that no one is allowed to veer outside of the “agile” process. Examples: No sprint can be more or less than two weeks. Fibonacci Story Points only not estimates in hours. You can’t sit down at a Scrum meeting. Once velocity is determined a Sprint must have the exact number of story points for it to be deemed complete. The list goes on and on.
3. Lack of Good Old Fashioned Common Sense.. Again common sense seems to sit in the background. Since there is a retrospective meeting, everyone waits to share their issues there instead sharing the issues when they come up. A developer could not possibly know how to develop a login screen from their vast experience and knowledge…they must wait for user stories. Don’t even think about working on something that is sitting in the backlog that has not been prioritized by a Product Owner…even if it will not affect your ability to deliver on time and not doing it will put your current tasks on hold.

At the end of the day, don’t blame your methodology for your project woes. Your team is not made up of children. They do not have to be told to open their mouths before they take a bite of food. The next retrospective where the methodology is blamed, go back to the task that failed and find out who was involved and why common sense was ignored. My team sometimes jokes about it but have a Sense of Personal Agency. A Sense of Personal Agency is the awareness that one is initiating, executing, and controlling one’s volitional actions and knowing how they affect others.  It is honestly the most important part of any Waterfall, Unified, Agile, Flexible, Adaptive, Lean, Scrum, IDD, TDD, Extreme Development or Task Oriented project.