Agile will FAIL

25 Friday Oct 2013

Posted by claire in Agile, Agile2013, CAST 2013, Experiences

The closing keynote at CAST 2013 was Scott Barber and Rob Sabourin describing takeaways from each of the talks of the conference, bringing together many different talks into themes or striking moments. As a speaker, I was on tenterhooks waiting to find out what Scott would say about my talk. It was not what I expected, a moment from before my talk that he described as a “kick to the head” (in a good way):

He pointed out that I was emphasizing empathizing with people with different experience and perspective, which was important enough to say explicitly before I began my talk. So with that in mind, I want to talk about a foreign perspective I encountered at my other software conference of the year.

At Agile2013, someone taped large sheets of sketch paper to the wall with a large writing prompt:

to which many people replied in various ways during the week. Some of these responses were rebellious, resisting the seeming prophecy of failed agile. Others felt trapped by unresponsive or rigid organization behavior and hierarchy, industry regulation, or even customers. Contributors felt that companies with only a shallow understanding of agile or simply name-only “implementation” had no real difference in the way of working. Culture weighed heavily on the minds of attendees: belief, passion, desire, emotion, infighting, courage, trust, support, motivation, thinking. So people problems were at the heart of most expectations of failure.

To me, the most provocative perspectives I saw on that wall were not focusing on agile but on the demonstrated value delivered through whatever works, focusing on outcomes. Today, a friend pointed out a Mike Cottmeyer article from 2009 that discussed defining value in agile but at the enterprise level in terms of real business outcomes:

As an organization, we know that we need to deliver value as fast as possible… but we can’t figure out how to apply the small team concepts to our particular business problems. That’s why you get the classic “agile will never work here” comments. There is an inherent disconnect between the team level guidance agile methodologies talk about and the bigger concerns your senior executives are struggling with. There is a gap between value at the team level and value at the enterprise level.

Four years later, Agile2013 conference attendees are still wrestling articulating delivery of complex business objectives to business leaders. And while I also struggle with messaging how my work provides value to the enterprise, I’ve never experienced an agile transformation and so it hadn’t occurred to me to wonder whether agile could succeed. It’s always been business-as-usual, in my experience.

The full (transcribed) list from the Agile2013 wall:

We think we are “Agile”
The concept of “dedicated to one task at a time” is not supported!
They won’t change
- Response: “They”? Maybe this is contributing to the problem
Because CEO manages with fear and intimidation
… Only focused on changes in development teams; not looking at whole value stream (product ideation & management)
No buy-in from the business
Duplicitous product owners (two masters)
because of our culture
- Response: √
because my customer prefers waterfall…
Because the company wears “agile” as a label and yet does nothing to remove the bureaucracy and obstacles teams face daily while trying to implement agile.
- Response: √
We lose trust in each other
… Adoption is done because of convenience not because of conviction.
We are different
- Response: … Just like everyone else who has done it.
XP NOT DEAD!
Our egos are bigger & more important than the company goals
A re-org will set us back to the beginning, again and again. (weekly)
- Response: √
Of me.
…Insufficient support from leadership
- Response: Totally agree
Different part of the biz use different types of agile
Deeply hierarchy…. Project leader doesn’t want Agile.
my leadership team no longer believes in it 🙁
… it’s counterintuitive & hard to practice
Because agile is a state of being… NOT doing! Agile is grossly misunderstood… SADLY!
… because Agile is not the goal. Agile is simply a MEANS to and END
- Response: Agree!
We only fund CAPITAL projects
Because I just think on the consequence not the cause. We should be able to teach the noble truth behind agile methods. Teach that discipline is not a fantasy. If we try hard as a team we can achieve anything. – She Liang
My manager has to assign work to the team
It does not support SECURE software (ISO27000 or code analyzers)
They don’t want to change. & no lean leadership.
Too much focus on the mechanics of the process. Not enough on the motivation/passion behind it.
- Response: +1
We have not explained the ‘why’
Not everyone on our team understands it.
It won’t, because I work at Rackspace! 🙂
“Lack of Courage…”
We don’t want it badly enough
Because I’m writing on this wall & I think it will so it will
We can’t show the value
“What we do already works!?”
Crash at current (complex) business model
Jim
Strong and growing PMO traditional structure being instituted
We don’t think by ourselves. We need to think everyday, every time, everywhere!
- Response: Agreed.
Our culture won’t *change*
- Response: √

Q: Maybe someone can clarify that business model remark for me? I wasn’t quite sure what that said…

Fresh Perspective

17 Thursday Oct 2013

Posted by claire in CAST 2013, ISST, Training, User Experience

≈ Leave a Comment

I can’t remember what it was like to start working as a tester. Ten years later, the only impression I have left of that time is voracious learning. So yesterday’s debut of the ISST webinar series focusing on the first 2 weeks on the job as a tester was a good refresher for me.

Ben Kelly gave a description of two distinct new testers and their experiences of adjusting to the expectations for testers. This reminded me of Pradeep’s talk at CAST this year about his “baby shark” new testing trainees. I suppose that shouldn’t surprise me since they’re among the founding members of ISST.

Both emphasized that novices have an advantage: ignorance. While that doesn’t sound like a very positive description, one you might not want to claim for yourself, it resonates with me. Most of my professional progress has been made asking the dumb questions that filled in my ignorance, pointing me in the right direction rather than remaining stagnant.

But ignorance is not enough, merely lacking information one stagnates. Curiosity turns ignorance into action, transforming it into a powerful tool. (I think this is what people refer to as beginner’s mind, though I haven’t studied that concept myself.) Pradeep explains that newbies have a tactical advantage in not having been misled yet. Ben reminds us that while asking questions seems so simple it’s actually deep exploration of context, not just about business content but also about team expectations.

When Pradeep’s freshers (I think I’m using that right, right??) go out into the world to help start-ups with testing, they’re learning multiple contexts. This adds a bit of complexity to the already daunting task of acquiring testing skills. Sounds intimidating, doesn’t it? While these testers get on-the-job training, the start-ups experience the value of a context-driven testing approach focused on providing business value, which shifts from business to business.

Ben and Pradeep emphatically drilled us on providing information in the way the consumers can understand. Knowing that they have multiple audiences, testers must be excellent communicators. As an intuitive person, this intimidates me – and it sounds like other empathic testers may have similar trouble. I took my first stab at messaging about testing with members of my product team since that was most familiar to me. However, test reporting above the product team hasn’t been a big part of my career so far. My primary approach there has been getting to know the end users.

I know this webinar was aimed at less experienced testers, but I’m reminded that I could use a fresh approach myself. Like some (formal) practice in session debrief? Joining forces with sales for product demos? What approaches keep test reporting fresh for you?

Image credit

Testing For Humans? Try Empathy

11 Friday Oct 2013

Posted by claire in Context, Experiences, Experiments, Personas, Skype Test Chat, Soft Skills, Test Retreat, User Experience, User Stories

≈ 1 Comment

Two months ago, Matt Heusser organized Test Retreat and I attended, along with 27 other testers open to new ideas and wanting to change the world. Sound a little ambitious? Let’s find out!

My first blog post in this series is about Michael Larsen‘s Testing For Humans, which he was unable to live blog due to presenting. 🙂 However, Michael did post Alessandra Moreira‘s notes in his live blog of the event.

Fortunately, I was able to live-tweet the talk that he described as:

Testing for Humans: It’s Sticky, Messy and Very Satisfying

Abstract: Software development is a beautiful thing. We often create amazing ideas and features that would be wonderful… if only those pesky humans that end up using, abusing, and mis-understanding our brilliant code weren’t part of the equation. Unfortunately, we’re all in the business of developing software for people (yes, even when it’s machine to machine communication, it serves human beings somewhere. What are some ways that we can approach testing software outside of the theoretical ideals, and actually come to grips with the fact that real human beings will be using these products? How can we really represent them, test for and on behalf of them, and actually bring in a feature that will not just make them happy, but represent the way they really and actually work, think and act?

Expected Deliverables: An excellent debate, some solid strategies we can all take home, and some “really good” practices that will be helpful in a variety of contexts.

My take-aways were:

People are imperfect so ideal users aren’t enough for testing.
By definition, a composite of many people (e.g. user persona) is a model.
Too many user descriptions based on small differences is overwhelming, not practical for testing.

On Wednesday night of this week, I joined Christin Wiedemann‘s regularly scheduled Skype test chat with some other lovely wonderful tester folks and we focused on empathy in testing. We wrestled our way to some working definitions of empathy and sympathy, which was much better than shallow agreement though it took a bit of time to establish. We agreed that testers need to observe, focus on, and understand users in order to serve them better. We find that empathy for our users and passion for our testing work go hand-in-hand since we care about helping people by producing good software.

Then we struggled with whether empathy is an innate trait of a person testing or whether empathy is a learnable skill that testers can develop through deliberate practice. (Go watch the video behind that link and come back to me.) We concluded that knowing what others are thinking and feeling, getting inside their skins, in the context of using the software is essential to good testing, though this might require a bit of perseverance. This can go a long way toward avoiding thinking we have enough information just because it’s all we know right now.

As I mentioned in the chat, I’ve found that user experience (UX) design is an amazing ally for testers. One tool that helped me to develop more empathy for my users is user personas. (Later, I found that forming user personas of my product teammates helped me to develop empathy for them as well.)

I immediately took to (end) user personas as a natural progression from user stories. After all, user stories are focused on value to and outcomes for a particular group of users. Describing those users more specifically in a user persona dovetailed nicely. Rather than some sterile requirements that never name the user, identifying a role – or, even better, a rich symbol such as a named primary persona – focuses the product team’s efforts on serving someone by helping us to understand the purpose of the work we do.

We also discussed interviewing users, visits to users, and experiential exercises as techniques to help us call upon empathy when we are testing. In my work history, I’ve been fortunate to hear about my UX team’s great work in a collaborative design workshop, to contribute to designing ad hoc personas for my product, to participate in a UX-led contextual inquiry, and to log actual usability sessions led by my product team’s UX designer. (Yes, my fast fingers came in handy. Yuk yuk.) My innovation days team developed a usability logging product that evolved from an existing solution I tested/used in those usability sessions, so I was a natural fit to test it. I’m curious about empathy maps but haven’t tried them myself yet.

It’s fair to say I’m a UX-infected tester. More than fair. I identify with the curiosity I see in the UX profession and I admire the courage to kill their darlings (carefully crafted designs) when evidence shows it is time to move on. After all, we’re not building this product to marvel at our own cleverness but instead to serve humans.

Image credit

Tea Time

05 Saturday Oct 2013

Posted by claire in Experiences, Exploratory Testing, Tea-time With Testers

≈ 3 Comments

A little history

So as you may have gathered, I’m an American. But not just any American. I’m from The South. In fact, I’m a very special kind of Southerner: the mythical Atlanta native. (Though some would argue that prevents me from being really Southern.) While most of you are likely to pass through our airport, I was born and raised here. That has resulted in a certain expectation when you mention the word tea (i.e. it should be used in the phrase “sweet tea”). Now Southern sweet tea isn’t “one lump or two” but more the kind of thing that induces diabetes. You don’t make it by the delicate little tea pot, you make it by the gallon and it’s always caffeinated. If you’re feeling really fancy, then you make sun tea. Carefully. Or you mix in a bit of lemonade and voilà, Arnold Palmer. The important thing to remember here is to serve it sweet – and cold.

Wait, what?

So you can imagine my curiosity when I discovered that most of the world drinks tea hot and brews it from “loose leaf” not tea bags. What’s that about? I had to find out! When I mentioned it to a friend, she showed up at my house bearing a beautiful enameled tea pot as a gift. It was time to learn a few things. I made a foray to a local tea shop and discovered that not only were there non-black tea options out there, but not everyone drinks it sweet. (Okay, so I might be livening things up here a bit, but it was still rather revelatory that this was a complex process.)

An app for that

I found out that the retail chain Teavana has an app. I decided I could use some help with brewing tea when my friends were not available to tell me what to do, so I downloaded it onto my smartphone. While the app clearly has a revenue purpose, driving you to purchase their detailed catalog of products, directing you to their online shop or to a local store, and showing recommendations for blending teas, it also has a tea timer. So I tapped on the brewing icon and stopped to investigate.

The first thing I noticed was the list of tea types that defaults to having Oolong selected. I don’t even know what oolong tea is, so I tried tapping the icon for additional information to no effect. I thought about referencing their catalog of Teas with its detailed descriptions of tea varieties in order to understand it better, but I didn’t see that option in the buttons at the bottom of the app. Accepting this usability problem in favor of actually making some tea right now, I went for the old standby and selected Black Tea. The generic black tea brewing instructions included measuring a volume of tea, but since I typically brew more than a cup at a time I had to do the math. No way to set up a preference for a full pot of tea here. The usability could use some love.

Some science

Then some perplexing data: 195 degrees. While I’m American and appreciate this default to the Fahrenheit temperature scale, I don’t have a kitchen thermometer, only human thermometers to use in case of illness. I was pretty sure that wouldn’t be suited to the purpose. (And it turns out there are thermometer testers! Don’t forget to calibrate!) Now I found myself heading to the internet for more data about water temperature. I’ll admit that I don’t know the temperature of boiling water in degrees Fahrenheit off the top of my head. And the first search result wikipedia article about boiling point, while interesting enough to open in another browser tab, weren’t helping me out here when what I wanted was a simple conversion. Okay, got it. 212 F is boiling and so too high for my black tea. Obviously I’d been doing it wrong my whole life. In the past, I’d just microwaved the water or boiled it on the stove, but now I should care about accuracy. Well that’s why I’m using the app in the first place, to gain some nuance in my tea preparation. The first step is admitting you have a problem.

Let’s do this!

So I get the water hot but not quite boiling and take it off the stove burner with my tea ball filled and ready to steep. Pressing the helpfully labeled Ready to Steep button takes me to an adorable screen that looks like the tea steeper they sell for a single cup brewing. I’m happy to go with it because pressing the Start Steeping button plays lovely music as it counts down and that music varies with the variety of tea. The animation of the water level adjusting with the tilt of the phone with bubbles rising up and tea drifting down is so cute – until my smartphone’s screen goes to sleep. The music cuts right off. I go to wake the phone up only to see the prompt to begin steeping again… What? I glance at the clock, wondering how long I’d played with rocking the phone back and forth. What time did I start brewing? Argh! For a tea novice, this flaw is fatal. My tea comes out just as satisfactory as usual, but I’ve had enough hassle with the app that it’s not a useful tool.

Clearly time to turn off the phone, sit back with my “cuppa,” and find some creative inspiration.

[Note: Although this post is not related to Tea-time with Testers, you should definitely go read that testing ezine too!]

Sick and Tired

03 Thursday Oct 2013

Posted by claire in Experiments, Lean Coffee, Speaking, STARWest 2013, Training

≈ 1 Comment

Brain_Drain
On the first full day of STARWest 2013, I ended up at home with my sick son. (Stomach bug. Boo.) Fortunately, most of the excitement had passed by morning and the day turned out to be blessedly restful, which was essential for this sleepy mom keeping vigil.

We rolled out of bed and sat on the couch watching a cartoon in companionable silence while I poked about on Twitter to find information on the morning’s Lean Coffee to attempt virtual attendance. Since it turned out to be a Google Hangout, my son became much more interested in paying attention, selecting various digital accessories for me – much to the amusement of the other attendees. (Son’s first Lean Coffee? Check. Wearing a digital monocle? Check. Winning at parenting? Check!)

As with any remote conferencing system I’ve ever used, the setup and logistics had their challenges, but I was happy to be included in the event in this small way. The one topic that I could clearly hear concerned sharing conference learnings after returning home.

The classic: presentation to the team.

Many people have blogged about writing – or presenting – a great trip report. Usually these start out with advice for writing your conference attendance proposal to include some language about teaching what you learn, perhaps at the prompting of your boss. At the conference, you take great notes, perhaps even writing up your report during a layover on the way home. Upon your return to the real world, still on a conference high, you set out the conquer your problems with the grand visions of a better work life only to confront business as usual… which you will somehow overcome in a single hour or two of lecturing? It’s a rude awakening. Somehow the top-down decision that the team will learn – from you. right now. – isn’t quite working out. So how do you overcome the resistance to change and really bring home useful lessons?

The subtle: solo experiments as exemplars.

A tactic I prefer is coming home with a list of things to try “on Monday” when I’m back in the office. I think of this as a series of small experiments. Matt suggests keeping these experiments isolated to your day-to-day work in order to improve results without running into the dreaded inertia of the system. As they say, big wheels turn slowly. I can certainly see his argument there since past attempts to suggest alternate approaches that radically changed others’ tasks haven’t really worked out for me. I feel a lot of ownership of my experiments and the experiences have opened up my thinking to additional new techniques, approaches, and strategies. Is your pen mightier than the the sword? Will your report really sway your audience? I certainly have tried this option in the past, but teams may find that approach tired, just one more meeting to attend.

How to bring conference learning back to the team? #leancoffee #starwest @mheusser does experiments solo. @g33klady is doing a presentation

— Claire Moss (@aclairefication) October 2, 2013

The novel: long and drawn out denouement.

The new shiny approach that I’m currently tackling is making connections among different presentations and topics to connect them in ways that seem particularly relevant to my work team’s context. My current experiment is a series of smaller presentations, complete with food and succinct snippets (the TL;DR) in emails that will link to blog posts (the deets). Gradual exposure seems better than bombarding a team with new information in a one-time brain dump. I just hope no one gets sick of my weekly missives!

I’m putting together Lunch-n-Learn presentations and weekly email/blogs to distribute. Less info dump, more learning #leancoffee #starwest

— Claire Moss (@aclairefication) October 2, 2013

As the conference delegates adjourned to attend the regular sessions, I remained sitting with my son. It might have been the exhaustion talking, but when he asked me for my mobile phone I gave in. Within minutes, he found an odd interaction (bug?) in the mobile Hangouts app and shortly afterward froze Angry Birds with a feathered missile in mid-arc. Natural born tester, I tell ya. Making his momma so proud it was easy to forget the sickness and fatigue.

Update from this morning’s Lean Coffee!

Going to use #LeanCoffee as the way to share what I’ve learned at #starwest with my team

— Hilary aka H-Bomb (@g33klady) October 3, 2013

Image source

aclairefication

~ using my evil powers for good

Monthly Archives: October 2013