Category Archives: Half-baked

Half-baked posts are ideas, musings, ramblings … more to encourage discussion than anything else. Please comment!

Mindfulness Is Dangerous

Or insert your provocative title here!

A tweet by my mentor @SAlhir alerted me to an article about possible dangers of mindfulness. As I consider myself “interested” in meditation, buddhism, mindfulness and stuff like that–but by no means an expert–I was intrigued.

I’d love to know what the Buddhist Geeks think of the article, dealing as it does with the use of mindfulness training in the workplace. Perhaps they’ll do a podcast about it (or already have, I’m a little behind in my listening). Certainly I have heard enough about the difficulties faced by serious meditators at breaking through to different levels of awareness to know that mindfulness or awareness can be difficult.

There must be many people like “Claire” who work hard, and on many levels “do well.” (Wait, you’ll get more out of my post if you’ll go read the article.) But we are complex beings with many more levels, that is, levels on which we do not do well. Or levels with which we are completely unfamiliar. For individuals seriously pursuing awakening through meditation, it is the challenge of discovering and coming to terms with these ‘deeper’ (implying buried, hidden) levels that is important. But for ‘casual’ meditators, such exploration may be dangerous, as revealed by “Claire.” Outward Bound hires guides and has protocols to protect those who venture on their physical journeys. Similar precautions really ought to be applied to exploring the layers of one’s mind, thinking and personality.

So why am I writing about this on my “agile coach” blog?

I was particularly struck by this sentence in the Guardian article:

After all, it’s harder to complain that you’re under too much stress at work if your employer points out that they’ve offered you relaxation classes: the blame then falls on the individual.

This suggests, I think rightly, that employers while well-intentioned, aren’t addressing the root causes of employee stress. That’s a bad thing; it won’t lead to true resolution of any problems.

That’s still not related to agile; here’s how I make the connection: a team/company/whatever that adopts agile practices–or especially one that adopts agile ‘rules’ or ‘best practices’–is like those employers offering a week of mindfulness training to it’s Type A personalities. It’s a band-aid, it’s potentially a ruse, it’s potentially dangerous.

Applying principles of agility, and I’ll point especially to the practice of regular and frequent retrospectives, without being prepared to properly deal with the consequences, is like mindfulness training on your lunch break. Or like sending your employees into the desert for 40 days and expecting them to come back enlightened.

A team that starts agile behavior will

  • encounter and expose company weaknesses quickly,
  • find themselves in conflict with each other,
  • be frustrated by conflict with partners outside the team

and will peel many more layers of the enterprise onion, shedding a lot of tears. The team and the enterprise need to expect difficulty and be committed to working through those difficulties as they arise.

If you don’t follow through, if you don’t take your agility journey *ahem* mindfully, you will end up with serious problems, maybe worse than what you started with (or maybe not worse, but more visible). And as can be the case with mindless “mindfulness training,” the employer will blame the team. Net-net: bad.

It’s not plug-and-play, attend-this-seminar-and-be-great, follow the rules or paint-by-numbers. If an Agile Coach or an Agile Consultancy offers you a two-week plan to Transform, keep looking.

Okay, end of rant. Hope you enjoyed it.


Burndown Charts That Suck #1

Over the past year or so, I’ve collected some burndown charts that illustrate some team problems. I don’t want to tell tales on past clients, so no names will be revealed by me. And for that matter, people always mean to do their best, but sometimes it’s an emotional challenge to fix things (see the second to last paragraph below).

For each image, I’ll list a few ideas I have about why the team’s progress looks as bad as it does.


  • mis-use of an agile tool (stories weren’t “in” the sprint when the start button was pushed)
  • stories not broken down into small enough pieces
  • probably not really using daily meetings to report progress.

  • mis-estimated some of the work, or actually had done work before the sprint started
  • …and then somehow managed to get stuck on the remaining work
  • meanwhile, a points worth of work failed at the end of the extended sprint–why wasn’t some qa-like work done earlier?

Screen Shot 2014-11-18 at 9.38.34 AM

  • Oh please. Admit that you didn’t meet the commitment, and move unfinished stories into a new sprint. Figure out why you struggled, and fix that problem.

I think there are two themes that pop out here. The first is using and relying on a tool before fully understanding the underlying principles. That first image, where all the scope of the sprint is added after the sprint has begun, illustrates a simple “record-keeping level” problem. But there are larger problems with tools. They’re built for some specific requirements, requested over time by people using the tool. But those people are not you or your team. You and your team will look at all the fields and dropdowns and buttons on the tool’s interface and decide you have to use them, even if you don’t know what they are for. Before figuring out what is important for you to track, you are puzzling over how to use someone else’s idea of tracking. This just leads to confusion and losing your focus to things that are actually meaningless to you.

When coaching, I really do prefer to start teams using paper and pens. Using simple manual tools forces simplicity. Simplicity gives you the chance to understand the process you are creating before it grows.

The second is a more emotional issue: teams are uncomfortable to admit failure.  Look at that last image. It is the map of a massive failure of some sort. “Extending” the sprint is much less confrontational than saying “something is broken.” But as hard as it is to admit failure, admitting failure is the first step in fixing the causes of that failure.

I don’t know if I heard this phrase somewhere else, but I’ll use it now: “Fess up when you mess up.” Then use your retrospective to make some improvement, somewhere in your process, or your team organization or your client/product owner relationship. Don’t let your burndown charts look like these.

SEO for this Blog

I’m looking at the posts I’ve made on this blog so far, and thinking about traffic–of which there is very, very little–and how to generate more traffic . . . which of course leads to thinking about SEO (search engine optimization).

I feel like I have very rarely mentioned “agile” or “scrum” in my posts. And that’s going to hurt my presence in search engine results if someone searches for those items. Sure, the name of the blog is “Agile Coach Jacque,” but as it stands, that’s just as likely to turn up in a search for yoga instructors as it is in a search for “software development methodology.”

*Sigh* Tempting though it may be, I’m not going to fill a post with all the names of agile methodologies and synonyms for “agile software development” that I can think of. (And besides, that kind of b.s. is detected and discarded by search engine algorithms anyway.) I’ll just keep writing things that I think are useful, and maybe work a bit on getting more people to link to me. Traffic and comments will come eventually. (And when it does, I’ll put sell ads on the site and make a million bucks a week! The new American Dream!) 🙂

Location, Location, Location and What’s Your Ecosystem

I just had lunch at a local sandwich shop [Soulwich, on Orrington Avenue in Evanston, IL–4 stars on Yelp, I recommend you visit!]. The owner was sharing his misery a little bit, that because of his location, on a block that has a lot of vacant storefronts, and paralleled by two busy, lively streets to the east and west, not many people came down his street, and his business wasn’t as good as it should be.

“I should have listened to that old adage” he said “‘Location, location, location.’ … Even if there were a competing sandwich shop like Panera or Potbelly next door, business would be better.”

That got me thinking just a bit about ecosystems. No matter how good your individual product or team, if there isn’t health nearby–or really, if there is poor health nearby–your work will be affected. If your healthy-team members have to interact with members of a team in poor health, your team will be affected. If your healthy-team is guided by a poor-sighted governance system, one that doesn’t do a good job of prioritizing for value, your team will be adversely affected.

Look around at the ecosystem that surrounds your teams. Is there some change, even something small, even a competing team, that can improve the health of the ecosystem?

Electrical Circuits as a Metaphor in Agility

In discussion with the core team at a current client, somehow the idea came up of representing team members and other players involved in transformation by electrical symbols.

  • Someone outwardly and obstructively opposed to change (that’s the obvious definition, anyway).
  • Someone from whom information/conversation flow is one-way only.
  • Business Sponsor, Lead or Visionary.
  • Someone who controls flow, or limits velocity (for good or bad?).
  • Someone or some process for smoothing out turbulence or variability.

I’m going to play with these ideas–some of you readers will suggest others?–to see if they’re helpful as metaphors for a transformation journey.