In this episode of #talesfromthetrenches - We explore the tale of the self-destructing team Warning, this team will self destruct in 5 sprints.
The tales from the trenches videos will explore and share real life experiences & war stories with agility. We'll explore scenarios, challenges, concepts and identify actionable takeaways that you may wish to experiment with in your own agile journey as your forge your own tales in the trenches. Let me tell you the tale of a team I once worked with. They had been put in a very difficult situation and this was widely acknowledged. They were given a waterfall deadline and asked to work using agile ways of working. They were tasked with integrating multiple systems together from a legacy system, without any of the expertise or knowledge historically and had to piece things together. They were up against it constantly and began with the right intentions, but as time pressure increased, they stopped doing retros, their standups became status meetings, they began self destructing and the consequence, they all felt the frustration, the pressure. They wanted to change but felt they were too busy. This wasn't a single habit or behaviour that was destructive, it was multiple. And considering them with unconditional positive regard.. They were doing the best they could, with the knowledge and skillsets they had available, and given the situation at hand. However, one of my favourite quotes is 'Taking no action is a decision'. Through them choosing not to act, through them accepting that they were 'too busy' to change, they were accepting their reality and acknowledging that it wouldn't improve without action. They were consciously allowing themselves to self destruct. I encouraged them to start small. Think of a few experiments to attempt in the next few weeks focused on improving their current reality. To commit to examining in a few weeks what they learned from the experiments and whether it worked, or didn't, and then to tweak, or come up with new experiments to try next. They haven't fixed their reality yet, but they are on the right path, on the right trajectory and I'm sure if they keep embracing small experiments, they will get there. Top tip - Encourage teams to start small. A retro for example should come up with 3-5 experiments (Not actions), that a team can make capacity for in their next iteration and add to their backlog for transparency. Ask them to commit to these experiments and do a short retro to examine what was learned. Don't let perfect be the enemy of good and remind them that imperfect action is better than no action at all.
Link to the YouTube video for this story can be found here;