Can Agile and Traditional (Predictive) Software Development Co-Exist?
Beginning with this post, we will be posing a series of discussions on this question: Is Agile (Agile/Scrum) able to either peacefully co-exist with traditional (predictive) software development, or is the former on track to totally replace the latter? These blog posts are based on a whitepaper that I published in 2010 on this topic of the ability of Agile to co-exist with traditional software development.
For those not completely aware of the birth of the Agile software development philosophy, a bit of non-Agilist history is in order. I use the term ‘Agilism’ to indicate the form of the software development practices that conform to the purest definition of the Agile values and principles. So let us start our journey towards trying to answer the question above that has many in the software development field still in arguments and debates.
First, let us lay some ground work so we are all on the same page about just ‘What is Agile?’
The answer can be found initially in the Agile Manifesto of 2001. Well, let the Agile Alliance state this in their own words:
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, and of course, to eat. 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.
This manifesto espouses the guiding values and principles of the Agile philosophy:
Agile is guided by four values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
And supplemented by 12 principles:
- Customer satisfaction by rapid delivery of useful software
- Welcome changing requirements, even late in development
- Working software is delivered frequently (weeks rather than months)
- Working software is the principal measure of progress
- Sustainable development, able to maintain a constant pace
- Close, daily cooperation between businesspeople and developers
- Face-to-face conversation is the best form of communication (co-location)
- Projects are built around motivated individuals, who should be trusted
- Continuous attention to technical excellence and good design
- Simplicity
- Self-organizing teams
- Regular adaptation to changing circumstances
By 2001, there were already many Rapid Application Development (RAD) methodologies in existence ; what was lacking, it appeared, was a concise statement of value and focus. The Agile Manifesto provided this for the above listed RAD methodologies whose representative practitioners became signatories to the Manifesto:
- Kent Beck: Creator of eXtreme Programming (XP)
- Jeff Sutherland, PhD: creator of Scrum
- Scott Ambler: Creator of RUP, AUP, and EUP
- Alistair Cockburn: Creator of Crystal
- Jim Highsmith: Prime mover behind APM (Agile Project Management)
The current literature on Agile methods have two consistent themes involving the use of Agile methodologies and the best way to ensure their benefits to the organizations using Agile methods:
- Agile is best used in developing software for computers, and
- The team size and co-location of the project/product owner and team are crucial
The frustration of the Agile signatories were evident in the manner in which the Agile Manifesto swung the philosophy pendulum in completely the other direction. If you read the guiding values and principles closely, they repudiate almost word for word the manner in which IT project management and software product development had been attempted to the point of the manifesto signing.
No requirements gathering? No documentation? No contracts? No infinitely detailed deliverables scope? The Agile manifesto was a cannon shot across the bow of the current best practices practitioners reminiscent of the scream from the movie “Network”
“I’m as mad as hell, and I am not going to take this anymore…”
However, did the Agile signatories really think this through before embarking on such a radical change, or was it the radical nature of the manifesto the end in itself? Figuring an answer to that would take some time and hard evidence of purpose and intent, but the results seem to bear out the affirmative. The methodologies that stream from the point of agreement brought on by the Agile manifesto have yet to stop ringing in the halls of traditional project management.
The point from here on is:
Can Agile peacefully co-exist with project management current best practices?
This answer is so important for many project management practitioners and PM-contract firms since the choices made will determine the capabilities to achieve successes on the projects under assignment. If Agile can be applied to all forms of project management, what does this mean for the project management current best practices model? If Agile is applicable to only a small sub-section of project or product development solutions, what are the questions a project manager or firm needs to ask in order to determine if and where these seemingly orthogonal philosophies can be applied according to their success potentials?
Stay tuned for Paul’s next blog installment on Agile project management and don’t miss his presentation at ACQUIRE on June 9, 2016 at 12:15 p.m. in the IT Pavilion.
