It seems to me that over the years, organisations have responded to both the increasing complexity of projects and their dismal success rate by heaping on:
- more processes and tools,
- loads of documentation,
- tighter and tighter contracts, and
- detailed plans from start to end...
...in short, everything on the right-hand side of the Agile Manifesto. To me, Agile is a movement aimed at refocusing our profession back on the fundamentals of effective software development. Back to the future perhaps.
In the first 'official' book specifically on Scrum - Agile Software Development with Scrum - Mike Beedle writes:
"The Scrum practices are hidden but simple universal patterns that have been forgotten by most of us."
Beedle goes on to suggest that if we start a small project with a customer and development team in a room without dictating or suggesting a particular way of working, we will generally converge on an approach that closely resembles the core Scrum model. How would you expect the group to work in such a scenario? How similar is it to the following (based on Beedle's outline)?
- We talk to the customer, find out what they want and what is most important. Together we create a prioritised list of requirements = Product Backlog in Scrum.
- Before starting work, we review the highest priorities and plan the short term in detail = Sprint Planning in Scrum.
- As we develop the software, we learn more about what we have to do and refine our "to do" list = Sprint Backlog in Scrum.
- To see where everyone is and co-ordinate efforts, we have informal meetings to tell each other what we are working on, what issues we have and what we will be working on next = Daily Scrums in Scrum.
- As we implement features we show the customer how it looks = Scrum Review in Scrum.
- At regular intervals we pause and reflect on how we are doing and how we can do better = Sprint Retrospectives in Scrum.
To me, this is the distilled essence of any good software development approach. That's what Scrum is - an intentionally minimalist distillation of what works. Codified common sense. Of course, there's a lot more to most projects than this which is where we need to draw on an array of effective techniques that compliment the core Scrum model from planning poker to big visible charts.
Scrum is not rocket science, it is common sense. Unfortunately, implementing common sense in a world of complex requirements, complex technology and most of all complex people (individually and in terms of their interactions) isn't always easy. These are the challenges that I'm interested in as an Agile Coach.