Tag Archives: Redpoint

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!

Advertisements

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

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: http://www.rugby-sidestep-central.com/rugby-attack.html , 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): http://www.rugby-sidestep-central.com/basic-rugby-rules.html#Q20 . 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.

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

Punished by Ambition

One of the precepts that we–okay, I, for certain–take for granted in scrum is that teams should consider carefully how much work they can commit to in their sprints, use estimated size (i.e. in story points*) and past history as a guide, and only take on more work if they truly finish the work they’ve committed to. Intuitively, this makes sense. You want your teams to focus and finish work, not to start, or stub out, more than they can finish. Starting more than you can finish leads to making some progress with a lot of things, but being finished with few.

As I said, this makes sense intuitively. Recently, I came across a very nice empirical observation of the danger of over-commiting. I have to give props to one of my current clients** for providing this example, as well as providing the title of this blog post (although the phrase may have first been used by Sir Francis Bacon).

The team’s velocity, now established after more than 8 working timeboxes, is 60+ points per three-week sprint. This is shown on the graph as the 5-week moving average of points completed per sprint. But the team didn’t always know–or trust–that as a fact.

During their fourth sprint, even though they had never completed more than 81 points in a sprint, the team was pushed to accept 134 points as their committed work. They failed in a spectacular manner, completing less than a third that many. In fact, the number of points completed during that sprint was their second-lowest on record. (Their lowest-measuring sprint occurred early on when the team had almost no experience with agile techniques.)

So you can imagine what happened, right? The Product Owner, excited at seeing an upward trend over the previous couple of sprints, and perhaps agitated to release something soon, may have pushed the team to take on more work. Or the team itself, wanting to prove something, may have applied internal pressure. Whatever the exact reason, they took on more than they could handle. And the result was calamitous. Not only did the team not complete all the points they committed to, they in fact completed fewer points than they usually could.

In sprints 3.3 and 3.4, the team was more conservative, committing to 62 and 70 points respectively. And in both of those sprints, they were able to pull in work and complete more points than they committed to. (This pattern may suggest, of course, that their actual capacity is higher than 60.) But look out! Buoyed by those two successes, the team committed to 115 points in sprint 3.5, and again failed to meet their commitment. (To be fair, they did complete more than their average, so something is going right.)

The important point is that remaining focused, which in behavior translates to committing to fewer points/stories, allows the team to work more effectively and accomplish more than planned. And being aggressive in committing to work dilutes attention and results in worse than average performance.


* But for a good common sense opinion on NOT using story points for selecting work for sprints, see Mike Cohn “Why I Don’t Use Story Points for Sprint Planning.” I don’t think what he says negates the underlying message I’m trying to convey in my post.

** Not wishing to run afoul of any confidentiality agreements that may exist, I’m not going to identify the client by name in this blog posting.

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?

Nothing’s Personal / It’s All Personal

One problem I have observed in Retrospectives, and one of the things that can keep a team (scrum/agile or otherwise) from really performing well, is the tendency to interrupt each other.

Sometimes, interruption is a sign of healthy enthusiasm. But sometimes it is not. It takes courage to let someone else finish their thoughts. You might be scared that they won’t let you finish yours. You might fear that your idea won’t be accepted if you don’t repeat it often enough. You might be afraid that someone else’s idea will be better than yours.

Stephen Covey’s fifth “habit” is “seek first to understand, then to be understood” and that definitely applies in Retrospective meetings.

But why did I title this post “Nothing’s Personal / It’s All Personal?”

Because it’s going to feel quite personal, to listen carefully to what someone says. Often things that are discussed in Retrospectives are coming from a place of feeling, of emotion, not simply burndown charts and story points.

But it’s also got to be treated like it’s NOT personal — just like the task cards we put on the table, once they’re out, they belong to the team to probe, question, build upon and even discard as the team sees fit. But still, the emotion-origin ideas at a Retrospective need to be treated as personal — one person said each of them, after all.

So it’s not personal, but it’s all personal. To put it another way, we need to balance thinking critically and objectively with being compassionate and appreciative. By listening carefully and personally, letting thoughts be finished–even if you’re jumping in to agree–you help make the transition from personal to not personal easier. And your team will grow stronger and more quickly.