My first tech job was building and configuring enterprise servers and racks in a lab (or a factory depending on your definition). It was a blast because of all the neat toys that I got to play with but it was not without problems.
As time went on, I started making notes of some of the things that I thought were strange. We were constantly running out of floor space, so we couldn't start new orders and Techs spent nearly 10% of their time waiting for new orders to be brought in for them to work on. At first I thought these two problems should be mutually exclusive, if we've got so much work in front of us that we literally can't fit in the space anymore, then how can we not have anything in front of us to work on?
As it turns out the problem was simple, A rack is put in front of me, I start building it and run into a problem that I can't solve on my own. I then have to make a call to somebody else to fix it and move on to whatever is next because it's no longer my problem. Before you know it, everything on the floor is waiting for some magical fix that I can't provide, there's nothing left for me to actually do and so I sit on my hands and complain that I can't get anything done.
This was all an intellectual problem for me until I was put in charge of a team that was failing, even by our low standards. This team generally got smaller orders which meant we had more opportunity to get blocked on any one of them, which played a big part in their abysmal performance.
I went about the business of fixing this in the only way I knew how: by being loud and annoying (that's what 22 year old Sean did). There were five of us on the team, so I declared that we would only bring 5 orders into our area. We can be working on fewer than 5 orders but at no point do we put a 6th order in front of my team and I got loud and annoying when anyone tried to do otherwise.
This pushed the other side of things, when an order became blocked it became important to unblock it so that we could really finish it and move on. Sometimes it was painful. Really painful. Really Really Painful. A second order became blocked and it was unbearable.
You see what happened over time was that my team spent less and less time getting hung up on random issues and more and more time actually building stuff since we weren't spread over tens of orders. Over time my little forays also became less and less frequent as well since it became obvious that I was going to bug the crap out of anyone that held up my team for more than 10 minutes. What happened is that the business actually learned how to become more efficient at providing for the team.
How it Applies to Scrum and Software Development:
This was before I had heard of the magic of limiting Work In Progress or Kanban or really any of these, it just seemed like a logical solution for a random problem I had encountered.
The takeaway here is that limiting Work In Progress (WIP) isn't really a secret, it's not complicated and it's certainly not even something you need to take a weekend to learn or read a book on. It's just good old fashioned problem solving applied to a really common problem. While floor space isn't something you have to deal with, integrating 10 features into a product in the last few days of a sprint is.
Limiting Work In Progress works in the same way that Scrum does. You see Scrum doesn't really solve any problems for you and neither does limiting Work In Progress, it just exposes the problem for what it really is which makes it easier to solve. If it's a business area problem, then it's easy to show and prove to the business making the solution easier. If it's a tendency of the team to juggle the entire sprint backlog, then bring in a WIP limit and measuring over a couple sprints might be enough to prove to them the virtues of this new idea.
If your Scrum team can't solve a problem on it's own, then they come to you (the Scrum Master). It's your job to hunt down whomever can unblock the team as quickly as possible and solve that problem. What will your developers do while you're on your manhunt? Partnering up on a single programming task would work great, maybe having a WIP limit of 8 for a team of 7 or a WIP limit of two for each single developer. Use your sprints to experiment here if it seems like something you want to implement.
Just remember to wear comfortable shoes since you'll be walking a bit more than normal for at least a little while.