Panel Discussion: UX and Agile

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

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

Why the Name “Scrum?”

It almost never fails to get a laugh: “scrum.”

But there are some real reasons for that name — it’s a term from rugby, and it’s used as a metaphor to reflect the degree of cooperation needed to succeed.

A rugby team scores when the ball is advanced across the goal line and touched to the ground. The way the ball moves is (primarily) by being carried and being handed off or passed laterally/backwards. If the ball carrier is tackled, he must release the ball, and play doesn’t stop.

Because holding the ball leaves you very vulnerable to being tackled by the big lads on the opposing team, it’s imperative to keep the ball moving between teammates. And this means that the whole team is needed to score. There are no Montana-Rice combos in rugby, no solo stars–at least not to the degree that there are in American football.

Work as a Team

There are a lot of applicable statements on this page about playing rugby: , but here’s one that might be the best:

Continually think of your alignment in relation to the ball carrier and any players in between. Work hard to be available when needed.

How about if I repeat that last sentence for effect: “Work hard to be available when needed.” If you are on an agile team, you should work hard to help your team succeed. Another one of those sure ways to make your team unhealthy is to look at the stories or tasks, shrug, and say “there’s nothing here for me to do.”

So . . . Scrum?

So what’s the term “scrum?” It’s the beginning of play (or the restart of play after an infraction): . If you are familiar with American football, you’ll see a scrum and think of a scrimmage. But in the scrum the ball is loose, and each team is scrambling (clawing, fighting, kicking) to gain control. Just as when the ball is being handled by the backs, teamwork is required. (I’m not advocating for violence in your retrospective meetings, just describing rugby, now.)

scrum, where forwards from both teams pack together using their bulk, strength and ability to work together to get the ball.

How do I know all this? Well, I admit I’m not an expert. I just googled to find the site I’m referencing, and what it says matches what I remember (Thanks, Peter Dawson!). Because when I was in college, I played rugby for about a week, damn near broke my ankle in a practice and never played again. I got a good tough shirt out of the deal, but my ankle still hurts sometimes.

Coaches and How to Hire Them

I really like the ideas expressed by Tobias Mayer in his post “How to Hire an Agile Consultant.” I recommend you go read his post.

I found Tobias via the comments on this anonymous “editorial”. That happens to be a post with some good ideas and concerns as well, but I have to fall in with the commenters who take it to task for its anonymity, in spite of using the personal pronouns “I” and “me” consistently throughout. Good ideas, but no-one to whom one can give credit.

I haven’t yet directly experienced the coach = scrummaster situation yet, but I can easily see how it will happen as more and more companies look for help in “doing agile.” And more and more companies spring up to offer these services.

Scrum Master != Answer Master

One thing I’ve seen in watching companies adopt agile principles, and specifically with some flavor of Scrum, is the tendency for newly-minted ScrumMasters to feel that they must have the answer for any question asked in a standup, demonstration, planning, grooming, or retrospective.

Now, it’s very typical for the existing Project Manager to assume the ScrumMaster role. It is the closest to what they were doing before.

And it’s natural for ex-Project Managers to hold on to many aspects of that role–we’re creatures of habit, after all. And in waterfall, the Project Manager was responsible–even accountable–for creating that lovely detailed work breakdown structure, and those spiffy cascading Gantt charts in MS Project. All the answers were at their fingertips: Are we On Schedule? Check with the Project Manager–they have a magical way of knowing if things are on track! What happens if we remove a feature? Subtract the tasks from the WBS, re-align any dependencies and voila, the Project Manager has calculated the answer!

Things aren’t so simple in life. Or in Scrum/agile.

If we’re building a healthy team, we should be seeing communication between team members, in a network, rather than in the hub and spoke fashion of a lot of Project Managers. ScrumMasters should encourage this networked mode of communication.

I believe it’s healthier to accept that one individual will not have all the answers. Scary? Sure. But if your team is healthy, the answer to a question is not very far away, because there will be enough communication to retrieve any answer in short order (and enough information radiated by reports the ScrumMaster maintains to answer many simple status questions straightaway). Think about the idea that the knowledge of the team is “too big to know” and that the smartest person in the room is the room.

One way to be sure that your team doesn’t get healthy is to make sure that all communication is funneled through one single individual. (For instance, what does it do to your truck number if only one person has access to the folder where the team’s release plan is stored?)

On some–or maybe even many–projects, rather than being a special expert, the ScrumMaster could be an individual from within the team who steps up to handle the ScrumMaster role in addition to their other duties. The description of the ScrumMaster from the Scrum Alliance’s Scrum 101 page reads simply “ensures that the team is functional and productive.”

So, ScrumMasters, make sure your teams are protected from outside distractions. Radiate information like a single-pipe steam radiator with a wide-open air vent on a freezing cold day. Get the team to the demonstrations, the retrospectives, the grooming, the planning by making sure they know when and where they are. But once things get underway, get out of the way. To borrow a phrase, facilitate your meetings “as though you were cooking a small fish.”

(As a sidebar, and in the interest of thoroughness–not as an endorsement–I’ll link to the “ScrumMaster Manifesto.” I’ll say that I’m pretty sure that I disagree with their statement “WE BELIEVE THE SCRUMMASTER IS A FULL-TIME POSITION FOR ONE PERSON ON ONE SCRUM TEAM.” I think a lot about team size, challenge, maturity, and capability are being assumed by that statement.)

Jilles van Gurp’s “Scrum: Agile Madness”

There is some great stuff on Jiles van Gurp’s blog. Here are a few of my favorite thoughts from “Scrum: Agile Madness

  • “…you can’t substitute experience with process and that is exactly what agile followers end up doing. Take away the experienced people and you have a lot of people executing the rituals of scrum, kanban, or whatever without really understanding what they are doing.”
  • “…often scrum is introduced to fix what is already a dysfunctional organization.”
  • “Actually, if all of the above is true [referring to four assumptions about happy and productive teams], you will have little need for process. If that isn’t the case, no amount of process is going to fix things magically.”
  • “[ironically:] A two day pep talk about scrum is apparently all the training you need to become a product manager or scrum master.”
  • “[T]here are a lot of inexperienced people who get promoted to be a product owner or worse start their first or second job being one. Likewise, the scrum master role is not considered a job very high on the corporate ladder either.”
  • “Choosing and tuning the way in which you work is more important than having everybody mindlessly follow the same process.”

These quotations of course are all presented here without the context van Gurp provides. I strongly recommend you read the whole post: . Thank you, Jilles, for your blog!