One of the precepts of agile teams is that they do not dissemble and reassemble at the end of the project or any time beforehand. In fact, the concept is that the “project” never ends so the team just stays together working on a never-ending backlog of items to be done.
This is ideal. The team grows together, works more and more collaboratively as it works together over time. An agile team that has worked together for a long period of time and has reached that pinnacle of Performing (as defined by Bruce Tuckman), would not need a Scrum Master, daily stand-ups, or even retrospectives. And the team would produce prodigiously.
However, in today’s world, individuals are still the Lingua Franca of the workforce, not teams, and every member of every team is available for transfer to another team at any time management sees the necessity for workload balancing or evening out costs on multiple projects.
So, of course this is not considered “Agile” by the agile advocacy, but it is real life. And despite the advantages of a standing team of Agile developers, projects do come to an end.
In one example that I witnessed, an agile team of eleven came to the end of their part of the contract. Since the termination was scheduled just before the end of the year, we prevailed on management to extend the team into the new year. The team had been together for just over three years. They started working in the Scrum framework and as time went on they continued to improve and work together as a team. Eventually, they found that the Scrum Master became extraneous and was not really adding any value to the team. They were able to conduct their own ceremonies and resolve their own issues. They also abandoned the daily stand-up because it was redundant. Since they were co-located, they were constantly updating each other and resolving impediments. They practiced “swarming”, similar to a Kanban flow, in which the entire team worked together on any problems or impediments that came up. And, in the end, they did away with the formal retrospectives because they held retrospectives constantly throughout the sprint by noting activities that they did that worked and didn’t work and making adjustments as they went rather than holding off until the end of the sprint.
The team was in all regards a Tuckman “performing” team. But the organization for which they worked was out of budget for the project and also basically out of work since the team had completed just about everything. The remaining items on the backlog were of so low priority, the organization decided not to pursue them. To the organization’s credit, they did try to identify another project or work for the team, but being the middle of the budget year, it did not succeed. There were other agile teams working on other projects and the team members were given a number of alternatives. Several joined other agile teams. A couple had had their fill of “Agile” and went back to some non-agile mainframe work, one left software development and moved into a quasi-management position, and two left the organization completely.
I worked with the team for their last several weeks helping in the transition and capturing lessons learned to guide the organization for any future repetitions of the termination of a team (there have not been any since this one). The interesting aspect of the phase out is that not one of the team members felt any bitterness or regret and all were, to a person, grateful for the experience of working in Agile and working with each other.