Call me a cynic I have never seen Work In Progress (WIP) limits taken seriously at big companies. So here are 9 ways of increasing productivity that do not reference WIP. TLDR; Create clarity and focus by eliminating everything that is a distraction to front line individual contributors.

9 Ways

• Apply a surge of resources to fix top live site issues
• Treat critical priority bugs as a big deal and make sure they get fixed the first time
• Require tests to verify tasks are documented at design time and implemented before production time
• Automate deployments and ensure the right environment configuration
• Create emergency lane for developer work to enable tasks to jump to the front of the queue
• Continuous integration of builds along with basic correctness tests
• Create targeted goals for responsiveness and peak requests per second
• Automate provisioning to grow and shrink capacity
• Enable features flags to eliminate branching and merging (branching is ok; merging sucks)

Surge on Live Site

Nothing worse than live site fires to suck the life out of a team. Fires happen at random hours and keep people up all night. Fires are unplanned, and eat into planned work. Fires are huge distractions that make it hard to do excellent work.
Why it is genius
When you use the word Surge it sounds cool. People immediately assume the effort will have an impact. Really it's all in one word.
Why it sucks
Should have never needed a Surge. Oh well, no sense in revisiting decisions of pointy haired bosses.

Fix Critical Bugs The First Time

Mostly people assume software has two levels of quality. It either works or is does not work. Sadly most code works and it looks awful. Its like an abandoned factory. All the windows in our abandoned factory have holes, it is dirty and dingy. In this environment, developers tend to get in and get out as quickly as possible. As a result they don't take the time to truly fix critical bugs. They make minimal fixes and test against one or two key scenarios. This is also know as legacy code.
Why it is genius
Quality is a self perpetuating machine. Once a high bar is set the code starts looking better. Once the code starts looking better other developers want to keep things neat and tidy. It is like a factory with shiny new windows; no one wants to throw the first rock.
Why it sucks
Now you are going to have to spend 2 weeks fixing that bug and that leaves no time for the cool kubs prototype project. Its sucks to be the first on cleanup duty.

Test Before Production (aka Clear Requirements)

It seems obvious that code should have some tests. The truth is the requirements were very vague and wishy-washy so we pretend we know what to code up. Then the tests come along and we discovery we had no-idea how it was supposed to work. Instead of man-ing up and fixing the problem we polity explain there is no bug, and it works as designed.
Why it is genius
Tests are the best requirements. If the people that wrote requirements had to write tests they would quit and run away in horror. So skip the requirements and just write the tests. Bonus points for, negative tests, tests outside the happy path.
Why it sucks
You may need to talk to customers to figure out how this feature was supposed to work so you can write the tests. In the process of talking to customer you may discover you are building the wrong thing.

Automate Deployments

We all hate waiting. Why wait for deployments?
Why it is genius
Honestly the reason to automate deployments is to eliminate human mistakes. All of those manual configurations and manual release steps causes lots of rollbacks and outages. Automation ensures we do things with precision and fewer manual errors.
** Why it sucks**
Someone needs to tell the release person who manually configures and deploys the software that he or she needs to move up the value chain. That is the polite way of saying a machine has taken their job.

Emergency Lane

In every project there is the catch-22 moment when the team realizes they need the mock data before they can code up the server side code. Hey missed dependencies happen, we call them emergencies. So put some emergency work in the the queue to create mock data. Problem solved.
Why it is genius
Emergency Lanes make escalations ok. It is the single best thing your team can do to shift from controlling change to embracing change. Without the emergency lane you are forced to sneak away from "real work" to work on critical fixes. The effort you put in is never tracked and as a result you and the rest of the team end up oversubscribed.
Why it sucks
People outside the team abuse the emergency lane to get their tasks completed. As an example, the product manager wants a shiny new feature an puts it in the emergency lane. Bottom line, only committed team members should be managing the tasks. Folks outside the committed team need to respect that.

Continuous Integration

Take your code and merge it, build it, test it, test it like production, and at the end you get a thumbs up or thumbs down. NOTE: thumbs up is good, that means it worked
Why it is genius
Finally feedback right away. You can now write awesome code and get things into production. As a developer you will be happy that your awesome code is now in production. Before Continuous Integration things failed for no apparent reason. Honestly before Continuous Integration it was almost like the system was cursed. Burning incense and wearing your lucky t-shirt was the only way to get code into production.
Why it sucks
With continuous integration you no longer have the ability to shrug and say works on my machine.

Targets for Perf and RPS

Get a napkin and write down how many requests per second (RPS) your system can handle on a good day. Right below that right down how long those requests should take to complete. Congratulations with the help of a napkin you now have a Service Level Objectives (SLO).
Why it is genius
Since you know what your service can do at peak you can tell everyone else. When that brand new mobile app goes online and slams your service with addition 10,000 RPS you can politely point to the napkin taped to the wall. PS expect the napkin to be ripped to shreds
Why it sucks
I believe I am rich and thin. My kids are geniuses. I believe my service is fast and powerful. Once measured your service will look slow and weak. SLAs crush egos. Tip: don't weigh yourself or give your kids an IQ test

Automated Growing and Shrinking Capacity

Software is amazing. Software can do almost anything including grow and shrink. Imagine if you could grow a foot taller for a basketball game! Imagine if you can slim down for the cross-country flight in economy class!
Why it is genius
No need to write super efficient code and struggle with complex caching logic. Just add more compute power and grow your way out of it. When traffic dies down get rid of the excess flab to save $$. A win-win.
Why it sucks
Growing is great as long as the load balancer and database can keep up. Often they cannot keep up. Growth is limited by other factors in the environment. The second problem is the reactive nature of growing hosts. The signal for a cluster to grow in capacity only happens after the cluster runs out of capacity. Adding new hosts to a cluster takes time. A late signal and a lag often results in capacity arriving too late.

Feature Flags

Your new middle-out algorithm for compression is genius. Making the update to the new algorithm is a big change and a big risk. If only there were some way to have both old and new algorithms at the same time. Then switch to the new algorithm when you wanted to test it.
Why it is genius
Feature flags let you push out crazy good stuff while protecting users from the associated risk of change. By adding a flag to the requests you can light up new code and test it with a small set of beta users.
Why it sucks
Putting your code behind flags is addicting. Once you experience the rush and exhilaration of feature flags you will want to do more and more. It will all come to end in a bad way. Your feature flags will need feature flags and the code will become an unreadable mess of nested switch statements. Consider yourself warned.