Pitfall of Agile Development

First, let me say I'm am an Agile Development believer and evangelist. Not all projects and teams are created equal, and agile seems to make the most of any team. However, Agile methodology is an incremental and results driven approach, and focusing too much on the results can have its pitfalls.

The average developer designs code specifically for their problem. Even with broad software pattern usage, software is generally developed for a specific need. In a common agile development team, once the iteration's worth of issues are resolved, the next iteration obtains a new set and they move on. The software is only programmed to meet the needs of that iteration. Which is great because you get incremental value and functionality as you go. The problem comes when you take a look back at your code and you need to change something because you ran into an issue you didn't foresee, which you now have to accommodate in software written in a previous iteration. Now since that iteration already provided value, and you need to modify what that previous iteration gave you, you may even need your program manager's approval.

This change could happen in various ways. A lot of developers prefer addition over modification (open/closed principle), which is great when you design it that way from the start. Commonly however, the task was handled with naive forethought (to nobody's fault) and needs to be re-factored to account for these new issues. The code may have even been written by somebody else with a different vision in mind. The issue is then solved in a less than ideal way.

This sort of development occurs over and over because the leads and architects are busy, have different technical vision, and peer reviews are usually after thoughts. Here's what makes it worse. Peer reviewed code is considered "done". For some programs code is essentially untouchable after peer reviewed. So even though the term "iteration" implies you can go back and improve, it doesn't really happen, and it's more of just a series of small cascading waterfalls. It creates Frankenstein code.

So sure, the software works and is demonstrable but you're left with a hodge-podge of brittle software with little enforced technical vision. What needs to change is having the freedom to re-factor and improve upon already written code. Most programs stray away from doing this because it doesn't add function/value to the program tangibly. They are too focused on results and not the product. To the developers though this freedom is a godsend; a breathe of fresh air; a re-paved road to drive on again.  Here's what I mean:

• Technical vision becomes more clear because we revisit WHY we do certain things.
• Future iterations are easier because the infrastructure is more flexible.
• Integration becomes more seamless.
• Communication becomes more succinct since everybody's on the same page again.
• Team works closer together because they're not arguing over which way to do things.

No one can see the future, so even though the above practices help, you still need to consider actually re-iterating over software. Here's a few ideas on how to improve your Agile Development for proactive software development, you can keep re-iteration to a minimum:

• Have small iterations.
• Everybody can do anything. (Don't force roles (quality testers, database admins, and et.al.))
• Rotate a two person team and have them take an entire iteration to enforce technical vision.
• Have a team design meeting before every iteration.
• Include software design in your retrospectives.
• If you have multiple small teams, mix up the team members every few iterations.
• Have the leads have separate design meetings as needed and look as far forward in software requirements as possible (and don't come out without a commitment in your design).
• Have developers not write any code until a buddy developer approves their approach.
• Have a dedicated engineer (product owner) keep track of requirements and update documentation as needed per scrum team.
• Peer review rules:
• Early as possible peer reviews.
• Small peer reviews (200 lines of code max).
• Critical peer review comments are non-deferrable - deal with and escalate that bigger issue in that iteration even if it means the task overflows into the next iteration.
• Peer review must be signed off with an end to end test.

I'd like to hear your stories and any feedback, please comment below!