An important management tool to improve team performance is the Team Squeezer. It’s really simple: just use hierarchical power and exert pressure to make the development team hurry up. Usually the Team Squeezer backfires.
Is your software team spending too much money and time on features? Do you suspect them to gold-plate their code and even goof off? Here is your solution: the team squeezer. It takes as little effort as turning a wheel: Just reduce the money the software team is allowed to use to build your dream software with all the features and functions and the glitter. Don’t hesitate to squeeze, the more the better. We all know that people work best under pressure.
I don’t know who sold that story to managers. And I don’t understand why any company would want a person who believes in this story in their management team. I however could understand why a company would try to make sure to send such a person over to their hardest competitor.
Pressure reduces team performance
Lets take an agile transition scenario to illustrate this: We have a bunch of people that are used to work in well-organized traditional way with a project leader assigning work packages to the individuals. Requirements people write requirements specifications, developers take the specs and create code that more or less matches the specification. Then testers take the code and whatever documentation they can find and test it.
Many people are quite happy working that way. They have their small and quite easy piece of work to complete and don’t need to understand the whole complexity. If something goes wrong, there is always someone else to take the blame. Whether the overall project is a success isn’t their concern. Not so happy with this working style are the users – they get hard to use, overly complicated software that does not support their work well – and the user’s managers – they pay loads of money to have software for a business that already changed.
So introducing the shiny new agile world: One self-organizing team with the common goal to make a piece of software with impact, one backlog to plan and organize the work, user stories to manage the conversation, the “three amigos” working together to embrace change in business and so forth. Everything is set up, the team starts working, the agile transitions begins and the managers expect to finally have a piece of software that matches their expectations and can be constantly adapted to the new needs of the business.
After the first iteration the Manager complains about the slow progress: “we need to increase velocity”.
This bit of pressure is enough for most teams to forget about agile in favour of save, i.e. known, ways. “We have no time for experiments so lets stick to what we can”. The team members forget about leading the conversation about the best possible solution for the problem at hand. Requirements engineers revert to writing specifications, developers wait for the final specs and implement what they think is best and testers do testing based on the documents provided – they just do that with user stories and a backlog. During the retro, they discuss how a user story needs to be structured and what must be done for a user story to be ready.
The first thing to go under pressure is learning new and in the long run more efficient ways of working in favor of known and trained ways of working.
After three sprints the Manager insists on the milestone: “We must have these features by then. Hurry up, will you?”
Higher pressure and the team stops meeting for the retro. “We have to work and have no time for such nonsense”. “Lets be done and learn afterwards for the next time”. The team also stops caring about creating a useful piece of software. “The manager wants features, so features she will get.”
The second thing to go is improving current ways of working in favor of just working the way they always used to.
And rather than making an impact, the team delivers functions.
The team also starts taking shortcuts.They drop pair programming, write fewer and fewer unit tests. They accept stories even though bugs are still open. The team cares less what the software is actually used for and how people will use it. As long as the features are here. “Debts? Don’t worry, we can do them later”. In addition, a clever team makes sure to assign a bit more effort to the user stories. Transparency is gone.
The third thing to go are trained best practices in favor of hacking ones way through and hoping to be far away when everything breaks. This of course is covered up so everything seems all right until it’s too late.
After five sprints the manager tightens the screws. “Ok pals, take Jack as your role model: He delivered 400 lines of code average per day during the last sprint! I want everyone of you to deliver at least 200 lines of codes every day! Did I make myself clear?”
At this point, the survival tactics will jump into action. “Refactoring? Unit testing? Pair programming? Architecture circle? Are you kidding me?! I have to write this code and I don’t care if this really makes sense or if it works. That’s the job of the requriements guys and the testers.” Features sieze to be relevant. The main point is to deliver more than others. Not helping is a crucial element of success. Because while a person can’t run faster than the lion, the person can at least make sure to run faster than the team mates.
At the fourth stage the team completely dissolves and individuals resort to basic survival tactics.
The team doesn’t make the planned release because the software is full of bugs, no unit tests, and loads of functions nobody needs that way. Everybody blames everybody else. At least the task force created after the launch is able to fix the most urgent things – after four weeks of working 100 hrs per week – and the software can at least be used, even though users hate it.
Having completed such a difficult project with good success the Manager gets promoted and concludes: “I was quite disappointed about that agile stuff. It didn’t pay off at all. We had the exact same problems as before. It’s quite obvious that agile isn’t working.”
Squashing the team between pressure plate and feature block
Lets quickly review the essential points.
- Creating a team needs investment into the team. The team needs time and the freedom to experiment to develop an effective way of working.
- The time invested into the team can only be take from the time available for development.
- Activating the team squeezer simply uses resources needed for creating and maintaining team performance for implementing features.
- The team cannot form nor improve and even dissolves.
Not only does the team dissolve, also the promise of agile is gone. Because this promise relies on a couple of things where the following three seem to be the most important in the light of this article: (1) the team does not loose focus and strives to achieve the desired impact; (2) user stories are really done and well done so there is transparancy about the progress made, and (3) the team has time to learn about more effective ways of working together so it gets better and better at doing (1) and (2).
The Team Squeezer creates a team doing whatever it did before (or even worse) with tools designed for agile way of working. The software fits as bad as ever and can hardly be maintained. The Team Squeezer simply nils the agile promise.