Way back when, when we were learning Agile as a company, we sometimes hesitated to present it as such to our clients. We weren't sure how clients would take it. We took what might call it a "stealth Agile" approach. Over time we got more confident with it and could point to successes as well as a few failures. But we learned from both. From that experience we extracted a few rules of thumb that are good to remember. In this post, I want to share those rules of thumb with you.

It became obvious, very quickly, that whenever we fell to temptation and cut a corner or fell back on the non-Agile ways, we would pay the price. Crappy code would come back to haunt us. People burned out, trying to be heroes and "save the day." In the end, none of the stakeholders would be happy. We had some code, but not code that we could be proud of. Of course, the reverse was also true.

Whenever we insisted in sticking to our Agile methodologies, things ended up well. Nobody got burned out. We put out great, high quality products. And stakeholders were happy and proud of what they did.

Them Are the Rules

From these early experiences we culled out a few guidelines that have helped us stay the course.  Hopefully, you'll find them helpful, too.

• Before declaring a story done, make sure that the code faithfully implements what the story asked for. This is part of the testing that development is responsible for, as well as unit tests and any other techniques that can help make the code ready for system test. Quality up front is a good thing all around.
• Going slow is the only way to move fast. Do not be tempted to release code that you know is not complete or well tested. This will come back to haunt you, and everybody else in the team, in the worst way.
• Do not work on more than two stories at a time. You may think you're multitasking but what you really doing is wasting a lot of time switching from one to the other. Programming requires concentration and it takes a while (15 minutes?) to get to the point where you are in the flow of it. If this is the only task you're working on, then you'll deal with each obstacle as it comes; if you have other tasks you're working on in parallel, it is very tempting to turn to it at the first obstacle. Doing this back and forth is costly in time and even in satisfaction.
• When you release a feature, and start on a new one, focus on it. When the bug reports start to come in, resist the temptation of fixing them as they come. This is as costly as working on multiple stories at once. Continue with your current task until finished. By now you can look at the bug reports against your earlier work as a whole; looking at them altogether may reveal systemic problems with the code
• Working on weekends is a no-no. Emergencies happen and all that, but if you find that a significant number of people in the team have to work through weekends repeatedly in order to complete sprints, then there is something else going on that needs to be fixed.
• Measure your teams' progress, and make it as visual as possible. The canonical Scrum whiteboard is a great tool for that.