By: Greg Tutunjian, Eliassen Agile Coach
While each team’s experience of Agile Adoption is unique, every team that is new to Agile is faced with the consistent theme of adopting Agile practices, principles, and tools. The process of adopting these things is in addition to delivering value to the business (AKA real work). The Product Owner and key stakeholders are invested in the process, but they’re accountable for delivering the real work above all else. The core team is faced with learning the What, How, When and For Whom all at the same time. This maelstrom is not always sufficiently visible to non-developers, and is often under-appreciated outside the core team. One solution to this dilemma, that I’ve adopted on a current engagement, is the introduction of a Team Backlog.
The Team Backlog is tailored to the project and to the team and includes Agile Adoption concepts, practices, principles, and tools that are specifically required for the team to succeed. (This isn’t boilerplate from the team’s training experience or from the company Intranet). The Team Backlog is developed and maintained, either by an Agile Coach or by the Scrum Master, through direct engagement of the core team. Similar to the Product Backlog, everyone on the core team has input into the Team Backlog but one person owns it.
These are some of the entries in a current Team Backlog:
- Definition of Done
- Definition of Ready
- Team Working Agreement
- Work In Progress Agreement
- Continuous Integration
- Dependency Management
The Team Backlog can be extended to include Software Engineering practices, and other practices that are new to the team. Having a robust Definition of Done doesn’t guarantee that you’ll get to Done on time, or with the prerequisite functionality tested and documented sufficiently to be accepted into Production. Sometimes teams need support in non-Agile practices in order to succeed and the Team Backlog provides a means of capturing and resolving those impediments.
To make the Team Backlog as effective as possible, ask core team members to own entries and deliverables. When someone on the core team isn’t speaking up during Iteration Planning, work with them to take ownership of a Team Backlog item to get them comfortable speaking in front of the team and collaborating transparently.
Agile Adoption is real work too, and a Team Backlog makes that work transparent, while further enhancing the team’s ownership of it’s own success.