(Paraphrased from Wikipedia) A racket is an illegal business, usually run as a part of organized crime. The best-known is the protection racket, in which criminals demand money from businesses in exchange for the service of "protection" against crimes that the racketeers themselves instigate if unpaid.
You could say a racket is when you claim to be doing one thing that looks good while really doing something else that isn't.
I would suggest that running rackets is something people do all of the time – most without realizing it.
For example, we all know the person who is always a victim of things. We continuously hear their lament. One might ask them why they can't get out of it, but, being the true victims they are, they are unable to do it. By the way, if they are able to break out of their victim mode but chose to stay in it, they often shift to being a martyr. For example, the victim's racket about their boss:
Oh (woe is me) my boss is demanding I work late again to cover up for his mistakes. He gets to go home but I have to work late! Bummer. Nothing ever works out well for me. I'd quit this job but I can't get another one. I'm in such a horrible situation. …
The martyr's racket is not that different:
Oh my boss is demanding I work late again to cover up for his mistakes. He gets to go home but I have to work late! Bummer. I could get another job but then this company would fall apart. But I'm tough and I'm going to hang in here because somebody needs to.
I hope you get the idea. There two obvious parts to any racket:
One may wonder what keeps something like this in place? Why not just do something about it. In the protection racket, you keep it going because there is a benefit – getting paid the protection money. In the personal racket, there is also a benefit – but one which must remain hidden, because to put it out in the open would destroy the racket.
I call this the hidden benefit. In the above victim and martyr examples, the benefit is all of the attention that one gets by being a victim or martyr (not to mention being right and noble). Sure one's life is horrible, but at least one gets to get sympathy (when victim), or respect (when martyr) and attention in either case. At some level victims and martyrs are also better people than the people making them victims or martyrs. BTW: I do not really believe they are better people – nor do I think they are worse people. All of that is just story about what is happening.
So what does this have to do with IT?
Well, I would suggest there are some pretty big rackets being run in IT –by the business side and the IT side. In fact, there are several levels here, but I'll just cover two. You'll get the idea.
Here's the obvious part of the business side's racket:
Here's the obvious part of the IT (development) side's racket:
BTW: You might notice that developers often run this racket with their own management as well.
We see this all the time – business can't get what they want developed and developers can't get the time to do what they really need to do. What we don't see is the hidden benefit both sides get – the benefit that keeps things stuck – that keeps us from resolving the challenges present.
The business side's hidden benefit: we get to be right and explain why we can't get the job done. We also get off the hook for not getting stuff done. It is the development group's fault, not ours.
The developer side's hidden benefit : we get to be right and explain why we can't get the job done. We also get off the hook for not getting stuff done and for being continuously in this horrible situation.
One should notice how the stories are almost identical, except that the business is playing the victim role while the IT is playing martyr. A match made in hell.
Seeing this dynamic is very useful. Seeing how your process helps you deal with this dynamic is also useful. My own sense is that methods that suggest looking at the entire value stream are less amenable to rackets – as everyone is responsible for the end result. Team focused frameworks, on the other hand, can make those in the scope of focus either martyrs or victims.
Does your process make you more right than the other side? Is one group committed and the other group isn't? If there is any sense that there are even sides, that you are optimizing one aspect of value development then I suggest you are feeding into this racket.
Before looking at how team-centric approaches can keep these rackets going, or even make them worse, let's look at how a more holistic approach can help deter them. One of Lean's most important guidances is "optimize the whole." This applies for both the business and the development side. For example, good management can't just say - "do this" and throw it over the fence. "Optimize the whole" puts responsibility on their leadership for the entire result - not just what goes into the development funnel. They should ask how their actions affect downstream workers. On the other side, developers can't just say "well, we did our part" (that'd be optimizing the development side. They must take ownership and see how their part fits into the bigger picture. Without authority, they must use influence. Influence in software development translates typically into creating visibility so others can see the affect of what their actions are on the team. Instead of being victims and/or martyrs (developers actually have played both roles) they must take action to show the business side the adverse affects certain business actions are having on them.
Kanban's explicit policies is a powerful tool here. It states that the development organization's process must be visible to the business side and management. That both the state of the work and how it flows must be able to be seen by everyone in the organization. There have been many experience reports about how this visibility has helped product managers avoid interrupting teams adversely because they understood how the teams worked. This is the anti-thesis of Scrum's combination of a "black-box" process, which claims one cannot state process, and attitude that the sprint agreement is sacred (which ironically, is almost never followed). Notice the difference how Kanban and Scrum affect the racket. When Kanban teams say - "you can tell us to work beyond our capacity but in doing so you are causing problems and here's why" they are exposing business' racket. They are also opening the door for partnership with the business and therefore not being a victim/martyr. However, when Scrum teams say - "we had this agreement and if you break it, we'll have to abort the Sprint. Don't ask us to tell you why we can't do one more thing - you've got to trust us", it just underlies the team knows better and management is bad for breaking their word.
This is an example of how Scrum keeps the rackets going, but do all team methods do that as well? Perhaps not. The key is that team methods that do not include illuminating the relationship with the team and the rest of the organization do. The challenge with team-centric methods is where they seem to come from - that is, that the team is the key. Lean suggests the entire organization is key - not merely the development team. The racket I've described has developers considering themselves (the development team) being more key than other parts to the organization. Following a team based approach supports that view (racket).
You might notice there are two levels of rackets going on here - business - IT and management - development teams. The dynamics of these two are similar, and I would suggest one strengthens the other. The only way out is to take a more holistic view.
A key point to observe here is that anytime negative behavior persists, there is a good chance that there is something you are doing to keep it going. Looking at the bigger picture is often uncomfortable, even scary. But it is often the only way to break down the rackets.