OMG, Change Your Tactics

As actors and directors of theater, we’re always trying to keep the story and the characters interesting. One sure fire way to not be interesting as a character is to ignore your usage of tactics. If you look at each line in a script as an attempt for your character to get something he wants, then your tactics are they way you go about getting it. Overusing the same tactics is off-putting to an audience. Think about it, nobody wants to see a movie where the leading man always gets his way by being charming, or one where the bad guy is always yelling and screaming. It’s much more interesting and engaging to watch characters use multiple tactics to get what they want.

Al Pacino is the master of tactics. In his best movies, you don’t notice as much because they blend so naturally into his character. His turn as Big Boy in Dick Tracy is a perfect example. It’s easier to point out his tactics in his not-as-good movies (like Heat) because they stick out a little more.

In the stage adaptation of Peter and The Starcatcher, Captain Hook injures himself. His reaction is a repetition of “Oh, my God” over and over and over again. To understand how this simple phrase can become more interesting through the use of varying tactics, say that phrase to a friend nine times. Pretty boring, yeah?

Now try it this way, with a little help in changing your tactics with each reading:

Oh, my God Oh, my God

Oh, my God Oh, my God

Oh, my God Oh, my God

Oh, my God Oh, my God

Oh, my God

Oh, my God Oh, my God

Oh, my God Oh, my God

Oh, my God Oh, my God

Oh, my God Oh, my God

Which way is more interesting? More engaging? Just like when Captain Hook reacts to his pain, each “Oh, my God” is a lesson in tactics.

As team members, we need to understand the power behind tactics. It’s a perfect illustration of the benefit of face-to-face conversation. “Oh, my God” can be interpreted on paper or in an email, but it means something specific face-to-face.

As leaders, it’s important to recognize when your current tactics aren’t getting you what you want. When you find yourself spinning your wheels, it’s likely that your tactics are either overused or unnatural. Try introducing variety in your persuasion and influencing techniques. You may find that you’re more successful.

Generally, being aware of our tactics reminds us that we are all subject to the hazard of becoming Charlie Brown’s Teacher. Without variety or the element of surprise in our communications, we risk becoming noise makers without a message.

The Show Must Go On

IM_A_SPEAKER_AT-300px

I’m speaking at Agile 2014 in Orlando on July 29. If you’re at the conference, come check out my session. I’ll be talking about the connection between developing great software and developing great theatre. Many in the community view software development as an engineering practice, but, as we’ll explore in my talk, it’s as much an art. Once you appreciate this view, leading Agile teams takes on a new dimension.

Here’s a preview of my slide deck.

Who Really Needs Agile Training?

The 13 year old Prospects

I have two young boys, both of whom play baseball. My wife and I are at the ballpark a lot. If you’ve got a ball player, you know how impossible it is to just be a bystander. There are so many games, they work so hard, and they only get so many chances to do something wonderful – it starts to get in your blood. You start wanting success as much as they do. You start coaching them in the car ride home, analyzing each swing, each pitch, each drop step in the outfield. You start to panic when they haven’t hit the ball for three games in a row.

The Matheny Manifesto

It doesn’t help that I live in St. Louis, a city whose common denominator is the St. Louis Cardinals. The Cardinals is one of the oldest and winningest teams in baseball history. They are currently managed by Mike Matheny, the youngest manager in the MLB. Matheny was hired just a few years ago, and he was able to take the team to the post season in each of his first two seasons, and to the World Series last year. Earlier in his career he was a catcher for the Cardinals, but his only management experience consisted of coaching a youth baseball team. During his tenure in little league, he established what is now referred to as the Matheny Manifesto, a lengthy dissertation on his coaching philosophy. It started as a letter to the parents of the team he coached, but it has become popular among little league teams. Coaches will often ask parents to read it at the opening of the season to remind them to keep their priorities in check.

A few highlights from the manifesto:

  • “I have found the biggest problem with youth sports has been the parents.”
  • “I believe that the biggest role of the parent is to be a silent source of encouragement.”
  •  “Our culture has lost respect for authority mostly because the kids hear the parents constantly complaining about the teachers and coaches of the child.”

If you have the time to read the entire seven page, 2700ish-word letter to the parents of his little league team, I highly recommend it. You’ll understand rather quickly who exactly he’s trying to coach. And it’s not the kids.

It’s These Parents That Need the Coaching, Not the Kids!

Organizations spend a lot of money, time, and energy reorganizing departments, implementing a new tool, or even adopting Agile in the hopes that such changes will improve the quality of the software they deliver, or perhaps make them deliver faster. These efforts are more often than not aimed at those that are actually doing the work. When I visit a client, I’m typically spending time with the developers, testers, and project managers. The thinking is that if they’re the ones undergoing the change, they’re the ones that should be trained.

But there’s a very important element of improving software delivery that isn’t being addressed in these training sessions: management. In the ball park, Matheny recognized that building a successful baseball team included training the parents. He saw that the parents need to learn how to be parents of little leaguers. In the world of software delivery, managers also need training – they need to learn how to be managers of Agile software developers.

 “I am completely fine with your son getting lessons from whomever you see fit. The only problem I will have is if your instructor is telling your son not to follow the plan of the team.”

We can provide Agile training to our teams until they are experts. But if we can’t provide their managers the skills they need to steer them within the Agile principles, what value is the training? Teams are being trained to self-organize, but we expect managers to just fit in to that model. Teams are being trained to favor face-to-face conversations, but managers are still holding on to the chain of command. How can Agile teams be successful with such an uneven training plan?

If we expect Agile training efforts to pay off, we have to train the managers how to manage Agile teams.

Training vs. Training

At work, we think of training as a one-time event. We consider ourselves proficient in a particular software program because we went to training. On the baseball field though, the concept of training is completely different. It’s repetition-based. It’s taking 100 grounders, or throwing 50 pitches, or repeating a pick-off play over and over and over. Agile management training should resemble baseball training, with a lot of situational role-playing and repetition.

A baseball player would never think he was proficient at baseball because he went to a one-time training event. And his skills would deteriorate if he left the game for an extended period of time. Likewise, Agile management training should be an ongoing effort.

The primary lesson of the Matheny Manifesto is that parents need to back off. The kids will improve at a faster rate if they aren’t constantly pressured by their parents. If the kids are given the freedom to make mistakes, they’ll learn faster. But this is a difficult pill to swallow for many parents, so Matheny spends as much effort training them as he does his kids. The parents had to be trained so his kids could be trained.

I suggest we train managers of software teams to take the same approach. Agile managers should be trained to back off, let their teams make mistakes, and give them the freedom to improve. It’s the only way to make the team training effective.

Sound off

What do you think? Managers, are you getting the training you need to manage your teams? Team members, do you feel your managers have the skills to allow you to be successful? Leave your comments below, or send me a note on Twitter at @johnkrewson.

Quick Tip #2: Don’t Persecute the Typist

I know it’s fun to make fun of people who don’t know how to use a computer. But if you have a facilitator in your meetings who happens to be taking notes in Excel while using a projector, refrain from calling him out on his typos and missed opportunities to use keyboard shortcuts. He probably already knows how to right-click and add a column, and he probably didn’t mean to leave the “r” out of the word “story”. We could either focus on what needs to get done in the meeting or we could criticize his Excel mastery.

Choose the former.

The Missing Agile Value

Author Carol Dweck has completely changed the way I approach the world.

I’m a smart guy. I’m no genius but I’m pretty smart. Through most of my life, I’ve been able to get by just by being smart. For the most part it has turned out to be a pretty good strategy. I complete tasks in less time by thinking about them longer, I demonstrate industry knowledge (thus impressing my bosses) because I can hold a lot in my big fat brain. The problem is, I allowed the world around me to turn my smarts into my identity. It became my brand, and I felt a constant subconscious urge to protect that brand. As a result, I would avoid any attempt at a challenge to my intelligence. Unfamiliar things were anathema because not knowing about them made me look not smart. I avoided anything above my cognitive pay grade, and chose the activities that allowed me to shine.

Kinda limiting, don’t you think?

Enter Carol Dweck. She wrote Mindset, a book I find myself recommending in just about every conversation I have. In it, she describes me exactly. I had, as she describes in her book, a fixed mindset. Someone with a fixed mindset believes that intelligence and abilities are fixed; you’re either born with them or you’re not. A growth mindset, however, is one that believes that intelligence is not fixed and that, with enough effort and grit, anyone can be brilliant. The message isn’t new; it’s basically a very detailed version of, “Whether you think you can or you can’t, you’re right.” But what is new, as she explains in her book, is the science and evidence behind that way of thinking.

She compares John McEnroe (fixed mindset) to Michael Jordan (growth mindset). John McEnroe would blame everyone but himself when he lost a match, but Michael Jordan, who didn’t even make his high school basketball team, put in the effort to become the best basketball player ever. McEnroe wouldn’t allow himself to be labeled as someone who has something to learn, he considered himself a born tennis great. Jordan, on the other hand, was always learning, always trying to make himself a better player.

Since reading the book, I’ve looked at the world in a completely different way. Instead of looking for opportunities to show off my intelligence, I’m looking for opportunities to grow my intelligence. Instead of gravitating toward subjects with which I’m already familiar, I’m entering into new and unfamiliar domains. I’m learning about sales. I joined an indoor soccer team. I’ve always considered myself rather bad at sales and just plain awful at soccer. I’m no longer embarrassed to say that I don’t know something. Instead, I’m eager to learn about it. I don’t allow failing to result in labeling myself as a failure. Instead, I learn from it.

I value learning. And there’s a lot to learn in the domain of software development. Because it’s hard.

I believe the creators of the Agile Manifesto value learning as well. They just went about expressing it in a different way. Take a look at the first sentence:

“We are uncovering better ways of developing software by doing it and helping others do it.”

Imagine, instead, if this first sentence was written like this:

“We have uncovered the best way to develop software through academic research.”

We are uncovering better ways of developing software. We’re still trying to figure this thing out. We’re still learning. Just like doctors who say they “practice” medicine because they haven’t perfected the science, I think that we’re practicing Agile because we haven’t perfected the process. And I don’t think we ever will. That’s why we always have to be learning.

By doing it and helping others do it. By digging in, failing, and learning – we’re putting our reputations on the line by experimenting with software development approaches in settings where money is at stake.

Learning is everywhere in the Agile mindset. We learn from our customers through rapid and frequent feedback. We learn from each other through regularly scheduled retrospectives. We respond to change because we learn about shifts in the market. We rework and refactor because we learn that there’s a better way to lay down code. To truly be Agile means to be in constant learning mode. To be Agile requires a growth mindset.

Have you noticed that the term “best practice” is hard to find in the Agile canon? That’s because there really are no best practices. We implement, we retrospect, we tweak. With all that tweaking, how could we ever settle on a best practice? If we’re too focused on implementing the best way, we’ll never find the better ways.

I offer an additional Agile value: Learning over Best Practices. While there is value in best practices, we value learning more. I’d like to know where you stand on this. Please drop a comment or hit me up on Twitter at @johnkrewson. Maybe I can learn something from your feedback.

Why ‘Tech Safety’ Might Not Work

You’ve probably seen a lot written lately about tech safety, the notion that we should be making our software environments as safe to work in as our physical workplace environment. If you haven’t, it’s definitely worth a read.  Josh Kerievsky has conjured up a useful analogy for the protective measures we should be implementing in our development environments. From his initial article on the topic:

Tech safety is a driving value, ever-present, like breathing.

 It is not a process or technique and it is not a priority, since it isn’t something that can be displaced by other priorities.

 Valuing tech safety means continuously improving the safety of processes, codebases, workplaces, relationships, products and services.

 It is a pathway to excellence, not an end unto itself.

 It influences what we notice, what we work on and how our organization runs.

 It’s a noble concept and I wholeheartedly believe that it has merit. However, there’s an issue with the idea of Tech Safety lurking below the surface, and it’s called “risk homeostasis”. Risk homeostasis, a theory developed by Gerald Wilde in 1994, is the idea that we don’t save risk; we consume it. In other words, when we implement something to make our lives safer, we use it to justify riskier behavior in other areas of our lives, and so on the whole we’re no safer than we were before. There is no better overview of the concept of risk homeostasis than Malcolm Gladwell’s 1996 New Yorker article, “Blowup”. (You can also find it in What the Dog Saw, a collection of his best articles.) In the article, he examines the cultural and sociological factors that contributed to disasters like the Challenger explosion and Three-Mile Island. At the top of the list: Risk homeostasis.

A few examples:

  • Studies have shown that Diet Coke does not help people lose weight. On the contrary: the supposed calorie “savings” are subconsciously used as an excuse to eat other high-calorie foods.
  • When we lower our monthly expenses by, say, paying off a car loan, do we take that amount and put it in a savings account or find another way to spend it?
  • Gladwell cites a study of taxi drivers in his article. Drivers whose cars are equipped with ABS were shown to drive more recklessly than those who didn’t, supposedly because they “consumed” the risk savings provided by their anti-lock braking systems.

Don’t get me wrong, I believe that Tech Safety is a good idea. We need to be able to prevent our teams from the perils of fragile code. We owe it to our customers to protect them from bugs. But the safety systems we create, according to the risk homeostasis theory, are just going to give us permission to increase our risky behavior in other areas. We’re going to use the protections we’ve enabled, not to make us safer, but to make us faster. That’s what the taxi drivers did, isn’t it?

So what’s the solution?

I think the first step is recognition. It’s human nature to equalize our risk tolerance. When we create our safety systems, let’s not look at it as the solution, but as the first iteration of a better system.

The next step is to find the balance for each of our safety checks. Our safety systems have to have the foresight to capture and isolate the risk not only within the area it’s intended to protect, but also areas where our desire for risk might leak. Not just checks, but balances too. And checks-and-balances is where Agile shines. We protect against mishandled requirements with acceptance criteria and a clear definition of done (check), and prevent information silos with collective ownership (balance).

I’d like to hear your thoughts. How else can we protect our safety systems from risk homeostasis?

Quick Tip #1: Lunch Meetings Don’t Save Time

This is not a secret. It’s a well-known fact.

Here’s what a one-hour lunch meeting agenda really looks like:

  • Roll call (5 min)
  • Set up the food (15 minutes, maybe longer if it’s being delivered)
  • Eat (20 min)
  • Clean-up (5 minutes)
  • Discuss meeting topic (5 minutes)
  • Devise alternative arrangement since meeting only lasted 10 minutes (10 minutes)

So the next time you hear this:

“This meeting has to happen today and the only free spot is during lunchtime. Can I just bring lunch in?”

The proper response is this:

“No. Figure something else out.”

4 Great Articles That Aren’t About Agile Even Though They Are

1. Operational Excellence, Meet Customer Intimacy

Brad Power writes a great piece weaving Lean concepts in and out of Michael Treacy’s Value Disciplines. He profiles Tesco’s successes in making these two concepts work together. If you don’t think Agile is headed to the enterprise, read this article, then think again.

2. You Need to Get Into Flow: Concentration At Its Best

Dianne Schilling isn’t talking about the continuous flow of Kanban, she’s talking about personal mental flow and achieving maximum productivity. When you extend this thought to continuous flow in a team environment, though, the benefits are the same.

3. 7 Employees You Should Fire Now

Yep. I know, we don’t like to think about this side of running a development shop, but Agile doesn’t work with just anybody. As a leader, your first step is to get the right people on the bus. Steve Tobak identifies the types of employees that don’t belong on that bus.

4. A Line to See Someone Is Not Cool, But Is Blocking Progress

Steven Sinofsky paints such a good picture of the problems that the Agile community is trying to solve every day: command and control, establishing appropriate accountability, establishing team rhythm. He does it by dissecting the barrage of employees waiting their turn to speak to  a busy manager and pointing out exactly what’s wrong with it. He also offers some some helpful solutions.

All the Good Ideas are Taken

second city

The Second City in Chicago has been turning out A-List comedians since the 1950s. Countless performers from Joan Rivers and Alan Arkin to John Candy and Steve Carrell started there, then went on to have long lasting careers in comedy.

Many of them move on as cast members on Saturday Night Live, where they continue to churn out laugh after laugh. The question is, when does the well run dry? When will we harvest the last laugh – the last joke or prank?

When will we run out of funny?

The answer, of course, is never. Humor is just an observation of the world around us. As long as our world is changing, there will be an opportunity to find humor in it. The best comedians are just the ones who are most adept at noticing it.

Those of us in the Agile community often feel like the best ideas have been spoken for. But that can’t be true. If all the good ideas were taken, we wouldn’t be filling conferences across the globe year after year, writing (and buying) books, and attempting to make our current processes better. We’d just take the ideas we have and say, “Well, that’s the best we can do”.

There will always be good ideas. Better ideas. Great ideas. As long as there are great problems, there will be great ideas. So if you’re thinking that there’s no point in contributing because all the good ideas are taken, stop thinking that way. Ideas are a renewable resource.

Are we going to run out of musicians? Will there come a day when there are no more good designs?

Your ideas, your thoughts, your contributions are what makes the Agile community tick. So don’t hold back. We’re counting on you.