Quay Consulting’s Senior Consultant Matthew Sharpe explores the origins of Agile in the project management space – both the ‘how’ and the ‘why’.
Agile has been a buzzword for some time now, and no doubt many if not most of us working in the industry have come across it in some form in recent years. But is it really all it is cracked up to be? Is it the magical silver bullet that will solve all the issues facing IT and software development, or is it just another fad?
Over the course of the coming months we will explore some of these concepts, but before doing so, it is important to go back to the origins of the Agile movement and why it evolved. Even those of us who may have worked in Agile environments for many years often get so caught up in the ‘how’ and lose sight of the ‘why’, and in so doing face the risk of losing sight of the benefits.
From Waterfall to Agile
From its beginnings in the 1940s, Software development has evolved a set of principles and best practices which have dictated the most effective ways to create, maintain and release quality code.
One of the core practices that developed out of this was an ever-tighter set of project management methodologies, reaching a peak in the 1980s and 90s with the codification of a PMBOK and related methodologies including PRINCE/PRINCE2 and others.
Whilst these ‘waterfall’ or ‘heavyweight’ approaches undoubtedly had many benefits, there was a group of industry thought-leaders around this time who criticized these methods as slow, bureaucratic and overly regimented and not ideally suited to an industry that was increasingly subject to change.
There was recognition that far from improving efficiency, these heavy-handed methods more often than not set up projects that failed, and it became apparent that whilst these may have their place in some environments, when it came to software development there had to be a better way. And so, over time a new set of principles emerged that in an almost dialectical approach to the ‘locked-down waterfall’ school of thought, embraced change. A set of principles that not only anticipated change, but in fact fostered it and leveraged it in a manner that would result in a more effective and successful delivery strategy.
The Start of the Agile Revolution: The Manifesto for Agile Software Development
Initially the approaches varied and included a number of ‘change’ methods including Scrum, XP, DSDM, Crystal, and others. But it didn’t enter the mainstream until seventeen representatives from these approaches got together at the Snowbird Ski Resort in Utah in February 2001 to form the Agile Alliance, find common ground and famously draw up what became the Manifesto for Agile Software Development. It was an inauspicious start to a revolution that would sweep the software development world.
So what was it about the Manifesto that made it so appealing? Why does this movement continue to grow and evolve where other methodologies have come and gone? To answer these questions, the key thing to understand is that ‘Agile’ development is not a prescriptive methodology in the same way that Prince2 is for example.
The Agile Manifesto was written to express a set of shared values or principles of people who saw a new, better way of developing software. These values developed from a set of thought-leaders who between them had many decades of experience and together reached the same set of common-sense conclusions.
Another key thing to understand is that these principles do not reject earlier paradigms, and the Agile Manifesto is written in such a way that acknowledges this by expressing that value “x” is preferable to value “y”, but that “y” still existed and in some scenarios is still useful.
The Left and the Right: The Continuum Between Extremes
In understanding the context of the Manifesto therefore, we understand that, irrespective of the methods we use or the artefacts we create as an Agile practitioner, we value the statements on the left more than the statements on the right, but acknowledge that hey, life is complex, every project is different and we sit on a continuum between the two extremes. For those of you unfamiliar with the manifesto, and as a reminder for those of us who are, the values are as follows:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
As we each go back to work in our own environments, whether it be a mature Agile house, a company already on the journey or one where projects are still firmly rooted in the ‘right-hand-side’ of the above values we believe it is always useful to take a step back and consider where you sit on that continuum, and what you can do today to re-align your values more closely to those on the left.
As part of this series we will begin to examine the realities of this approach in more detail, and start to revisit the question – is Agile all it’s cracked up to be, or is it just another fad?
The Terminology of Agile
For many people starting out and not familiar with the terminology, it can seem like learning a whole new language – with many terms that can seem interchangeable or unclear.
Before making the decision on whether or not to jump onto the Agile bandwagon, it is worthwhile to familiarize yourself with some of these terms. We hope with a basic level of understanding of the why and the what, the conversations around the how can gain an entire new contextual framework. So without further ado, here are some must-know terms:
Agile: An umbrella term that comprises a set of values for a family of project delivery frameworks that promotes iterative, incremental development (as opposed to Waterfall development).
Scrum: The most popular and widely-used Agile framework, usually characterized by a set of roles, time boxed ceremonies and artefacts, some of which include:
ScrumMaster: The facilitator for the product development team whose main roles are to remove impediments and ensure adherence to the methodology to allow the team to incrementally deliver value.
Product Owner: The person responsible for the success of the product/project who conveys a vision, sets priorities and sets work through the creation and grooming of the Product Backlog (a dynamic list of requirements).
User Stories: A method of writing requirements stated as a sentence expressed from the ‘user’ perspective, usually with a desired action and outcome.
Story Points: An (optional) method to measure relative effort of a user story – instead of measuring effort in blocks of time this is a way of showing the relative size of a story when measured against another story. This concept is sometimes difficult to grasp initially, so we may cover this in detail in a future post.
Sprint: A set period of time (usually 2 weeks) during which time an agreed set of user stories are ‘done’ – also called iterations.
Standup: A daily time-boxed meeting (usually 10-15 minutes) where the whole team gets together and answers three questions each – what did I do yesterday; what am I doing today; are there any blockers?
Burndown: A visual method that shows teams progress of how many story points have been ‘burned through’ during a Sprint or iteration expressed in a chart. Can also be expressed as a burnup.
Kanban: Another Agile framework that leverages the ‘just-in-time’ principle by limiting work in progress and focussing on value flowing through the development pipeline and revealing and removing impediments to that flow.
Scrum-ban: Yes, this is a thing. As you would guess, this is an emerging Agile framework that combines aspects of both Scrum and Kanban and offers a flexible alternative for organisations that blend product development and support activities.
XP: Not the Windows Operating System, but this is an acronym for Extreme Programming – another Agile framework, often used in concert with other approaches that advocates frequent or continuous releases in short development cycles.
Lean: Whilst not strictly an Agile framework, this is related in it is a practice that seeks to maximize customer value whilst continually seeking to eliminate waste. In essence to do more with less.
There are of course other terms that you may hear as you go about your Agile journey such as Epics, Features, Retrospectives, Test-Driven-Development, Spikes and many more but we don’t want to go too far down the rabbit hole at this stage. There are many sites, such as agiledictionary.com which are great resources to explore further.
Having an understanding of the above however should help inform the next decision you need to make and one which we will cover in the next bulletin – is it worthwhile that you pursue an Agile qualification?
Mathew Sharpe is a Senior Consultant for Quay Consulting, working primarily in the Agile space. This article was originally published on his blog, DigitalTaskForce in January 2016.
We believe that quality thought leadership is worth sharing and encourage you to share with your colleagues. If you’re interested in republishing our content, here’s what’s okay and what’s not okay.
To speak to our team about how we can help your business deliver better projects, please contact us.