- Can a sole software developer working on a small project be agile?
- Can a team of five software developers without any dedicated test support be agile?
- Can a group of 20 developers, testers and analysts working on a major project be agile?
- Can an inter-departmental, cross-functional group of 100+ people working toward a common goal be agile?
- Can an entire company, or at least a division of it, be agile?
The answer to all these questions is yes, absolutely, yes.
The ways they operate, the rules they follow, and the speeds at which they deliver will vary. That’s okay. Being agile means a few key things:
- Open, honest communication within the group and across the organization.
- Working software delivered at regular (and preferably short) intervals.
- Customer collaboration and active involvement, not just “weekly memos”.
- Change acceptance not change “control”.
Obviously, a very large team or a collection of teams cannot deliver working software weekly or even bi-weekly. But, nowhere in the definition of agility is there mention of specific timelines or durations. There is a general comment about delivering software frequently, “from a couple of weeks to a couple of months”.
The idea of agile is to change the focus and quicken the pace, not to get hung up on the implementation details. Don’t let fear of things like frequent deliveries or daily meetings stop you from trying an agile approach. Those things are not required to be agile.
Whether you follow Scrum, XP, Kanban or any other agile approach, review the core principles of the AgileManifesto and take them to heart. (Please share your opinion!)