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.

No Scope Creep

Tobias Mayer earlier today tweeted:

In an agile environment there is no such thing as “scope creep”. There are only better ideas.

Amen.

Amen, amen, amen.

He hasn’t expanded on that tweet in a blog post (afaik); but really what more is there to be said? I suppose saying it gives those who don’t know what it means the opportunity to ask “what does that mean?” which could then be the subject of a blog post. But this is just words. That tweet expresses such an important idea.

There Should Be Some Fun

We’re working with a slightly-distributed team. So after we do our standup, I often take a picture of the physical wall to share with the remote stakeholders. For this, I use the panorama mode of  my phone.

When team members are willing to have some fun together–as illustrated by this image–I think you’re on the right track to a solidly-performing team.

One of the other developers was wandering by, and was heard to mutter “I wish I had a wall.”

 

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?

• 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.

Commitments and Quantified Self

I came across a posting on quantifiedself.com that I thought would be very interesting to those who think about agile principles. In an eight-minute talk with about seven minutes of Q&A, Michael Cohn describes his own experiments with tracking personal commitment and progress.

http://quantifiedself.com/2014/04/michael-cohn-tracking-commitment/

If you’re like me, when you listen to his talk, you’ll hear “planning meeting,” “commitment,” “daily standup” and “review.” He also talks about the value each of these things has in keeping him on track. I’m not going to do a detailed analysis here, just a recommendation that you might find these an interesting 15 minutes.

Cohn is talking at a personal level, but the things he says make a lot of sense applied to teams, as well.

The talk was just posted today, April 17, on quantified self. It hasn’t generated any comments there yet. If you like what you hear there, please leave them some comments … and if you want to tie your thoughts more closely to agile principles, I’d love to hear from you here as well!

Lowering Risk

I’ve written a post titled “Lowering Risk Using Agile and Lean Methodologies” for the blog at Pathfinder Software. Here, I’ll post a summary, and invite you to link on over to Pathfinder’s blog for the full version. Leave a comment in either place.

I’m interested in three kinds of risk that are mitigated by using agile and lean processes:

• building the wrong features or the wrong design (“UX”)
• changing market conditions
• the unknown

Even the best market research is more theoretical than the empirical test of building a small product and releasing it to actual users. This is true of features and of a chosen design (interaction design or visual design). It’s even true of your application architecture or production environment.

By building in small iterations that are individually complete, your ability to react to changing market conditions is enhanced.

Open communication in an accessible way, as suggested by agile principles, leverages the knowledge of the whole team to anticipate and solve problems however they arise.

The topic was suggested to me by folks at Pathfinder, who also provided some editing. So I invite you to read the entire post at the Pathfinder Software blog.

More on “The Curse of Allocation”

Recently, I re-discovered a post written by my friend Len Lagestee entitled “The Curse of Allocation.”

Len lays out five important problems that arise from allocating people to multiple teams or projects:

• Wasted Time
• Frustration
• Lack of team bonding and connection
• Lack of ownership and accountability
• Perceived progress

Len’s post is a good one, and I encourage you to read it (and add his blog, Illustrated Agile to your regular reads!).

There is another problem with allocation people to multiple projects that I’d like to mention. It could also be seen as a symptom of the last two points Len raises, “lack of ownership and accountability” and “perceived progress.”

It’s very common for a worker who has two or more projects to work on to have to decide “what will I do today?” and to have several choices on each project they are working on. I believe (and have observed) that given a choice, an individual will choose the work that is either easiest or most easily defined (they’re often but not always the same). Which means that, given two sets of stories or tasks to choose from, an individual will choose what to do based not on the priorities and needs of either team, but rather will choose to do work that looks like something they can complete.

Of course, choosing to work on something you can complete is a great principle of agile: commit to doing things you can finish, or design your work such that there is a clear way of telling that it is done. No problem there.

The problem is that sometimes the most important work a team can take on is not easy to do or easy to define. Sometimes a team–or an individual–needs to be faced with no option but to take on a difficult challenge. A person on two teams, when faced with a difficult obstacle on team A, will choose to do the easier or clearer work on team B. And that is bad for both teamwork and team progress. It would be better that that individual have no option but to talk to their teammates, confess that they’re stuck, and get the team’s wisdom on determining how to move ahead.

As a thought-starter, I’ll offer a third alternative to Len’s tips — and let me note that Len’s tips are FAR superior to this idea:

Enforce the terms of allocation. If an individual is assigned to work “50%” of their time on project or team A, they should spend, literally, exactly that amount of their time on that project, even if it means they’re staring into space trying to think of the solution to a problem, or running around to the rest of the team asking for advice. That 50% should be regular (every iteration, pay period, reporting interval, whatever) and predictable (“each day from 8 am until noon” for instance).

Prioritize and Don’t Do It (Len’s post) are better pieces of advice, but if you must allocate, enforce the allocation so that you really understand its implications.

Panel Discussion: UX and Agile

Wednesday, March 20, I will be moderating a panel discussion on how UX fits into agile environments.

http://www.ixdachicago.org/events/ux-panel-discussion-how-does-ux-fit-into-agile

This is IxDAChicago’s monthly meeting. I’m really looking forward to this event. It’s something I have wanted to do for a long time.

Agile principles really suggest that people are more important than fixed processes and tools. So I hope in this conversation to bring out the different ways (processes) that user experience design (and research, etc.) has been integrated into different agile environments. And by implication those environments have been created by (different) people with unique needs.

I hope that members of the audience will come away with some ideas for their own agile journeys, as well as an appreciation that there is no single “best” practice for UX in an agile space.

If you attend, please say “hello” after the discussion! Oh, and bring your questions, too!

Five Processes

Read about this in a discussion on LinkedIn’s Agile CMMI group.

Nils Malotaux describes Five Processes that businesses use: the official one, the one we think we use, the one we idealize, the one that would be best for us, and the one that someone or something else (vendor, software …) imposes on us.

As coaches, we think we’re bringing the target process, but we might actually be bringing a perceived process . . . and everyone is subject to the process that is imposed by management, or vendor or other circumstances.

I don’t need to run on at length about it, read Nil’s entry. What do you think? Add a comment (here or there).

If You Give a ____

Overheard in a recent meeting – the AP has a guide for online style.

That’s not at all surprising, but I thought I would google the comparison between AP style and the Chicago Manual. I stumbled upon http://www.apvschicago.com . Here is a great tagline:

A guide comparing Associated Press style and Chicago style for editors, writers, teachers, students, word nerds, and anyone else who gives a dollar sign, ampersand, exclamation point, and pound sign about style.

If you didn’t chuckle as I did, be sure you read through the last twelve or so words again.