Let’s talk agile
We seem to have a misunderstanding of agile software development. I’ve spoken with business folks, software engineers, and product owners. Many have mistaken the agile approach for working without a plan and ignoring documentation. I have a problem with this definition of agile and maybe you do too.
To understand agile software development we need to understand its initial context and the original agile manifesto. When the agile manifesto was defined, the most prevalent SDLC (Software Development Life Cycle) was the Waterfall model — this model was in fact, the earliest SDLC approach used in software development.
Wikipedia[1] defines the waterfall model as “a breakdown of development activities into linear sequential phases, meaning they are passed down onto each other, where each phase depends on the deliverables of the previous one and corresponds to a specialisation of tasks.” In certain areas of engineering this is a good approach. But in software development it is less iterative and flexible. We don’t always know every requirement before starting work on a product. In a waterfall model, if we changed the requirements mid-project, we would also need to redesign, redevelop and retest thus increasing costs and pushing out timelines.
As a result of shortcomings associated with the waterfall model, new, leaner software methodologies started to emerge. Numerous lightweight software development methods evolved such as extreme programming, unified process, dynamic systems development method, and Scrum. Even though iterative and incremental software development methods can be traced back as early as 1957, it wasn’t until 2001, when seventeen software developers published the ‘Manifesto for Agile Software Development’ [2] that the term agile was associated with software development. The manifesto is short and easily embedded here:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
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.
This is all there is to agile software development. When looking at the manifesto it is important to understand that the principals highlighted in bold are valued the most. Let’s look at each of the items individually.
Individuals and interactions over processes and tools
Processes and tools are important, but it is more important to have competent people working together effectively. Processes are good, having a clear routine of how to release software to production is a process; breaking down a task into smaller parts is another process. These are good, but shouldn’t come at the expense of interactions. Don’t be dogmatic about the process or the tool. They are not inherently bad.
Working software over comprehensive documentation
It is important to have high quality documentation, as this helps users understand how to build software or how to use it, but working software is what we are tasked to build, not the other way around. It doesn’t mean we don’t have any documentation. Gitlab has a great resource of documentation[3]. They go beyond the documentation of the software. They document meticulously their process and structures. And it serves them well.
Customer collaboration over contract negotiation
A contract is important, but is no substitute for working closely with customers to discover what they need.
Responding to change over following a plan
There is no mention of not planning. In the book How Big Things Get Done[4], the authors ask us to think slow and act fast, or in other words plan well. A project plan is important, but it must not be too rigid to accommodate changes in technology or the environment, stakeholders’ priorities, or even your understanding of the problem and its solution.
Agile is now a marketing term. It has become a noun. Everyone says they “do agile”. But you cannot “do agile”, you can only “be agile”. To those who said the agile methodology doesn’t prescribe planning or documentation, I hope I have clarified this. The original manifesto was defined in the world where dogmatism suffocated agility. Being agile helps build great software. Follow the manifesto, not the marketing.
Finally, I’ll leave you with 12 principles the manifesto defines in extension of the values.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity — the art of maximising the amount of work not done — is essential.
The best architectures, requirements, and designs emerge from self-organising teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
- https://en.wikipedia.org/wiki/Waterfall_model
- http://agilemanifesto.org/
- https://handbook.gitlab.com/
- How Big Things Get Done by Bent Flyvbjerg and Dan Gardner
