As anyone who has worked with me will tell you, I don’t enjoy scrum as an Agile methodology. While the concept of sprints and scrum teams serve their purpose, I find that having flexibility in both deadlines and team composition is an invaluable tool in certain circumstances. Taking the example of a new, large project comprised of months of effort and many milestones: it can be advantageous to have smaller, flexibly-sized teams (which I like to call “Taskforces”) organized around smaller sub-projects or tasks, which can change over the course of the larger project. Using sprints, a project lead is concerned with coming up with a deliverable to fit into a fixed number of days of development. Using scrum teams, a project lead is concerned with sizing these smaller sub-projects to best make use of all team members on a given team. By keeping both the deliverable time and the team composition flexible, the team can better adapt to the changing nature of the project.
Opponents and critics to this approach will point out that the beauty of scrum is that the team can more accurately measure their velocity the longer the same group works together. In theory, this is perfectly valid. In practice though, given the short-term “gig economy” that we work in, that measure becomes less and less accurate (and therefore less and less meaningful). I would offer the counter-argument that by allowing/permitting/encouraging teams to change their composition, team members will be exposed to more of their peers more often. This exposure will offer new perspectives, increase the chance of getting valuable feedback, and up-level the individuals.
Of course, this does not preclude me from trying to hold other agile ceremonies such as Backlog Grooming and Standups; both are valuable tools to communicate goals and statuses to the team. The only thing that changes is the delegation of the work and to whom.
Beard and Bourbon 