Team Dynamics & Esotericiscm
It happens from time to time that cultures clash. On a daily base it might happen to yourself walking along a hallway being rebuked to not greet people by saying “Servus!” It happens in meetings when suddenly somebody acknowledges the elephant in the room instead of keeping quiet to get over with this meeting. And sometimes it happens when you think that everything is clarified and explained.
A question in your Scrum exam will ask you what happens to a team whose constellation is changed — either by adding or removing people. The answer will be that its velocity will drop in the short term, recovering over an unknown period of time. Knowing that, it would be absurd to add new people to a performing team a few sprints before a critical deadline, wouldn’t it? Teams are social constructs. These constructs are not necessarily proven by numbers. But a person that is at least capable of understanding that a team consists of human beings might be able to follow the concerns one might have with randomly throwing resources at them.
The project management perspective is clear. More resources mean more people working on something valuable. Thus, results are delivered faster. What these people often leave out of the equation is the time it takes to have a team performing again after being restructured. Looking at Tuckman’s model, there are four phases. Forming, storming, norming, and performing. Changing any circumstances will result in a team being thrown back to the forming phase. In real life this would mean that new members joining will need time to adopt to the implicit rules that are clear for every existing member. On a functional level, new members might have to learn new skills to contribute to the value a team tries to generate. The same goes for removing people. The team needs time to fill the gap a fully active team member leaves behind. Understanding this should be common sense. Not understanding this should risk a project’s success.
Nevertheless it seems that numbers often beat social constructs and alleged team dynamics. Measuring in hindsight might prove the risks afterwards, trusting experienced Scrum Masters, however, might help people to not take these risks. As for my personal experience, it happens that such soft facts count as esotericism for some people. As if we’d light some joss sticks to exorcise the demons of bad software development, throwing holy water at our sprint board to have the good ghost of the manifesto’s authors’ ancestors on our side. Claims like “Scrum teams can’t grow” or “you’re saying that we cannot scale this project” follow the lack of understanding on how teams develop. But scaling at the wrong time in a project will hopefully alert your teams and their Scrum Masters and have them teach those unaware of what’s to follow. Bad planning and unfocused project management are often the causes of falling back into traditional assumptions like “more resources at any given point in time immediately mean more efficiency.”
I can totally understand that classical theories originating from classical crafts and industries are able to follow these heuristics. But a highly critical project in software development driven by a couple of unexperienced teams that are still about to be coached in both craft and process might escalate into an unstable house of cards. The more cards you try to stack, however, the less solidity you’ll get. Therefore it’s important to protect teams for the good of the project from these kind of decisions. In the end, you will have to work out a tradeoff. But make sure the tradeoff causes the least damage possible. In our case, we added new people to the third of three teams. This team is still new to the project (two sprints as of today) and just started working together. Thus, it’s easier to get them going with the new members. The other two teams are already performing well and driving the project, whereas the third is still in its forming phase.
Conclusively I have to admit that it has been an interesting experience to see this clash of cultures— agile software development vs traditional project management. Both worlds have their advantages, both worlds have their frictions. As long as you keep up communication and are willing for tradeoffs on both sides you might see your project developing in a positive way. There’s too often a protective stance on both sides. It’s important to understand each perspective, though. Otherwise, a so-called agile transition is not going to work. Organizations are far from being finished adopting new processes and new approaches to project management. Looking back at those ever-mentioned micro steps for macro solutions, it’s important to support where ever you can. You’re the agile coach, a wannabe agile leader, a Scrum Master, a Kanban mommy or whatever. But you and probably your whole organization are not agile enough.
