Friday, October 4, 2019

Disciplined Breaks, Two Years On

I described Disciplined Breaks here in 2017.

Sometimes people ask me how that's working.

I wish my answer was more confident and assertive, but what I can say is "it works great when we do it."

I use Disciplined Breaks in all of my training and coaching engagements, and often in conference talks. It works. 100% of the time it works. It works so well that people feel like they're cheating. They feel guilty for not being tired.

When I'm not there to enforce it, the teams practice it sporadically at best. When they work solo, few of them ever continue it (even though it works 100% of the time).  Worse, when I work solo, I also sometimes "forget" to do it. Yes, even though it works all the time.

We are talking about human beings and their sense of sufficiency and power and their work ethic and competitive, go-getter training.
Disciplined Breaks is a behavioral skill, and all behavioral skills (especially formal disciplines) are hard.
We are better at this when it's a special circumstance, an event like training or coaching or mob programming for a week. We're better when we support and remind each other. We're better when it's clearly expected of us. We're better at it when someone in charge expects it of us.

Lacking some external drivers we tend to be inconsistent -- not just students, but coaches and me individually.


Here are some patterns we see:

This is typical non-break-taking behavior. People feel that they have to be nose-at-the-grindstone at all times so they take no breaks and grind through the work all day long. Because they're lacking the energy to do their best work, they have to stay at it even longer to get similar results. 

As often as not, they make mistakes. When they go home and have some sleep they are refreshed and they realize what they should have done 4 hours into the day yesterday; which they couldn't see at the time. And they discover the mistakes they made, and fix those. 

They don't take breaks again (nose at the grindstone!) so they're tired by the time they've finished fixing yesterday so they'll have to work twice as long and hard to get their work done today. Maybe they'll do overtime.

When I follow this pattern I can tell how slow and depleted I am by 3pm. I'm aware of being unproductive and "slow" fairly early in the day. I can't concentrate. I'm antsy and have low impulse control. I'm easily distracted. I forget to keep track of my work, my learning, and the time of day even. I'm sort of lost and adrift and trying to force myself to be so.

Why do I even do it? I think it makes no sense to totally break discipline like that. And yet here we are. I have those bad days. I used to have nothing but.

So here is an intermediary pattern:



Here someone takes breaks in the morning or into the afternoon and they are surprised to realize that the breaks work and they're still energized at 2pm!! Since they still have energy, they reason, they don't really need a break so they skip it.

As a result, the energy level that was created by taking breaks is destroyed by not taking breaks, and the work becomes less energized. Now a break is needed for recovery.

We shouldn't need recovery breaks. We take breaks to avoid being tired, not to recover from it.  

But once we're tired, we'll need a bigger break to recover. This is the trap that most people fall into: you end up taking breaks in arrears -- only once you're depleted. But you have to ask yourself, why ever be depleted? What virtue is there in being tired and grumpy and slow-thinking at work?

I guess it's human nature. We would rather skip prevention, and then if we get sick we can have it cured. After all, we might not get all that sick, and maybe we can avoid both cure and prevention by just not succumbing to illness. Which is poppycock, of course. Human beings need maintenance -- either preventative or curative. But one of those is plannable and predictable and manageable. It's just hard to get past "I'll just push on, I'm sure I'll be fine. Or if I'm not fine, I won't whine about it."

Of course, when traveling and consulting "I can rest when I get home" is the thought. But that means we'll focus on work and ignore homelife. Not healthy either. I should come home in condition to participate as a family member, husband, friend, neighbor. So that's also silly once we examine it.

I usually get this pattern "rest when tired" pattern after I've fallen into the pattern of working without breaks for a little while.  Returning to Disciplined Breaks requires me to shift my mindset back to taking breaks in advance of work as a preventative measure. Before I shift back to prevention, I mistake my energized state as one that doesn't need rest, rather than one that comes from having rest. An easy mistake to make. Being human is weird.

This is clearly the better pattern:



Again, back on schedule. We take the breaks so we're energized all day long. We don't skip breaks because we realize that they are to maintain the energy level. We don't need to be tired to take an energy-maintaining break, so we stay full of energy all day long. And the next day. And the next.

Maybe not on the weekend. Maybe I'll just rest when tired. Or maybe not on vacation, because there's so much to see. Oh, wait. That's the all-red pattern creeping back in. Darn it. Humanity is a tough skill.

When I stick with the last (all blue) one, I am energized all day. I have good interactions, and I tend to do good work. I even end the day with a list of things I learned and new insights about working.

When I don't, I don't.



Thursday, September 26, 2019

The Coward's Confrontation: Leadership fail

I want to introduce you all to a term:

Cowards' Confrontation: a rule made in order to avoid having an uncomfortable conversation with an individual, which rule is either selectively relevant or selectively reinforced (or both).

So, for instance, a 15-person team exists of which only two people ever eat at their desks. One has a cold sandwich and carrot sticks, but the other brings tuna and shrimp freshly heated from the cafeteria's microwave oven.  The team has been bothered by the fragrance of the daily seafood and the residue left in the trash can.

The team (or a manager at the team's request) makes a rule that there will be no eating in the workspace.

Our sandwich-eater ignores the policy with impunity. After all, this person knows that the policy was about smelly seafood and doesn't apply to them. Nobody, team member or manager, says anything.

The seafood-eater notices the sandwich-eater's scofflaw behavior and returns to their desk with food one day. They are confronted with "you can't eat here; you know the policy."  This is upsetting because sandwich-eater has been eating at their desk. The seafood-eater now feels singled out.

BECAUSE THEY ARE.

"We're sorry," say the other team members, "if it were up to us it would be fine, but you know the rule."

This is the Cowards' Confrontation. Selectively-made, selective-enforced policies that allow people who are afraid of a confrontation to control the behavior of another without actually admitting to being upset or asking them to change.



When you are making team agreements or rules, beware. Don't be the coward cowering behind the Cowards' Confrontation.

Monday, September 23, 2019

Is It My Fault You Can't Handle The Truth?

Image result for you can't handle the truth image


In the past year, I was introduced to the idea of hyper-rationality. I think it was under another name (to be given shortly) and as part of a presentation by George Dinwiddie on, of all things, estimation.
It was a funny place to be introduced to ideas from psychology and family therapy, as well as organizational psychology and collaboration, but there it is.

It is nice to be smart.

It's extra-nice to be right. It is wonderfully nice to be right, smart, rational, and helpful to others.

Sometimes we put too much emphasis on being right, and sometimes we can be right in the wrong way.

Hyper-rationality is a state of being excessively or inordinately rational. It is a belief in rational truth as an unassailable fortress, that being correct is all that matters.

For instance, the feeling that if I am right or I am telling the truth that you have no right to be offended or upset.

When people are acting hyper-rationally, they often expect to be respected and appreciated for having the superior argument, the more data-backed answer, the provable theory. But this seldom happens.

I'm not going to explore any kind of moral, rational, logical relativism here. That's a different topic. I'm not suggesting that whether gravity or physics or hexagonal architecture are "true" are a matter of personal opinion. I'm not even playing with the idea of "personal realities" here.

The fact is that being actually, provably, data-based, research-backed, iron-clad RIGHT is sometimes not the most important thing.

"If the truth bothers you," one may say, "then you are overreacting or overly sensitive." This is a declaration of irresponsibility. It is the hyper-rational way of saying "I am not accountable for any damage, upset, or embarrassment I may cause."



Not Responsible For Broken Windshield

It reminds me of the bumper stickers on trucks saying that vehicles must stay back at least 200 feet because the driver is not responsible for damage done to other vehicles by falling rocks.  It's nonsense of course. The sign on the truck does not let the company off the hook.

The sign tells others "I am irresponsible. Whatever damage I do to you is your problem."

While I might suggest that moving several tons of gravel across rough public roads (especially over railroad tracks) is indeed a circumstance requiring special care, perhaps developing better ways of hauling dirt and stone might be more helpful than declaring irresponsibility.

Sometimes we crave the irresponsibility of Being Right.

Virginia Satir talks to us about being congruent and reminds us how our communication has different layers of meaning.




Even if my words are accurate, rational, and true, the way I deliver them may color that truth with an entirely different message.

Sometimes that message delivered with our "truth" is "screw you, I don't care what you think." That message is never helpful.

There is the term that Satir used, and which I hinted would be revealed. That term is "super-reasonable."

This is described by Andrew Fogg as:
A super-reasonable person discounts himself and others and respects context only. He frequently knows lots of information and works solely from a logical or objective perspective. He says to himself things like “Everything is just a matter of logic, emotions are a waste of time” and “I must be more intelligent and show how intelligent I am.” Physiologically this stance is rather dry! The super reasonable person only respects the context, while disrespecting themselves and others.
This is explained well in an article at Satir Workshops, using a simple three-part circle diagram ask a key.

The three chunks are Self, Other, and Context.

The same icon/diagram is used in this lovely sketch describing coherence and imbalance, which is from the 1972 edition of Virginia Satir's book Peoplemaking (original by Barry Ives, modified by Charles Lambdin to work better in this blog):


Image


Here you see people discounting the needs of the self, then the other, then both the self and the other, then all of the above. Finally, you see the Leveler who is considering all of these aspects and is likely to be successful in collaborations.

Super-reasonability ignores the humanity of an interaction, assuming that facts and intelligence are all that is needed to make it all work out.

Often when "objective truth" is presented in a conversation, it is given as a reason to NOT do things one is requested to do, or a reason that other people should do as they are told by the truth-teller.

In this case, it is a power move.
It is a trump card.
It is closer to "blaming" than to "super-reasonable" in such a case.

If the message is "screw you, I'm right" then likely you're not offending people with the truth but by demeaning or one-upping them.

All people in positions of power (bosses, managers, consultants, public speakers, recognized experts) need to be careful. When you find yourself in this position, it's time to pause and think more deeply; being right is not enough.

The truth-teller in this circumstance has been met with a request or a need, and rather than attending to the need or aligning with the person who has come asking, the truth-teller is instead asserting dominance/superiority and shutting down the conversation.

Why would anyone not take offense at that?

"I'm just telling the truth" is a mask frequently worn by callous self-centeredness.

Ouch.

That describes a great number of bad interactions I've had in the past. Having worked so hard to learn many things, I felt it important to deliver my well-studied truths -- more important than to care for the needs and ambitions and goals of the people around me.

I said some things not only because I thought they were true at the time (and may have been), but because they gave me a shield from the upset of the others -- my own "stay back 200 ft" sign; my own "get out of responsibility free" card.

As Michael Mendis described it:
"we flee from what we fear, so it can be concluded that hyper-rationalists fear their irrationality and seek to escape from it by taking refuge in an excessive and exaggerated devotion to 'reason.'"
Sometimes we try Being Right to protect ourselves from our own irrationality, from engaging with other people's needs, and so that we can avoid dealing with the emotional and irrational side of other human beings (a side just as scary in them as in ourselves).

But it's still there.

Data doesn't make us less human. It should be used in service to humanity rather than as an escape.

If we have an objective, context-free, helpful truth then why can't it be offered in a way that respects and honors other people?

Why must it be a conversation stopper/winner, rather than incorporated into the context of the interaction that is focused on meeting the goals of all the people involved?  Why can't it be helpful rather than off-putting?

Truth does not have to be delivered bluntly and brutally.
There is a tradition of "speak the truth in love" to consider.


A better example of helpful truth-giving is from Randall Monroe (AKA xkcd):




When you think that others are being hyper-sensitive, perhaps it's a good time to consider whether you are being super-reasonable.

Some questions to consider:

  • Are you hiding behind rationality? 
  • Are you discounting your place and the other person's place in the interaction? 
  • Are you trying to take a shortcut that is not helpful to your collaborators? 
  • Is it important to you to "win" the conversation?
  • Are you using rationality to escape responsibility?



Monday, September 2, 2019

Q and A on Velocity, part X


In the last installment we talked about communication between managers and employees, efficiency notions, and other key continuous improvement ideas.

This installment let's pick up on the idea of doing great work quickly.


A: You have said several times that something has to change for work to be done faster. Skills and stuff to make the work easier. Is that the right way?
B: If and only if the bottleneck is actually in development, it will help.

There is some good material here from A. In fact, skills and tools and knowledge can make the work progress faster. A developer with deep knowledge of their tools and stack can get work done in a tiny fraction of the time it takes a less knowledgable developer to figure out how to get a result.

This is often misinterpreted as "a 10x developer" but really it's a 1x developer surrounded by other 1x people who just don't know the stack, the code base, or the tools as well. If you like a 10x devs, invest in helping them learn to go faster. This is expressed in Modern Agile as "Make People Awesome", and in the Agile Manifesto as "give them the environment and support they need."

But let's move on...

A: Okay, then. Let's assume the bottleneck is development. What do we change?
B: Whatever makes it difficult or risky to delivery working code now.
A: How do we know what that is, or what to do instead?
B: Experiment. Some changes help, some not.

Since I've started this blog series, I have had a series of workshops where I ask the team "what makes you go slow?" It really isn't a difficult question to ask. In the right (blameless) environment, teams are happy to tell you where the problems are.

Most of the time, teams don't know how to fix the problems, or they don't know how to acquire the time and support they need (see Agile Manifesto principles, again) to solve the problem so that they can go fast. Here a manager can make a real difference.

Supporting experiments and other efforts to relieve bottlenecks isn't just good agile practice, or good empiricism, or good Modern Agile ("experiment and learn rapidly"), it's good management and good business. Leaving people stuck with drag-inducing problems while exhorting them to move faster isn't good form. Better to be effective, right?


A: We can't afford to do that. I told you our schedule is tight. Can we only do things that work and not waste time?
B: If you can't afford to experiment & learn, you can't improve. Do the best you can with the velocity you have. Order work by value. Descope.

If we can't afford to learn and experiment, then we can't afford to go faster. Full stop.

Is it okay to be seen learning and trying things at work? What happens if you try something and it doesn't work? How does that line up on the annual review?

We hope an experimental and informative, mindful approach to software development is seen as a positive by the organization. It has happened, though, that speed is rewarded and knowledge is rewarded, but no concession is made to the acquisition of speed and knowledge. This makes retaining motivated people very difficult.


A: We can't descope. We can't miss the date. We can't experiment. What else do you have?
B: Fail as well as you can. Give the best result you possibly can, considering that you'll fail.

We have referred to "the best possible failure" as a goal for timeboxed work. We slice work into pieces and then slice the slices. We find that if we can put a bunch of little slices into the timebox, ordered by importance/priority, then when time runs out and we're not fully finished we will have the most important work finished and integrated.

The worst failure is to have 100% of the work 90% done. Nothing is deliverable or useful. It's a mess.

To have 90% of the work 100% done is a qualified success. It's not 100% successful, but that 90% functionality is usable, functional, demonstrable, sellable. It may not satisfy everyone, but it can help some people. It gives partial value, and that's a damned sight better than zero value.

If you can't go faster, then make the best of the speed you have. Fail as well as possible.

A: Is that all?
B: No. Remember development may not be the bottleneck.

Organizations are shocked and upset to find that their 45-days-to-market lead time can't be improved (much) by speeding up programming because programming isn't the primary consumer of time in their case. 

In some cases halving coding time, if even possible, would produce results in 44 days instead of 45.
Software work spends most of its time waiting in queues. 

  • Approval queues. 
  • Prioritization queues.
  • Review queues. 
  • Waiting for other work to finish first. 
  • Waiting for testing. 
  • Waiting to be repaired. 
  • Waiting until the current production crisis is over. 
  • Waiting for an expert to answer a question or become available to consult on it. 

And it's worse than it sounds because these queues are wrapped in loops. 

  1. Code waits for the programmer to be available, b/c they're busy on something else
  2. Programmers work on the code
  3. The code waits for a code review, b/c the reviewers are busy 
  4. If the code review sends the code back to the programmer for changes, goto 1
  5. The code waits for a testing build on an official testing server, b/c servers are busy.
  6. The code waits for a tester to be available, b/c testers are busy.
  7. The tester waits for the code to be built and installed on an official testing server because the server has just been made available to the freshly-available tester and has to be prepared.
  8. The testers test the code.
  9. If any anomalies or improvements are noted, goto 1
  10. Code waits in a batch with other code to be deployed.
  11. If there is a problem with deployment, goto 1 for troubleshooting and remediation.

What if a change cycles at 4, then 9, then 4 again, then 9 again, then 9 one more time?  How long are these waits? 

If, as is often the case, 95+% of the time is waiting then programming twice as fast may yield you a 2.5% improvement in time-to-market. Whee. Not very impressive is it?

But if this is your situation, then it is very good news


You don't have to be a technical genius to fix human waits and queues. It only takes someone with some managerial chops and some systems thinking. 

You can do it. You can make the BIG difference in time to market.

You can give your staff the environment and support they need. Is it training? Information? Thought leadership? Faster computers? Learning to prevent defects? Learning to use their programming stack more effectively? Eliminating silos (working together with people rather than queuing)? 

You can change the system. You're a manager. You have skills and latitude.

Isn't that good news?

Monday, August 26, 2019

No Common Sense in Agile

People say that agile is “just common sense.” 

I wish.

I mean, it’s well-precedented and everything makes sense. But there is nothing common about it. 

It’s still a counter-cultural and counter-intuitive movement, to such an extent that most companies can’t tolerate it and have to compromise and cripple it immediately, even during adoption. Often before adoption.

Two problems with the “common sense” label:
  • It’s not common at all. 
  • It’s unpalatably sensible.


Just the simple idea of forming teams with all the skills necessary to do the job — that’s so uncommon as to earn an “uncommonly sensible” label.  

The idea of management “providing the environment and support they need” seems so backward to many companies as to be unthinkable (literally — they can’t think this way). 

And let’s not even try to penetrate with the idea of producing code that works every week, instead of (traditionally) code that may work someday when all the (traditionally) not-cross-functional teams finish all the bits and pieces and we (traditionally) take time to integrate it all together and test it in the final days and hours before (traditional) release.

And stopping to reflect on how you can do a better job? Most companies lock into a pattern and continue without ever questioning the way they work. For people to not only inspect but reflect and adapt? People scream “too much change! Thrash! Inconsistency! Hard to predict!” ...and stop all forward progress.  

Every time someone says “it’s just common sense” I want to ask why people aren’t commonly doing it? Because even companies that identify themselves as “agile” aren’t doing these basic things.

And now the aggressively-sensible method is expanded out of software and into other industries where it is equally radical and hard to swallow, but still produces great results. 

If you’re interested, consider how common and palatable and easy ModernAgile is:
  • Make (other) People Awesome
  • Make Safety The Prerequisite 
  • Experiment and Learn Rapidly
  • Deliver Value Continuously
Sensible? Yes.
Principled? Yes.
Common? Not.








Friday, August 23, 2019

The relationship between Agile and Scrum

A lot of people's first brush with Agile is during Scrum training.  There is usually some mention of the Agile Manifesto and its 12 Principles, maybe even 10 or 20 minutes spent comparing these to the scrum principles and behaviors. 

For a lot of these people, it's the first time they have ever read, seen, or heard of the agile manifesto.

If we are really lucky, they might even have heard of the Modern Agile principles. That's pretty cool when it happens.  

But they heard them in the context of Scrum, so they assume that these are supporting documents and of course when they're told "Scrum is Agile" they misunderstand.

The instructor probably meant to say "Scrum done right is fully compliant with Agile Principles and is a fully agile framework" (which I'm not arguing here). 

Unfortunately, most people hear that as the identity function "Agile is another word meaning Scrum. Scrum IS Agile. Agile IS scrum. They mean exactly the same thing." 

They don't recognize that the relationship is between a set (Agile) and a member of that set (Scrum).

I've tried several times to help make this clear and with mixed results. Here is a Venn diagram I made a long time ago:


Sadly, the point was missed. It's easy for people in the scrum world to become defensive because Scrum spent a decade or two being the most maligned agile framework on the planet. Almost all of the "bad agile" in the world was a bad implementation of Scrum. It has been more compromised and twisted and turned against people than any other framework until SAFe emerged. 

The distraction for Scrum defenders here is that I let the Scrum bubble lap outside the agile bubble.
That was very upsetting for some of my friends in the community. I still feel that there are ways to do scrum without having a very agile mentality, but that was not the purpose of the diagram.

That little bit of a bubble was the flaw in the example that destroyed the primary lesson being taught. It's one of the problems with using an abstract model of a real-world ontology; you risk losing people in the example.

I'm a little wiser, though I just republished that one as a counterexample.

I later wrote in some forums that "Scrum != Agile" and that was even worse. It was universally read as "Scrum is anti agile" instead of being seen as intended, that the word "Scrum" is not equivalent to the word "Agile". 

I later had a bit more success by reversing the nouns. When I say "Agile != Scrum" it's easier to see that I mean that Agile has something more/different to it than Scrum.  But of course, Scrum is the most maligned framework currently so there were defensive reactions.

"You're saying that scrum is not an agile framework!!!"
"No, I'm saying that it is not the only agile framework. There is more to agile than Scrum."
"But you singled out Scrum! You are anti-Scrum!"
"I singled it out because it's the only framework that people confuse with being all of Agile."

On it goes.

I don't blame them. It sucks being everyone's whipping boy.

So here's my most recent attempt:

Agile isn't a word that means Scrum.  Scrum is a member of the set of Agile things, as are many others.

I listed XP and FDD just because I needed a couple to kick-start the list not because they're "special" though XP is very special to me.

We'll see if this helps.

My favorite Estimates and NoEstimates exchange so far.


From my point of view and involvement with #NoEstimates we consider the things where the price is unknowable and the desire to know the price interferes with our ability to make good decisions.
9:33 AM · Aug 23, 2019Twitter for iPhone


Likewise, how much will you pay for electricity in the house you live in, all totaled up? Or my earlier grocery example. You don't consider those "buying a lifetime's supply" purchases, because they're ongoing maintenance costs. Hmmmmm........
1

The benefits of the food or the electricity Is available in tiny chunks, so to speak. The perception of a software project is that it brings no value until it is done. This is of course the whole point. Let’s re-imagine how software development is done.
2
3
4

This is the first calm, rational metaphor I’ve heard that starts to make sense for me. Most #noestimate folks just get angry and insulting. Thank you for the clarity!