The IT Racket and How Team-Centric Agile Methods Support It

May 28, 2011 — Posted by Al Shalloway

(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:

  1. The story – … my boss is demanding I work late … "nothing works out for me" or "I'm tough"
  2. The cost – I don't have a life

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:

  1. The story: Devs are geeks and don't understand things. We are the ones who make things happen.
  2. The cost: Our development expenses are way to high and the quality of what we get is way too low

Here's the obvious part of the IT (development) side's racket:

  1. Business folks are interrupters, don't understand development. The don't know what is required to get quality and are always pressuring us – which makes things worse.
  2. The cost: We have to work hard to barely get by and can never catch up with what is really important

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.

 

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Comments

It's been pointed out that I'm running a racket here too. And I won't deny it.  Here it is:

1) I claim to be providing information about Scrum that is useful to clients.

2) i get benefit from it because it gives me a name and gets me clients (not as many as people seem to think).

3) Hidden cost: I've alienated some of the Agile community and have a hard time seeing certain aspects of Scrum.

By noticing this I have toned things down a little.  Even spent much of my time with Ron Jeffries and Chet Hendrickson at the Scrum Gathering.

I certainly do not claim I am not running rackets.  Everyone does. Can you run Scrum without it strengthening the rackets I'm mentioning?  Sure.  Course, that would be adding something to it which I virtually never see - Scrum within the context of optimize the whole.  That would be a better thing.

While there are often personal motivations in doing any kind of work, I still assert that my primary motivation is the benefit others receive from the information I provide. What is conveniently forgotten by those who dislike my message is that years ago I abandoned the Scrum CST/CSM treadmill because it was moving people in the wrong direction. For all the attention of some recent Scrum defections in the last year or two, I can claim to be the first one about 4 years ago. This cost my company hundreds of thousands of dollars over these years.

This, of course, does not make me a saint.  We cannot totally avoid the forces that drive us.  We can notice them, reduce their charge and be driven more by our commitments.  Mentioning rackets is not intended to justify my own or anyone else's actions.  It is meant to make us think about our true motivations.  I have no doubt the racket I describe at the top of this comment drives me to some extent. But I am clear it is not the primary driver - as evidenced by my taking actions that were not in my own financial interest (leaving the Scrum Alliance).  My primary driver is creating value and opportunities for practitioners in the software industry.  I admit

The point is, it is critical to understand what drives you and to take responsibility for it. When I first wrote this blog I stopped at:

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. 

because I wanted people to think for themselves what their rackets were. I added the rest at the request of some readers. I still find it interesting that when I speak of things that people consider negative to Scrum, almost no one has ever discussed my assertions but instead talk about me.

Alan Shalloway, CEO Net Objectives

Hi Alan,

The acknowledgements you make here add significantly. There is always a bigger picture, beyond them and us. That doesn't mean that in many instances that culturally there isn't a true perception of them and us, and depending on your target audience this perception can be used to sell ideas.

This "sales" racket says nothing about the validity of the ideas being sold. All it says is that appealing to peoples prejudices can be an effective sales technique.

So teams aren't intrinsically good or bad. In the same way that Managers aren't intrinsically good or bad. The good and the bad, the them and the us exists in peoples minds. Elevating peoples thoughts means moving beyond simplistic two valued thinking ourselves. I see nothing in Scrum that stops you doing that.

To answer the question you raise:

"Can you run Scrum without it strengthening the rackets I'm mentioning? "

I do so all the time. It starts with not taking the chicken/pig thing too seriously. I (sometimes) use it as a bit of light humour to shake things up in an otherwise stuffy command and control environment. It also requires a little humility on the part of people who may have a tendency to take themselves too seriously, and the realisation by everyone that there is no true them and us, but a number of concentric teams with the outer-most team being the organisation itself (or even society at large if you choose to go there!).

Cheers,

Paul.

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban