I never got around to post the follow-up article on Lean and how it relates to software engineering. Now, over 7 months and a huge scandal that made people skeptical about Toyota’s lean manufacturing later, here’s the post on Agile software development.
There are hundreds of papers and articles on Agile written in the past decade. I don’t want to compete with them so I’ll just be brief with this post. I’ll just go through the core of the subject, namely the Agile Manifesto and the Principles behind the Agile Manifesto, and provide short commentaries on each point.
First off, let’s look at the Agile Manifesto:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
The “by doing it” part is important here because it means that the software development methods that they are advocating came “from the trenches” and have already proven themselves. Contrast this with theoretical or (government) regulated software development practices (e.g. Waterfall Method) which don’t really work well in the real world.
Individuals and interactions over processes and tools
Software is primarily created by knowledge workers; processes and tools may help improve productivity, but they are worthless if the individual developer is taken for granted.
Lack of interaction, as we have seen in Lean, is waste. In traditional software development, teams are divided into “silos”, each with a certain skill (e.g. analysts, programmers, QA, etc) and have limited communication channels. This often results in unaligned understanding of the system, as depicted by the somewhat infamous comic strip below.
Working software over comprehensive documentation
Again, this is similar to Lean’s concept of muda. Comprehensive documentation is often unnecessary, most often a side effect of separating your team into non-interacting silos. Sure, some clients require documentation as part of the deliverables, but in reality, they’re not that important. Besides, if you deliver them too early in the project, they’re likely to be obsolete by the end of the project due to the unseen requirements changes. (Not to mention they’re easy to fake. Take it from a guy who had to do this thing for years.)
In the end, what matters is that the customer gets the working software they want.
Customer collaboration over contract negotiation
The previous two points explains this point well. Learn to work with the user and expect a higher chance of successful projects (and repeat clients).
Responding to change over following a plan
If you can’t understand the simple concept that real-world software projects change a lot in the course of development, look for another field to work in (preferably a non-engineering one because this “problem” is common to all engineering fields). Thus it is imperative for software developers to embrace change rather than mitigate it via restrictive plans.
That is, while there is value in the items on
the right, we value the items on the left more.
Many people blinded by the agile buzzword tend to forget this part of the manifesto and just trash the right side without considering the context. Yes, the right side is still important; don’t forget that agile methodologies also consists of processes (e.g. Scrum) and tools (e.g. kanban), and even documentation (e.g. user stories). The point here is that you should just learn to value the left side more.
Now on to the Principles behind the Agile Manifesto:
We follow these principles:
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.
This part focuses on the importance of the customer, without which we software developers won’t have money to put food on our tables.
It’s easy to forget that we’re not merely creating software because the customer wants us to, but that we are making software in order for our customers to gain a competitive advantage. A system delivered half a year late, regardless of whether it had no bugs, might already be too late for our customer–their competitors may have already released a product that was able to capture the market in that time frame.
This is also the reason why continuous delivery of the product is important: this way, the customer can see if the project is going according to plan (and have the ability to steer it early) instead of the usual pray-that-the-system-is-what-we-want at the (single) delivery date. This also gives the user the opportunity to release a not-so-complete product with just enough features before the competitors can capture the market.
Business people and developers must work
together daily throughout the project.
Already explained in the “Individuals and interactions over…” above.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
Also explained in the same manifesto line, but this principle also brings to light the futility of micromanaging developers.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Face-to-face conversation is, simply put, far more efficient and effective than phone calls, teleconferences, boardroom meetings, e-mail, and documentation. Having the prototype/working software at hand also helps.
Working software is the primary measure of progress.
Working software, not documentation or filled up Gantt charts, measure the progress of the project. There’s no sense in saying “this module is 80% done” or something like that; that feature or module is either working or not working.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Translation: the managers are there to make sure things move smoothly i.e. not hinder progress through bureaucracy or other stupid things. So are customers. And developers. Heck, everyone that has anything to do with an agile project must work to avoid possible roadblocks.
Continuous attention to technical excellence
and good design enhances agility.
This is why refactoring and other low-level agile practices are important: it’s hard to change software (i.e. be “agile” in the somewhat literal sense) when your design and code base sucks.
Simplicity–the art of maximizing the amount
of work not done–is essential.
Again, we’re back to muda.
A side note, though. Agile wasn’t based on Lean, though the former gets many lessons from latter. Which makes sense because Lean, in its most popular form TPS, works primarily for the manufacturing industry, and software development is not just a manufacturing industry (it’s also partly a service industry).
The best architectures, requirements, and designs
emerge from self-organizing teams.
Translation: they don’t come from following guide books given by governments or certification institutions.
Allow people to work together well and they will eventually find what best suits their project.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
And here at the end is our looping structure: the feedback, the retrospective, the follow-through. Without this principle, agile is a useless unrepeatable cargo-cult fad buzzword.
—
With this article, I can finally move on to other agile topics… (yay!)
