I have a proposal for a new starting point for any team wanting to take an “agile” approach. Specifically, I’m looking to avoid describing agile as a one-liner like “an iterative approach that empowers a team to respond to change successfully in a rapidly-changing environment.”
I don’t think reflecting on statements like that, or having daily stand-up meetings, or having a certified Scrum Master, or enforcing 100% pair programming and test-driven development (alone or all together), set a team up to unlock the potential of an agile approach.
What I believe is most special about agile teamwork is how it frees a team to work how they think they should work based on the challenges they see on the ground.
In that spirit, below is my modified suggestion for how to take on an agile approach for your team. First, think of The Rules as a living document or working agreement for your team. Then, take The Suggestions as an incomplete set of agile tools (often incorrectly considered “Rules”) your team can take or leave (even though I’d strongly argue for not leaving some of them out).
The Rules for Agile Teamwork
1. Once formed, the team has full autonomy to determine how they work and deliver. This includes, but isn’t limited to:
- how often they meet;
- what internal team roles exist and who holds them;
- how they collaborate and/or hand off work;
- how often they deliver updates outside of the team; and
- how they determine how much they can take on or project they can deliver within a given time period.
2. At least every couple of weeks, the full team will gather for a meeting in which any team member can submit an observed issue with or a proposed change for the way the team works and delivers. The team is encouraged to consider and implement changes that increase efficiency and effectiveness in delivery value outside of the group while maintaining or improving the sustainability and well-being of team members.
3. Rules #1 and #2 cannot be removed.
4. This rule would include anything the team agrees they should do that flows from #1, #2, or #3.
The Suggestions for Agile Teamwork
1. Drive the development of new functionality with unit and end-to-end tests.
2. Prioritize and estimate a backlog of work for at least the next two to three months.
3. Consider trying on Scrum for size and have an internal team member take on the Scrum Master role.
4. Choose a repeating time period and iteratively deliver working software at the end of each period.
5. Periodically pair on design, planning, and programming work.
6. Develop a schedule or set of guiding principles for when to pair or not to pair.
7. Schedule regular time to meet and discuss your system’s architecture and technical debt as a team.
8. Hold a daily, or non-daily, stand-up meeting.
The Point of Agile Teamwork
Having a debate about whether a team “is agile” or “implementing agile correctly” or “taking an agile approach” is a complete waste of time. That is, unless you are specifically talking about whether the entire team believes they’re in control of, and can change, the way they work.
If your team decides to skip writing tests and never pairs with each other, I probably wouldn’t consider it a good decision, but I wouldn’t say that means you’re “not agile.”
However, if your team has a Scrum Master who dictates and controls your team’s process — I unequivocally deem your team’s approach as not agile.