We often hear focus on the customer, but what do you do when you customers are your coworkers? Developers are the largest group of individual contributors in software teams. It’s about time Developer Experience (DX) got the focus it deserves! Devs are users, too! Wouldn’t it be great if your user needs were met?
We often hear focus on the customer, but what do you do when you customers are your coworkers? Developers are the largest group of individual contributors in software teams. It’s about time Developer Experience (DX) got the focus it deserves! Devs are users, too! Wouldn’t it be great if your user needs were met?
Abstract:
As a career software tester, I’ve heard rumors DevOps culture will put me out of a job, so I took a job testing for a DevOps team. I’m new to DevOps, but aren’t we all? What matters most is our teams’ intentional decisions to grow our DevOps practices along with our development community.
Join me as I share my experiences blending disciplines, companies, levels of experience, and differing expectations as a member of efficient and effective delivery teams. I’ll describe common cultural and interpersonal problems I experienced while transforming a cross-functional agile team dogfooding a DevOps implementation.
Whether you’re into development, operations, testing, customer support, or product ownership, you’ll leave with concrete strategies for improving your DevOps working relationships to keep the technology running smoothly. People factors strongly affect your DevOps technical outcomes, so optimizing your flow includes improving your people practices.
Don’t feel afraid to ask about DevOps anymore!
Learning Outcomes:
The people factors that strongly affect your DevOps technical outcomes
Leo: Bob, there is a ground-breaking new book, that has just come out. Now, not everything in this book, of course, applies to you, but I’m sure that you can see when you see the title, exactly how it could help.
Bob: Baby Steps?
Leo: It means setting small reasonable goals for yourself one day at a time. One tiny step at a time.
My friend is having her first babies. She shared her wonderful plans for the nursery with us and I saw an opportunity to create something special and new for the occasion.
I’ve blogged before about my crafting habits but not about my design process. Given the reference point of the nursery that inspired my mom-to-be friend, I immediately reached out to a more experienced collaborator, a friend who frequently scrapbooks with me.
We riffed on ideas until we landed on one that intrigued us, and we started to develop it more through discussion. However, given our short timeline, since we intended to have the gift ready for the baby shower, I started to create initial prototypes of the components we planned to combine for our project. Using scrap paper, I cut out the shape that had inspired us the most as a reference point. I made several variations that preserved the color palette we wanted to use, so that even those early attempts would provide better information about the final product.
I sent pictures of these prototypes to my friend so that we could evaluate them together before I moved on to the next small piece of work. She had great ideas for coordinating next steps, so I continued to design and construct independent components, evaluating each as I went.
Once I had gathered several together, I called my husband over to provide a second opinion since he is very familiar with the intended recipients of the gift. He liked what he saw and offered suggestions for additional enhancements that I loved – but I hesitated. While I was in love with my design, would our friends like it?
Having invested this much time and effort into the design, initial construction, and overall style, I was loathe to give up any part of my vision. Then, I reminded myself that while I was spending joyful hours creating this work of art, our friends would spend years in the nursery with their children. No matter what I thought of my design, I had to be ready to kill my darlings. I picked up the phone and made the call.
Our friends agreed to take a look at the in-progress photos, to confer privately, and then to get back in touch with us. To my delight, they loved what they saw! Their vision for the nursery matched our vision for the gift. I breathed a sigh of relief.
Armed with this early feedback, I felt more confident about moving on to additional design and implementation. However, an unexpected illness kept my friend from being able to collaborate, and our work fell behind schedule. Not wanting to show up empty-handed to the party, despite knowing how welcome and appreciated I would be, I put together a smaller sample of our project as well as the latest work-in-progress photos of the whole.
At the party, I revealed one of the most recent developments to the excited couple. Other guests brought lovely gifts, from necessary supplies to handmade blankets. We enjoyed the serendipity of another decor gift perfectly coordinating with our project! The nursery is coming together, one baby step at a time.
While we weren’t able to deliver everything we hoped at the time we intended, we delivered something valuable as early as possible with the knowledge that the mom’s “delivery date” milestone is a bit farther down the road – the only delivery in our project that won’t be early and often.
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.
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 someotherlovelywonderfultesterfolks and we focused on empathy in testing. We wrestled our way to some working definitions of empathy and sympathy, which was much better than shallowagreement 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.
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.
As Agile2013 considers itself a best in class kind of conference “designed to provide all Agile Team Members, Developers, Managers and Executives with proven, practical knowledge”, the track committees select from a large pool of applicants and prefer vetted content that has worked its way up from local meetings to conferences. I have only one talk that fits this criteria since I presented Big Visible Testing as an emerging topic at CAST 2012. I developed several versions of this talk subsequent to that event and doing so had given me confidence that I would be able to provide valuable information in the time allotted and still leave enough time for attendees to ask questions and to give feedback on what information resonated with them.
I worked to carefully craft this proposal for the experience reports track, knowing that if I were selected that I would have a formal IEEE-style paper to write. Fortunately, my talk made the cut and I began the writing process with my intrepid “shepherd” Nanette Brown. I wasn’t sure where to begin with writing a formal paper, but Nanette encouraged me to simply begin to tell the story and worry about the formatting later. This proved to be wise advice since telling a compelling story is the most important task. Harkening back to my high school and early college papers, I found myself wading through different but largely similar drafts of my story. I experimented with choosing a different starting point for the paper that I ultimately discarded, but it had served its purpose in breaking through my writer’s block. Focusing on how the story would be valuable to my readers helped to hone in on sequencing and language selection. Once I had the prose sorted out, I began to shape the layout according to the publication standards and decided to include photographs from my presentation – the story is about big visible charts after all!
Investing sufficient time in the formal paper made preparing the presentation more about strong simple visuals. I have discovered my own interest in information visualization so prototyping different slide possibilities and testing them out with colleagues was (mostly) fun. I’m still not quitting my day job to go into slide deck production. Sorry to disappoint!
Performance anxiety
Despite all of this preparation, I couldn’t sit still at dinner the night before my presentation and barely slept that night. I woke before the sunrise and tried to school my mind to be calm, cool, and collected while the butterflies in my stomach were trying to escape. This was definitely the most challenging work of presenting!
As a first time speaker, I didn’t know what to expect, so I set my talk’s acceptance criteria as a rather low bar:
Someone shows up
No one hates it enough to leave a red card as feedback
When I walked into my room in the conference center, a lone Agile2013 attendee was waiting for me. Having him ready to go encouraged me to say hello to each of the people who came to my presentation, which in turn changed the people in the room from a terrifying Audience into many friends, both new and old. I think I managed not to speed through my slides despite my tendency to chatter when I’m nervous. I couldn’t stay trapped behind my podium and walked around to interact with my slides and to involve my audience more in the conversation. Sadly, I can’t share my energy with you since I forgot to record it. Oh well. Next time!
The vanity metrics
At 10 minutes into the presentation, 50 people had come to hear me speak and at 60 minutes I had somehow gained another 7 to end at 57 people. Thanks so much for your kind attention! I hope I made it worth your while…
43 people stopped to give me the simple good-indifferent-bad feedback of the color-coded cards (which I liked as a simple vote about a presentation) and I received 37 green cards and 6 yellow – with no red cards! Whoo hoo!
Words of Encouragement
Two people kindly wrote out specific feedback for me and I want to share that with you in detail, hoping to elicit some late feedback from attendees who might like to share at this point (Agree or disagree, I want to hear from you!)
Feedback Card #1:
– Best session so far!
– Great presenter – great information – great facilitator
– Would like to see future sessions by this speaker
Feedback Card #2:
Great Talk – speaker very endearing, Her passion for the subject matter is obvious.
A fresh perspective of how Developers and Testers should interact.
Should find ways to engage the audience
Someone else got a kick out of my saying, “I’m serious about my stickies.” and left their notes behind on the table after leaving. So thanks for sharing that. 🙂
One friend spoke to me afterward with some helpful feedback about word choice and non-native English speakers. When I was writing my talk, I was trying to focus on people who would be likely audience members, but I had not considered that aspect of the Agile2013 crowd. Since I was simply speaking off the cuff, I ended up using some words that would have fit in at our dinner table growing up but that would make for tougher translation. And yet, I got some wonderful feedback from Hiroyuki Ito about the “kaizen” he said I made. I can’t read it directly, but Google Translate assures me it’s good stuff. 🙂
uneasy truce
Finally, I discovered that my relationship with a linear slide deck is not a comfortable one. I wanted to be flexible in referencing each of the slides and having to sequence them hampered my ability to respond easily with visuals when discussing questions or improvising during my talk. I haven’t experimented with other presentation options, but I hope there’s an easy solution out there.
During the year and a half of experimentation that included the big visible charts that are included in this slide deck, I read over the following resources, only some of which would easily fit into the IEEE format. This is the full bibliography of my research, as far as I have been able to track down my sources. (At the time, I wasn’t expecting to cite them for anyone else, so I probably didn’t bookmark everything I read.) I hope the following links will prove helpful to you in developing your own big visible charts. Let me know how it goes! And please share any sources that you find helpful. I’m always looking for new inspiration.
REFERENCES
My first dev team was an XP dev team that dogfooded our own digital signage product to display success/failure for the thousands of unit tests in the suite (i.e. single flag for whole suite red/green).
Other eXtreme Programming big visible charts
Although the above resources were all I knew at the time I began my experiments, as I prepared my IEEE paper for the Agile2013 conference proceedings, I was tracking down my sources and came across these other relevant pages & posts that have given me some great ideas of things to try next!
After some discussion in my session about suggesting solutions for distributed teams, I was looking for some digital implementations of big visible charts, but I don’t know how these would work out for you.
