Friday, April 20, 2018

The world, joyfully shining from a desktop.

Sometimes this world gives me joy.

I take photos as I travel. I also try to take some time to see the world and take extra photos.  One day I realized that I could set my Mac to use random photos for the backgrounds. It seemed natural to create a folder called "backgrounds" on dropbox and use it. Over time I've moved a number of travel photos to that folder.

Today, as I was working I realized that my home office's three screens were showing NYC's Central Park, the view of Edinburgh from Arthur's Seat, and Colorado's Garden of the Gods.  As I was typing this, it changed to three more photos -- the pond in Central Park, a different view of Garden of the Gods, and the beautiful white cliffs of Dover in the UK overlooking the channel.

Through the day, when the backgrounds are not covered up in browser tabs, code editors, terminal windows, and social media apps, I can see my past adventures reflected in beautiful high-def.

I remember how much I love this world's beauty. It even distracts me from some of the ugliness and outrage-provoking I see in the course of my work and social media use.

I have to say to myself, "what a wonderful world" -- and I'm so lucky to have seen so much of it.

It's a dream that a runt of a kid from the Indiana farmlands with no particular skills or talents would have even considered possible. But he didn't know what he was capable of, or where it could take him. Probably still doesn't. But oh, what we've seen. Oh, where we've been.

This brings me joy. I pray it does you as well.

Friday, March 9, 2018

The Impossible Every Day

This is a slightly-edited re-presentation of a thread in Twitter. 

As twitter is ephemeral, and blogs are longer-lasting (and easy to point to in the future), I have copied it here and fixed a couple of typos that twitter wouldn't let me correct.



Once upon a time, people argued that TDD is impossible. You can't write a test first, obviously, because you can't test something that doesn't exist. It's obviously ludicrous.
But you change how you think about "a test" and it works just fine.

Likewise, two people working at one machine? Ludicrous! That's twice the cost! Except that when you realize that programming is more about thinking than typing it makes easy sense. It works just fine.

And mobbing! Why, how stupid must that be!!!! Having five or six people work on one task is horribly wasteful... until you learn that it gets work done quickly by putting the right number of brains and set of skills on the task. It works fine.

And evolutionary design! What kind of an idiot would think you should write code before you have a complete and detailed system design?! Except that you design in refactoring, which is a new way of thinking about design and it works just fine.

Self-organizing? How ludicrous! To think that coders, UX, testing, BAs, ops and other functions can choose their own work and coworkers task by task? Chaos! Except that people do it, and it works just fine.

LEAN STARTUP!? What madness is that? Building features and products and then switching customers and products -- not even knowing what you're building and who for? Except that you change how you think about "customers" and it works just fine and produces some successes (even $M).

NOT WRITING COMPREHENSIVE COMMENTS IN YOUR CODE? NOT FOLLOWING SINGLE-ENTRY, SINGLE-EXIT? Not wise. Except that it works just fine if you change how you write your code.

Running interpreted languages in production!? That will NEVER perform AT ALL!!! In VIRTUAL MACHINES!? That's moronic. Except that it works extremely well. It happens every day. It's fine.
Releasing monthly? No? WEEKLY? No way! No? DAILY!? That's going to be nothing but disaster. Except that orgs release hundreds of times per day, and if you change how you build and deliver, it works just fine.

Working without PROJECTS? That's surely mad. Except that product orgs do this all the time, no projects, no funding-by-project, no staffing-by-project; surely there will be no accountability!? Except it works just fine all over the world.

Letting customers see work that hasn't been finished and released yet?! Surely this is suicide! They'll be disappointed and angry, and will not work with us! Except that this kind of feedback loop is commonplace now, and it works just fine.

Working without BRANCHES? All the people mixing their code together all the time? It just makes sense that this will be a mess! Things will be constantly broken! Nobody will ever be able to release.  Except that people (in surprising numbers) are doing Trunk-Based Development and guess what? It works just fine. You have to change your thinking and process a bit, but it's okay.

Working without estimating all the work in advance and making promises and plans and budgets based on the estimates? Impossible! Except that people think differently about budgets and estimates and plans, and it seems to work just fine.

Nearly everything that vintage 1985 otter would have thought madness, foolishness, and impossibility has become not only possible but commonplace.

When people work together, nothing is beyond them.

You have to ask, what impossible thing is going to be done next?

I think we have to check our incredulity at the door.

As we used to think, none of this could have happened. We change how we think, and new vistas open up.

Who knows what is next?

Monday, March 5, 2018

Predictability as Maturity or System?

The predictability of a team is subject to the predictability of the work.

Duration of a task depends on three things primarily:
  1. Raw effort -- fairly predictable, measurable, repeatable -- easy stuff.
  2. Risk -- chance we might break something and have rework or damage; VERY hard to predict in advance of efforts, extremely hard to detect without significant effort in automated testing AND exploratory testing. This can bring us late delays that cannot be ignored. 
  3. Uncertainty -- the amount and difficulty of the learning we will do, along with the chance that we may hit dead ends and have to start over. Cursedly hard to predict even order of magnitude.

Interesting and Uninteresting Work


Work that is mostly raw effort is uninteresting. Nothing is learned there, nothing is innovated, nothing taxes or stretches the workers. It's mostly just typing. It is the vast minority of software work, because developers have a tendency to automate any uninteresting work. Not only does it save them a lot of time and tedium, but automating that work becomes interesting.

Work that involves risk and uncertainty is interesting work. It requires active minds and research and study. Easily 90% of all software work is interesting work. 

When you ask developers what they want to do, they will almost always tell you that they want to do interesting work. They want to take on hard problems and work them to completion, preferably with a minimum of distraction since risk and uncertainty will require their full attention. 

Developers will also talk about safety to innovate and try things that might fail. Again, these are natural parts of doing interesting work.

Maturity?


Phrasing the ability of a team to estimate accurately as "maturity" is unhelpful.  The likelihood is the opposite. You give more mature and skillful teams more interesting work, and thereby less predictable work. It's the immature teams that churn out identically-sized bits of raw effort per week and who may be able to put in extra hours without degrading the quality of the result. After all, you give them the uninteresting work.

If the work has high uncertainty and high risk, then the team could be composed of genius-dripping consummate professionals and the estimates will not be consistent.  

Consistency?


Organizations often expect teams to have consistent velocity and consistency in their SAY:DO ratio regarding estimates. That plays well with the idea of developers (coders, testers, ops, etc) as unskilled laborers in a simple or possibly complicated system.

If the work is interesting, and some work is more interesting than other work. As such, the velocities and estimates will be different among different teams because different teams do different work. We should respect this as natural variation, not condemn and eliminate it as special variation.

But, We Need Accurate Estimates!


You probably do. It is possible, even likely, that you've built a system of work around the idea that software is primarily typing, that developers are unskilled laborers, and that work is generally simple and occasionally complicated, but that the only real risk and uncertainty are in relation to the calendar. 

Do you need to need accurate estimates? Maybe you do. In that case, don't take on interesting work. Do only predictable things that have been done many times before, in a tried-and-true technology, for customers you understand very well. Don't complain about a lack of modernization, automation, innovation, or what-have-you. Keep it dull. You will probably lose some developers who like interesting work, but maybe you'll maintain a staff base of people who like trading n-hours-per-week for a paycheck, and those are the predictable ones anyway. 

But maybe you don't really need accurate estimates. Maybe you can learn to either do your work as an ongoing evolution of a software product using fixed staff and flexible scope. Maybe you can use story mapping and exception mapping and other story-splitting techniques to manage risk. Maybe you can have developers learn TDD and BDD and automated testing along with manual testing and coding. Maybe you can provide scheduled room for experimentation and dead-end mitigation. 

Possibly you don't need estimates at all but haven't considered what a different system it would have to be in order to stop relying on estimates. That's a topic for another day, but maybe you could do a bit of research into other ways of working.

If you are going to do interesting work, though, you can't insist on accurate estimates. You'll have to tune your process to allow for risks other than date-and-content risks by adding slack, testing, and support.

Either way, you probably want to make sure you invest in refactoring, so simple things don't become risky and thereby unpredictable. 

Your code should always be as easily-workable as easily-fixable as possible. That still counts.

The Inevitable

If the work is unpredictable, as evidenced by our history of poor estimation, then perhaps the lesson is that inaccuracy of estimates is not a case of maturity or insufficient effort.

If estimates have always been inaccurate, we have to accept that estimation error is (to us) inevitable.

If organizations all across the industry are also bemoaning poor estimates, then it's probably not just us.

So we treat it as normal and inevitable and keep looking for someone to come up with a better way.

It's how we've survived storms and market trends and other unpredictable elements for centuries; we accept it and allow for it.

If one or two "bad" estimates (ie estimates that turn out to not match actuals) will ruin a business plan and bad estimates are inevitable, then the business plan is fragile. If we can't have better estimates, we'll need more robust plans.


Wednesday, January 31, 2018

A little signal-to-noise



WARNING: the blogger "WYSIWYG" editor is really not very good about the "WYSIWYG" bit... so this article looks great in the editor but is a real crapshow in the actual post. I'm fixing it. Be kind, and bear with me.

In our eLearning, we publish problems and solutions. Sometimes people contribute other solutions and we show those as well. Today's sample comes from our Test-Driven Development album.

Album Art for Test-Driven Development



Geepaw hill tells us "everything matters" -- so today I'm going to nitpick at something that (in this case) is tiny and you might consider it insignificant. So be it.

But just the same, I would like to introduce you to a process that can improve your code and design in ways subtle and profound.

In this case, it stays a little to the subtle side, but that's okay for a blog.

Here is a source code example:

AreEqualWithPrecision(PhoneBill.calculateRate(PhoneBill.GOLD, 900, 1), 49.95); AreEqualWithPrecision(PhoneBill.calculateRate(PhoneBill.GOLD, 900, 2), 64.45); AreEqualWithPrecision(PhoneBill.calculateRate(PhoneBill.SILVER, 490, 1), 29.95);
AreEqualWithPrecision(PhoneBill.calculateRate(PhoneBill.SILVER, 490, 3), 72.95);



This test is checking a hypothetical phone billing calculation.

Let's look at these lines and figure out how much unique content exists per line.

De-Noise-Ify



Duplicated:
AreEqualWithPrecision(PhoneBill.calculateRate(PhoneBill.


56 characters of every line are duplicated. You probably didn't even read them after the first time.

Unique:
GOLD, 900, 1), 49.95);
GOLD, 900, 2), 64.45);
SILVER, 490, 1), 29.95);
SILVER, 490, 3), 72.95);




About 25 characters are not the duplicated prefix.

Of these, even fewer are unique (if you drop punctuation).

With 2/3 of every line being noise, it's pretty obvious that this code is inviting you to copy and paste. Heck, it's practically demanding it.

How many times would you want to type those first 56 characters (plus indentation)?

Most of the time when people copy and paste, it's because the code asks them to do that.

I'm willing to wager a pleasant adult beverage that the four-line test was written by copying the first line three times.

If we were to get minimal noise, it might look like this:

SILVER 490 3 72.95


Now we've got it to four points of data, and that's pretty noiseless. Do you know what it means?

Nope. I didn't think so.

This has all the noise removed, but also all the information.


If you have near-zero signal, then having little noise doesn't help.


But if you have little signal, having a lot of noise doesn't make it any better either.


Find Significance





There is a violation of the fidelity rule here. The fidelity rule tells us this:
One reads the tests to understand the code. One does not read the code to understand what the test does.

The first three numbers describe facts about a simple phone bill.

public static double calculateRate(int plan, int minutes, int numLines)


The other is the expected amount of the calculation (here done in decimal because it's just a teaching example).

So when the plan is type=SILVER, and billing is for 3 lines and 490 minutes of use, the expected result is $72.95.

Now the question is how to phrase this. We are a little stymied because there are two different kinds of plans being tested here for two different conditions each. We're not going to come up with a test name that reflects that because it's a number of different ideas.

Maybe the tests are too big.

We could divide the tests into GOLD tests and SILVER tests. We could make four different tests.

This seems like a good idea since test naming is a classic way of making code make sense.

When we look at the code we see that the algorithm is the same regardless of plan. Only some numerical values change per plan. That's interesting.


Exalt the Significant



Possibly we could rework the code a bit. I'm going to take some liberties and not actually build and run this, but just examine some different organization.

var baseRate = 29.95;
var included=500;
var extraMinutesRate=0.54;
var extraLines=21.50;
var baseRate = 29.95;
var included=500;
var extraMinutesRate=0.54;
var extraLines=21.50;


var silver = new Plan(baseRate, extraLines, quota, extraMin);
assertEqual(72.95, silver.calculate(lines=3, minutes=490));


There is more to this, though.

  • The significance of 490 minutes is merely that it is less than 500.
  • The significance of 3 is that it's two more lines than the 1 included in the plan.
In this test, the extraMinutesRate is insignificant. It's a shame we have to provide it.

I'm not even going to talk about the primitive obsession, using floats for money, or any of the other obvious issues here.

Especially not having small classes for minutes, and for money, and type-safe function parameters to keep us from shooting ourselves in the foot via mishandling of variables.

Far be it from me to mention that. This is, after all, a training exercise.


Avoid Duplication



Now we're getting closer to something that can be understood from the test. The signal is increased considerably. That's a good thing. Sadly, these numbers are going to be all over the tests and duplicated in the production code.

That violates the Single Point Of Truth (SPOT) principle, and also damages our signal-to-noise ratio.

Now we'll have numbers all over the place duplicating numbers in other places, and we'll have to be careful to ensure that they all agree when they should.

Maybe what we need now is to create a record type to hold the variables for different rates. Let's call them GOLD_RATE_PACKAGE and SILVER_RATE_PACKAGE for now.


var silver = new Plan(SILVER_RATE_PACKAGE);
var underQuota = SILVER_RATE_PACKAGE.minutes_quota - 1;
AssertEqual( 29.95, silver.calculate(minutes=underQuota, lines=1));
AssertEqual( 72.95, silver.calculate(minutes=underQuota, lines=3));


This could be taken further, but consider this example v. the original.

AreEqualWithPrecision(PhoneBill.calculateRate(PhoneBill.SILVER, 490, 1), 29.95);
AreEqualWithPrecision(PhoneBill.calculateRate(PhoneBill.SILVER, 490, 3), 72.95);




On one hand, they are almost exactly the same. On the other hand, there is a huge difference in the signal-to-noise ratio and the places one has to look to research why the first answer should be 29.95.


So Friggin What?


The point of this is not "my code is better than yours" or "I'm cooler than you" (which is almost certainly false).

What I'm suggesting is that there are subtle-but-different changes even in simple code if we consider the signal-to-noise ratio in our code.
  • De-Noise-ify
  • Find and Exalt the Significant 
  • Avoid Duplication 

As a result, you end up with code that is more obvious at a glance and likely has a better design as well.

This matters to me because I care about the code rather deeply.

Maybe you don't like it as well as the original.

That's okay, but what do you come up with when you follow the same process?

Thursday, January 25, 2018

How To Be Miserable (or Not)

I came across an interesting article the other day, stating:

EXPECTATION – OBSERVATION = FRUSTRATION

I think this is really good.

However, I think there should be more emphasis on spoken v. unspoken expectations, and then on agreements instead of expectations. 

Also, the refusal to adjust expectations out of compassion and respect for others is poison.


And yet, people are quick to judge the behavior of others rather than to approach surprises with curiosity. A lot of disappointments don't need to be upsets.  People judging situations scream "this is wrong" instead of "how fascinating!"

We refer to the difference between expectations and actual behaviors as a "curiosity space." It is where most of our learning takes place. One of my friends described it as a "cache miss" which is helpful to readers who are engineers or software developers (or both). 

So, here, to help us understand, is my quick guide to being deeply miserable:

  • Expect that others will tend to your needs and desires ("be true friends").
  • Expect that you will not need to tend to theirs ("put up with their drama").
  • Refuse to change your expectations ("lower my standards.")
  • Constantly inspect others' behavior to see if they fall short of your expectations.
  • Don't tell others what you're expecting from them ("they should know.")
  • Consider it an act of betrayal when others fail to meet your unspoken expectations.

Learning to negotiate and share expectations, and also to adjust them out of respect for others, is key.

If you look at this recipe for unhappiness (and the attached formula for frustration) then you can probably understand where a lot of misery and suffering come from. Then you can decide if this is a recipe you want to follow, or whether you'd like to try something else.

It's your choice. 

Monday, December 11, 2017

Feeling Safe?

I finally got around to watching Frozen.

I don't have any small children of my own and wasn't really interested in it for my own viewing pleasure, so it took a long time. I didn't know the songs, didn't know the characters, didn't know the storyline.

We were watching a friends' child last weekend, and the child really wanted to see Frozen, so we did.

Overall, it's cute and has nice jokes and beautiful animation. I can tell they spent a lot of money on the soundtrack. I probably won't watch it again, being well outside of the target audience.

There was one poignant moment that stood out to me, though.  Anna, the red-headed sister of magical-powered Elsa, came to retrieve her (very dangerous) sister and bring her back to their town.

Elsa warned Anna that she was a danger to everyone. Anna said:
You don't have to protect me; I'm not afraid. 

Boom. That line.


Feeling v. Being


It dawned on me that Anna thinks that feeling unsafe is the thing; actually being unsafe doesn't occur to her.

She's focused on the feeling instead of the reality.

When we say "make safety a prerequisite", people think we mean "feeling safe and unthreatened" which is not what I mean.


  • Fragile people can remain fragile in a confrontation-free space, but this doesn't make them safer.
  • Hiding problems can keep people from feeling afraid, but transparency gives them the ability to solve problems.
  • Brutish people can "feel safer" when they're allowed to run roughshod over others, but this does not make the group safer. 
There is more to this than feelings.

Likewise, when we say "make people awesome," some people think we mean "make people feel really great" instead of "give people the ability to do great things."  I mean the latter. If I meant "make people feel great" I would say "make people feel awesome" and would not bother with actually creating any enablement. Feelings matter, but there is more to this than feelings.

What Timing!


As I was pondering Anna's "not needing protection" Elsa deals Anna a mortal blow which begins to freeze her heart, and in time may well kill her.

So much for not needing protection.

Eventually, Anna is frozen solid, essentially dead. This being a Disney movie, she's restored to normal state and all is well at the end.

I wish it were the same for people who "feel safe" weaving through traffic on a motorcycle at 120mph with no helmet, or those who "feel safe" working with homemade explosives or modified firearms.

What Are We Really Doing?


The ideas of "make people awesome" and "make safety a prerequisite" are too important to me to have them confused and conflated with imparting (potentially deceptive) feelings of awesomeness and safety.

If we aren't enabling greater accomplishment and reducing potential damage, then what are we doing? Just playing with people's feelings? 

Monday, November 27, 2017

Taking Breaks in a Disciplined Way

I worked with a team where everyone was trying to do pair-programming, but it was too hard for them.

I asked what made it so hard, and they told me it was simply so exhausting. They were slumping in their seats by 10:30 in the morning, and by mid-afternoon, their productivity had plummeted.

I looked around the room to see if everyone had the same experience. They all nodded their heads. This was the big problem that was plaguing them.

I asked them how they were doing the pairing. They were forming up in pairs, and working all morning straight through without break. They went to lunch, and after lunch rejoined their partner and worked until quitting time.

They really were sticking with the pairing, and I had to admire their dedication. They were working so hard to try to build great software and working so hard at pairing that I was deeply touched.
But here is the problem, too.  They were working too hard at it to be able to do it well.

Biological Beings



We are biological beings. We're neither machines nor creatures of pure will and thought. We have human bodies housing human brains, and there are biological needs beyond mere nutrition, respiration, and elimination.

Thomas Davenport described "knowledge workers" as a people who "primarily rely on their brains rather than their bodies in [doing] their jobs."  Developers, testers, managers, service, support, finance, sales ... most people in the software trade are knowledge workers by this definition.

We, as a species, have uniquely large brains. It's said that 20% of our daily calories are burned in the brain, not in the muscles or other organs. That's one expensive organ.  Knowledge workers tax that organ more than most laborers.

That organ is biological, not mechanical. We can either try to work with the biology of that organ, or we can be subject to the weaknesses and frailty of the organ itself.

We have decades of people working hard to improve focus and extend the time that one can focus. We know that distractions are annoying and disrupt our train of thought. We are aware of the costs of multitasking, and especially of processing low-value interrupts (such as most notifications from social media and a lot of our low-business-value conversations). We have learned to hyper-focus on one topic for extended periods.

As reasonable as this sounds,  a number of recent studies have concluded (as Graham Wallas hypothesized in 1926) that a brain works better if it has some distracted time so that it may "incubate" ideas while doing other things.

Srini Pillay said in May 2017's issue of Harvard Business Review that a brain can take only so much focus. Excessive focus, he says, exhausts the focus circuits in your brain, draining your energy, making you more impulsive and less helpful.  His article states that the brain operates best when it toggles between focus and unfocus (which I call "the prairie dog brain").


Prairie dogs poke their heads up out of their dens from time to time to check for predators or opportunities in their environment. They don't stay buried all day long.

My Prairie Dog Brain likes to (figuratively) pop its head up and sniff the air for interesting opportunities or threats in the environment. Rather than being hyperfocused all day, I need to seek the occasional distraction in order to do my best work.

In his book Tinker, Dabble, Doodle, Try, Pillay relates the story of one of his hospital supervisors telling him that "taking breaks to allow thought to congeal is one of the most important aspects of a true education."

The Water Analogy


Consider, as an analogy, hydration on a long-distance hike.

You will naturally lose water to breathing, perspiration, etc. You will run low on water if you don't replenish.

When you are dehydrated, your performance will suffer and your being may take damage. In severe cases, your body may fail entirely.

It is recommended that you drink water to avoid dehydration (and alternate with sports drinks to avoid hyponatremia) on your trip.

Some sources recommend a cup of water every 15 minutes if you're on an endurance walk.

That is considerably more than if you're sitting at home watching TV.

When you are working with your brain all day long, you are doing some "endurance thinking."

The brain has a "normal" attention span of about 20 minutes, and yet people struggle to keep it focused on the work at hand for hours.

Just as a hiker needs to drink water frequently, you will need to refresh your brain periodically.

Rather than taking breaks because we are tired, we take breaks so that we do not become tired.

If we allow ourselves to become tired, then we will need longer breaks to recover, and will work less well before and after the breaks.
Just as you might have to drink when not thirsty, you will need to take a break when not exhausted.

Disciplined Break Taking emerges



A past mentor of mine was famous for an interesting trick: when teaching a week-long event, he gave the class a ten-minute break every hour.  The team was able to work on their individual projects and assimilate new ideas much faster.

This worked nicely and had a good rhythm to it.

Around this time, I also read an article by John Richardson on "The Power of 48 Minutes" in which Don Crowther claimed that he could achieve and sustain a state of flow more quickly and predictably if he worked 48 minutes without distraction, and then took an (obscenely long) 12-minute break. Since then he has reduced his break to 10 minutes.

... 48 minutes is the magic number. Here’s how it works… Set a timer for 48 minutes. Close out all distractions and work continuously for 48 minutes. When the timer goes off, get up and stretch, get coffee, use the restroom, etc, in the following 12 minutes. Repeat as necessary.

Around the same time period, the Pomodoro Technique emerged and became popular. In the Pomodoro method, you work for 25 minutes and take a 5-minute break, which lands you at about 50 minutes of work per hour.

 
The Pomodoro technique is named for a tomato-shaped timer used by Francesco Cirillo when he formed the original concept.

The Pomodoro technique has been fine-tuned since the late 1980s and is a popular and widely respected way to maximize productivity.

This seems to be a pattern to the 50-minute hour.


The story continues (and concludes)



The team I spoke of at the top of the blog post were exhausted every day, for most of the day.

I didn't have Disciplined Breaks worked out then, but I knew about Pomodoros. I set up a timer, and we used 25/5 "standard" Pomodoros.

Success! The team completed the work planned for a full day before noon. Pretty impressive! We had 100% increase in productivity immediately.

By mid-morning one of the team members had mentioned that they weren't tired and didn't need a break. At that point, we reminded them that we don't take breaks because we are tired, we take breaks so that we are never tired.

The team member took the break, as we all did.

By mid-afternoon, the team had accomplished the following day's work.  They had completed two days' work in 75% of one day! I realized that exhaustion was the team's biggest problem (as they assured me it was in the morning coaching session).  I felt elated.

However, part-way through the next break, a manager addressed the team and said "are you all goofing off again? Already?"

The team's enthusiasm drained out of them. Their eyes went to the floor. They ducked their heads and mumbled, "I'm not going to take this break, I'll just work through it."

To the best of my knowledge, that team never again took a break during their workday. They may never have had a boost in productivity like that again.  I hope that they eventually negotiated a break-taking schedule with their managers. I just don't know.

If you are coaching or managing a team, then you probably should repeat my success and avoid my failure.

I've since had many successes with other teams. I have learned my lesson and work more closely with the team managers when possible.

Rules of Disciplined Break-Taking



Break taking is not a very complicated idea, but in order to fit it into a business context, we find that we need to surround it with some very special rules.

There is a perception problem with breaks. Managers can see people not working, fear for lost productivity, and demand that they return to work. From the information given so far in this blog post and your personal history, you can see that breaks will increase productivity if they are done correctly and the managers will allow it.

In order to make this a safe experiment for others to try, I added some rules and have tuned them for about a year. Disciplined Breaks is the best set of rules I've used personally and have shared with teams.

Work out the experiment with the team's boss if necessary. If not, then please freely take and use these rules. Expand them for your own context, or simply use the Pomodoro Technique.

Disciplined break-taking is, as I've defined it so far:




  1. Schedule it.
    If you don't schedule the break, you'll not notice it's time and you'll skip it.
    You'll end up tired and will need a longer break to recover. 
  2. Leave the area
    Don't stay seated in front of your computer. Get out of the cubicle, the room, the space you're working in. Move. If you stay, you won't really take a break.
  3. Attend to Biology
    Yes, this includes the obvious reason people often take breaks, but also consider getting a drink of water or a healthy snack. Keep your biology in a brain-supporting state. 
  4. Change Something
    Change your focal length (look out a window), change the atmosphere (go outside), change your state of mind (rest, meditate), change company (call home). Do something non-work like so that you can tolerate being away for 10 minutes.
  5. Return Promptly
    The major reason managers fear letting teams take breaks is that once you let people go, you don't know how soon you can get them back. Whether using Disciplined Breaks (this method) or Pomodoro, or any other method you will need to be trustworthy and not leave your work for "too long."
    I recommend setting a timer on your phone or smart watch for 8 minutes so it will remind you to come back on time.

There are immediate and significant gains possible through disciplined break taking.

Please give it a one-week or a one-sprint try. You will be surprised how well you can perform when you are working with biology, and not against it.

After all, we're not machines.