Refactoring not only helps improve the mechanical quality of code; it also helps you learn from your code. When refactoring, you converge on better models. Right now, your code works, but it may feel tense, even a bit brittle. Refactoring reveals the implicit model, which informs your understanding of the domain. In the test-driven development cycle of red-green-refactor, “refactor” is not optional, lest you accumulate technical debt and fail to learn from the coding experience.
Stand-ups that don’t end
It’s easy for stand-ups, which are supposed to be brief team-sharing ceremonies, to turn into extended meetings. Limit the conversation to simple statements about things the entire team should know -- what you did yesterday, what you’re doing today, and any blockers or help needed. In addition, a sentence or two on what you’ve learned can be helpful. That’s it. You may do this round-robin, you may do this by “walking the story wall” or however your team prefers.
Stand-ups are not venues for technical discussions, making decisions, proposing designs, swapping war stories, reorganizing a sprint, or doing anything other than communicating what’s necessary for group coordination. Come prepared, so you can listen to what others have done and are doing and decide if it’s relevant to you, instead of thinking about what you’re going to say. Anything that comes up outside of the mutual status update should be deferred to a huddle or email. A stand-up should take no more than 15 to 30 seconds per team member.
Agile teams should self-organize, choosing practices and ceremonies that fit their collective behavior. This, too, should be examined periodically, with everyone contributing to identify ways to improve the process and take the corresponding actions. The is often called a "retrospective" and is a neutral approach to fix processes without wasting time blaming people.
For example, one team member may have noticed that feedback from production users was coming in too late and suggests that shorter sprints may help. The team agrees, tries a shorter sprint time, and reconvenes in the next retro to see if it helped. In this way, the team’s processes are continuously fine-tuned.
One-size-fits-all “agile” often results in teams skipping retrospectives or reducing them to rote ceremonies with no actionable learning. If you’ve noticed a problem with your team’s process but are afraid to bring it up in a retrospective, the retro has been reduced to rote. An unexamined process cannot be improved, and team members must feel safe and encouraged to do so.
Manual testing (or no testing)
Testing is essential to producing operational software, and if you haven't automated your testing, you’re missing out on significant efficiency and accuracy. Lightweight test-specification techniques like behavior-driven development (BDD) make excellent companions to agile stories. In waterfall terms, BDD descriptions define use cases, specify requirements, and are acceptance tests, in one very compact form.
Sign up for CIO Asia eNewsletters.