Exponential Change Or Bust

A friend put forward to another that the rate of technology advancement is increasing and these advancements could well eliminate our demand on high carbon energy. This person in return retorted that these are fairy tales.  I thought about this for quite some time as I do agree that technological change could solve many of the ails that we face in very short order, and I don't think these are fairy tales to be so casually dismissed, but I am more and more worried by what could go wrong.

Humans view the future on a linear line. What happened yesterday will happen tomorrow. However, change is not linear. It is exponential. The combination and multiplication of what happened yesterday will be what happens tomorrow. We humans look straight, change is a curve, an exponential curve, that is in front of us. This is no fairy tale. We could, in very short order, have technology that solves most of our problems.

However. The fairytale could end badly.

Very powerful lobbies, self interest groups, growing protectionism and fundamentalism, concentrations of wealth, lack of progress within our educational institutions, militarization, the massive job losses that technical disruption is causing, financial meltdown which is more or less a given, or a severe technological screw up (which is very likely) could throw all of this change into a sideways or downwards spiral.

We are walking a very thin line right now...

There Is No Room for Buffer With Scrum In Continuous Deployment

Scrum has a concept of buffer points. A percentage of the points that you are expected to ship in the next sprint that you can allocate for unplanned work and outside distractions. If the buffer is used up the sprint is busted and you hit reset. It is a bad thing when this happens. I put forward that this concept is a protection mechanism that gives the team the tools to make it clear why their project isn’t going to be delivered on time. Which makes sense when you are delivering a large project over a long period of time and the deliverables and feedback loops are infrequent and spread out and you are in a non-understanding environment of what it takes to deliver software. However, in a continuous deployment environment where you ship daily or multiples of it each day, the feedback is rapid and often, typically at least once per day, the goal is to learn and react, not block, and as such buffer puts a barrier up that is no longer needed, and quite possibly a distraction and unnecessary overhead. Further, if you are running a zero defect policy, which you absolutely should be, you don’t ever want a reason for your team to not immediately jump on a defect because the “buffer” is used up.

For all of these reasons don’t use buffer with Scrum in continuous deployment. Instead, track the found points percentage increase calculated as the number of points shipped and estimated remaining to ship the epic since the epic began over the original estimated points to ship the epic. If this percentage starts to swing too high then pursue scope negotiation, elimination and delegation of unplanned distractions to other teams. But don’t use buffer in the day to day decisions. It sets up the wrong mindset.

A Scrum Board is a Shop Floor

An efficient and safe shop has nothing on the floor but inventory that is immediately needed and the tools necessary to process it. Anything else gets in the way and slows the process down while increasing the chance of quality problems (stale inventory) and in some circumstances it makes the shop a dangerous place to be. A Scrum Board is absolutely no different. The only work on the board should be work that is actionable. Everything else is clutter. All work on the board has to have true meaning and purpose to what you are delivering, it isn’t a repository for to do lists, or might do someday backlog, all of that is noise. Get it off your board. You won’t be able to see the forest for the trees to manage your Scrum.

How to work on the hard stuff? Delegate.

Delegation is the opportunity for others to learn what you already know well. You give others the chance to learn and grow, especially if you delegate with authority and empowerment. And, by delegating you have the opportunity to move from your comfort zone into the unknow, the really big problems, the big problems that you have been avoiding because you are too busy because you haven’t delegated the work that you should have. You are holding on to the crutch of not delegating which is nothing other than avoidance of the hard stuff, the stuff you could fail on. Or possibly worse, you are doing the work that should be delegated while trying to tackle your next big challenge. You are burning the candle at both ends and approaching the big problems that only you can tackle with no recovery, no fresh perspective, just exhausted doggedness. The end result being that the routine that you know so well isn’t being done as best it should and the new challenges will remain in a frustrated state of never getting anywhere.  Bottom line is that your co workers that want to grow, don’t grow, you don’t grow, and your organization moves nowhere. All because you won’t delegate. What could you work on that makes a difference if you had half or more of your time available for it?

Scrum Means Singular Focus

To produce the best possible solution in the shortest period of time you have to have singular focus on the work at hand. Every time you pull a knowledge worker out of flow and away from their singular task it costs at least 45 minutes for them to return to the level of productivity that they left off at. Every distraction.

Every card in play on the board, is a source of distraction. This includes cards that are sitting in blocked as nothing in blocked remains quiet for long. There are follow-up questions and on-going discussions to try and clear, and then ship the card. Blocked cards are noisy.

There are cards up for pre-validation and there are always clarifying questions to be asked on those cards. More distractions.

There are the cards that are in play with the other members of the team and their questions and pull request peer reviews and in all likelihood if they aren’t working on the same card then the discussions and reviews are different than what the developer in question is working on. More distractions.

And then you have the rest of the company. Support related questions that need to be asked of the developer who created the product. Product Owner questions and epic planning. Quick meetings to review a key point. And then just the general administration questions of expense approvals, and all of the other things that it takes to run a business and support your employees.

From the list above it is pretty easy to hypothesize that there is likely at least 8 distractions or more per day. Assuming that falling out of flow takes 45 minutes to return to it and that non-flow time is slower by many factors than flow time, that means that out of an eight hour day you could be dealing with 6 very unproductive hours. OUCH.

How do you beat this? How do you give your team the ideal creative environment in which to work. A non-interrupt environment.

Make all meetings as short as possible and have them at the start or end of the day. Don’t scatter them across the day.

Never have more than 2 cards in play per team member across the active board, which includes pre-validation and blocked. If you exceed this work in process threshold have the team swarm to clear the cards. Don’t add anything else into the mix until you drop well below your threshold.

And, unless something is escalated don’t interrupt your developers. Queue cards for them in the backlog, give those cards points from your buffer, and if buffer is exceeded try everything possible to push the card out to the next sprint, and let them pick up the card when they close their current work. And ideally have developers on the same team swarm on a card. If four developers are working on the same card you eliminate four distractions. They are all having the same discussions about the same topic and building and contributing to the same outcome.