The Agile Manifesto

Here’s a video I shot for freeCodeCamp about the Agile Manifesto.

The Agile Manifesto describes the fundamental values upon which every Agile framework rests. In this brief video, you’ll learn what the full Agile Manifesto is, along with a little history of how it was created.

Click “Continue reading” below for a transcript.

(more…)

2017-09-19T16:20:06-08:00July 24th, 2017|0 Comments

On Leaders and Safety

Safety is a mandatory prerequisite for the success of any Agile transformation.

Leaders cannot create safety for teams if they do not feel safe themselves. This is influenced not by the leaders they report to (including the board), but also whether or not they have overcome their own insecurities.

2017-07-24T13:24:15-08:00July 21st, 2017|0 Comments

Working Agreements

Here’s a video I shot for freeCodeCamp about Working Agreements.

Does your team show up late to meetings? Does Sprint Planning take forever because half the team isn’t paying attention to anything but social media? Find out how to identify and limit these and other big risks with a Working Agreement.

Click “Continue reading” below for a transcript.

(more…)

2017-09-19T16:20:06-08:00July 3rd, 2017|0 Comments

On Doing Versus Being Agile

Are you doing Agile, or have you become Agile?

The difference seems pedantic at first…

You are doing Agile when you’ve changed your tools and processes. This is relatively easy to do but doesn’t offer much in the way of benefits. You’ve become Agile when you’ve changed you structure and culture too. This is relatively hard to do, but offers significant benefits.

Agile isn’t just a process. It’s a complete framework that brings together a shift in culturestructure, and processes. This framework is supported by tools such as Rally and other Agile Lifecycle Management (ALM) tools.

(more…)

2017-07-10T11:16:54-08:00March 19th, 2016|0 Comments

What a 106-year-old psychological law tells us about stress in the office

Work harder!

We’ve all been admonished to work harder at some point in our lives, whether it was from a well-meaning parent, a sports coach, or a manager facing a deadline.

What many Agilists have come to empirically observe is that the more we can get people to feel happy and have a good work/life balance, their total productivity goes up. We’ve come to learn that “busyness” is not productivity. I have heard managers brag of how dedicated their teams are because they’re working 100-hour weeks on their latest and greatest innovation. Yet, they seem miss out on the fact that had their teams spent 35–40 hours a week on their latest and greatest innovation, it would be less late and even greater.

So, why do some managers insist upon added stress and arousal? Clearly there must have been a time or place where “cracking the whip” made sense.

Hint: It’s not in highly creative fields like software development.

It turns out that there are some times when it makes sense. According to the Yerkes-Dodson law, an “empirical relationship between [physiological and mental] arousal and performance,” performance increases when arousal does but only up to a point. In some cases, further arousal lowers performance.

For simple tasks, more arousal equals more performance, at least up to a point at which it relatively plateaus. For difficult tasks, more arousal equals more performance, until it reaches a peak and begins to plummet at the rate that it rose. This is because stress negatively affects cognitive processes such as attention, memory, and problem solving, all critical for the modern knowledge worker.

Put another way…

Yerkes-Dodson Law

One of the things that I really like about Agile is that it’s all about staying empirical… Transparency benefits inspection, inspection benefits adaptation. And over the years, we’ve come to learn in the business context what many have learned in the psychology and biology contexts.

For instance, a 2007 review of the effects of stress hormones like glucocorticoids found that people’s performance on memory tests and the levels of stress hormones in their blood produced very similar responses to what Yerkes and Dodson found nearly a century earlier. One example: the ability to form long-term memories was highest in the face of small quantity of glucocorticoids were in the bloodstream, but removing the adrenal glands (thus no glucocorticoids) or injected glucocorticoids produced poor long-term memory formations.

Interestingly, this same review found that in order for something to induce a stress response, it has to be perceived as: novel, unpredictable, uncontrollable, and/or possibly leading to social rejection. Naturally, any knowledge worker’s office is likely to be plagued by novelty, unpredictability, and a lack of control (at least from external circumstances like competition).

One of the things Agile teaches is is how to manage these constants well. Rather than stressing out and feeling like we need to “replan” because “things didn’t go the way we planned,” Agile assumes that things won’t go as planned. Uncertainty is embraced. Servant leaders who understand the nature of software development reality deeply understand these things, and so don’t unnecessarily create a culture of fear that produces the sense of a “social evaluative threat” when “the plan isn’t met.” The plan hypothesis was wrong in the first place.

Thus, workers in strong Agile cultures are more productive not only because they aren’t working 80-hour weeks, but also because the whole culture (especially the leadership) is mature enough not to freak out at every single change. These workers experience less stress, therefore they’re producing less stress hormones, and therefore their brain isn’t acting like it’s about to be eaten by a tiger. Keep in mind the tiny amount of time that has elapsed between the constant fear of violent death and the modern 72°F office environment, at least from an evolutionary perspective.

This is your brain on stress.

Truly Agile companies then put A+ talent in environments where they feel autonomy, mastery, and purpose, thus providing strong intrinsic motivation (which does not cause the same sort of stress). A+ talent will not tolerate an environment of mediocrity, fear, or command and control, so any such talent in such an environment exits post haste. This leaves behind giant teams of B and C players who send the company into a tragically-slow death spiral from which few can escape. Further, small teams of A+-level absolutely run circles around giant teams of B- and C-level talent (kudos to Steve Jobs for popularizing this).  Many people have never seen this in action.

It’s easy to feel like a hero or a martyr when you’re working those eighty-hour weeks “for a cause.” Managers can tell their employees that they’re not “strong enough” and need to “man up” and put in the hours. But try as we might to ignore them, rarely can we escape the simple facts of our physiology and biology.

Thanks to Wikipedia for illuminating me on the Yerkes-Dodson law, from whose article I borrowed liberally for my own.

Yerkes Dodson Parody

2017-02-13T11:39:56-08:00July 21st, 2014|1 Comment

Some Thoughtful Retrospective Questions

I’ve used relatively standard Agile Retrospective questions to great success over my career:

  • What’s one word that best describes this sprint? (one per person)
  • What were the positive aspects of this sprint that we’d like to persist?
  • What were the deltas we’d like to change?
  • How can we change our behavior, process, or definition of done to address the above?
  • What actions can we take (with volunteered date commitments from one or more individuals) to address the above?
  • And the most important “Big Daddy” that we should ask ourselves constantly… Why? Repeat that one another four times…

While this is a nice base, I’ve been looking for other questions to ask. Here’s several that I liked from Ben Linder’s blog, Sharing My Experience:

  • What still puzzles us?
  • What helps you to be successful as a team?
    • How did you do it?
  • Where and when did it go wrong in this sprint?
  • What do you expect, from who?
  • Which tools or techniques proved to be useful? Which not?
  • What is you biggest impediment?
  • If you could change 1 thing, what would it be?
  • What caused the problems that you had in this sprint?

Here are some nice why examples:

  • Why did you do it like this?
  • Why did this (or didn’t this) work for you?
  • Why do you consider something to be important?
  • Why do you feel this way?
  • Why did you decide to work together on this?

From Debategraph, I liked “What don’t we know yet?”

Are there other questions you like to ask during retrospectives?

Photo from Magnus D on flickr

2017-02-13T13:13:15-08:00May 23rd, 2014|3 Comments

The Haka Dance

The Haka (plural is the same as singular: haka) is a traditional ancestral war cry,dance or challenge from the Māori people of New Zealand. It is a posture dance performed by a group, with vigorous movements and stamping of the feet with rhythmically shouted accompaniment.[1] The New Zealand rugby team‘s practice of performing a haka before their matches has made the dance more widely known around the world.

From http://en.wikipedia.org/wiki/Haka

Does your team have this degree of ba? If not, what could you do to foster it?

2017-02-13T13:13:24-08:00May 23rd, 2014|0 Comments

Imagine a team that admits mistakes, reinforces their shared values, forgives one another, and moves on. Do you think such a team would come up with astonishing ideas? I do.

— Lyssa Adkins, Coaching Agile Teams

2017-02-13T13:13:42-08:00May 6th, 2014|0 Comments
Go to Top