Many teams claim to be “Agile” or “a little bit Agile.” In your experience, which other development methodologies work best with Agile, and which seem to present the most challenges?
I think we all need to stop being concerned with labels, and focus on continually improving the quality of our software product. Take time frequently to evaluate what’s working and what isn’t with your software development process. Identify your biggest problem, and think of a few small experiments to try to make it a little bit better. Once you make progress on your biggest issue, see if it’s still your biggest impediment, and if not, start working on the problem that’s now causing the most difficulty.
As you plan, budget in plenty of time to learn new skills and try new techniques to get or keep your technical debt under control. It’s no accident that companies who enforce time for team members to learn and try out new skills together have a high level of innovation. My own team recently started devoting 10% of each two-week iteration exclusively to learning, in addition to two iterations per year for managing our technical debt.
Adopt a whole-team approach to quality, engage people in all positions including the business folks in trying alternative ways to implement new features and delight customers. Make sure people in all the different positions are equally valued. You need diversity to innovate and improve. Find ways to keep feedback loops short, so your team can stay on track. Think up several different potential solutions for each business problem or several different ways to implement each new feature, and delay choosing the “winner” until the last responsible moment.
Don’t worry about whether you are “Agile” or not. Worry about whether you have the best people to develop the necessary software, and whether or not they are being allowed to do their best work. Overnight transformations don’t really happen. Baby steps are good. Is your software a little better every week? Are people learning something new every day? That’s what builds successful, high-functioning software teams.
This was first published in June 2012