I’ve seen an interesting (and very annoying) trend recently - people who don’t know how to lead a well structured project and / or people who lead the under-estimated projects tend to “go agile”. Unfortunately, this “agile” doesn’t have much in common with true agile approach to software development. Let’s take a look…
What’s agile and why was it introduced?
The best definition can be found in so-called Agile Manifesto (http://agilemanifesto.org/) - in short, plain words: it’s a software development approach that focuses on:
- simplicity, simplicity, simplicity
- direct cooperation between business people and developers (over formal documents and sign-offs)
- constant pace of product development and frequent product roll-out
- on-going continuous self-tuning
- work is based on short user stories instead of complex overall designs
- constant changes are treated as a normal element of development process
Twisting agile …
Unfortunately many people understand “going agile” as something like this:
- we can abandon making documentation as we can always talk things through
- aaah, constant change is good, I like iiiiit
- no need for design, let’s just start coding what they want
- no need for architecture elements, we do only what’s needed for now
They are happy, because they’ve dropped off all annoying parts of classical waterfall approach. Unfortunately, those “annoying parts” had their reasons and if you want to get rid of them, you have to compensate their value somehow (even in agile projects).
- If you’re about doing agile properly - you HAVE to gather requirements anyway! They have to be written down, verified, prioritized and maintained in accessible registry. They have to describe WHAT will the software do (and your team should be able to prepare acceptation tests based on those requirements).
- Constant changes can’t really be constant. That’s why agile is usually done in short roll-out periods (in SCRUM they’re named “sprints”) - scope for particular period can’t be changed!
- Such approach needs constant monitoring and regular status reporting (on the level of team - even daily).
- Due to its specifics, agile works well in 2-8 people teams. Due to high degree of relying on direct communication, it’s not recommended for larger teams. Obviously you can split your project into several smaller teams, but most likely won’t be able to eliminate dependencies between teams’ work products (interfaces, common data model, etc.).
- If you’re giving up on having detailed business req documentation (because you find it expensive / hard to maintain), you need to guarantee 100% of business people availability on-site.
- In short-release model, when overall design is not prepared up-front, you’ll most likely have to change code from past releases to adjust it to new release requirements. That’s why you need to be able to test your product against possible regression in already deployed products. That usually means what you should either try unit testing or maintain a proper test script & data repository.
And see what happens…
What happens if you ignore those points:
- Your teams work products’ technical debt grows in an uncontrollable manner (I’ve seen companies abandoning products every 2 years to create new ones, as they were not able to properly develop old ones).
- Continuous changes of requirements lead to overestimating any task and massively increasing work costs (as team leaders are not stupid and they want to feel secure).
- Introducing new person to the team is a pain as there is no documentation and everyone is so busy with their job.
- If not everyone is aware of some functional agreement (which of course wasn’t written down) it may lead to inconsistency between what parts of code were to do - believe me, this will happen a LOT. It’s not that bad if you know which version is official and confirmed, but it may not be obvious…
- If business people availability is limited, you may encounter unexperienced delays (as there’s no prior agreement on what’s to be done).
- If development architecture (frameworks, libraries, tools, mechanisms) is not agreed first, it’s quite likely that several developers (or even teams) will do the same work independently (usually each version will have some pros and some cons, but there will be no optimal version).
- Errors in products deployed in past releases will start to appear (more and more frequently) due to missing regression testing.
I’m not saying that agile is bad, because obviously it’s not true. You just need to remember that you’re not getting agile if you just stop documenting in your project. Agile requires some practice and additional efforts - it requires that you really know what you’re doing.
A little bit more on some agile approaches:
http://en.wikipedia.org/wiki/Scrum_(development)