We often hear focus on the customer, but what do you do when youcustomers are your coworkers? Developers are the largest group ofindividual contributors in software teams. It’s about time DeveloperExperience (DX) got the focus it deserves! Devs are users, too!Wouldn’t it be great if your user needs were met?

In DevOps, there’s a pervasive theme of automating toil, which many would say contains all of testing. I’m just gonna say it: I come from the testing community. We’re people who constantly look for things we haven’t seen yet, who collaborate across roles, who explore the unknown, and who care about doing the right thing. Does that characterization surprise you? Yes, testing is complex enough to be a viable career and not just a thing we do until we can script it for a computer to execute.

So when I reached my limit of “X is going to kill Y” (in this case, DevOps and the testing profession), I finally went for it and joined a DevOps team as an agile tester. I wanted to see for myself that DevOps was the cultural sea change that would make my job role obsolete. If giving up my vocation was the right thing to do, I wanted to be ready with a deep understanding of the value of the new practices and to embrace the mindset shift. I wanted to be ready to bring others along with me on my voyage.

Free yourself, electron!

When I attended DevOpsDays Atlanta 2018, I didn’t know what the community would be like. Sure, I’d helped to review their proposals as part of the program committee, but who would I meet who would change me for the better? It was my first time hanging out at an event for people who might identify as “operators” instead of just “developers.” Would they welcome me, a person without any operations background?

Although my discernment of future direction is ongoing, I see as much diversity of thought in DevOps as in agile. The afternoon unconference was my favorite experience! This format is less structured, as you might expect from the name, allowing for free-flowing conversations that address the most current burning questions of the attendees. I found operators wrestle with similar collaboration conundrums. My questions and concerns found ready listeners and new proposed solutions (in addition to new questions!). This diversity of thought helped to open up my perspective on what is possible.

Collaboration with people from diverse backgrounds and viewpoints is a competitive edge. It’s also the right thing to do. We want to keep our professional and organizational options open. Distinct perspectives provide a greater ability to handle the breadth of competitive situations we face. We need new voices and different perspectives to make change possible.

I’m particularly excited about the possibilities this year in bringing 3 communities together! Whether you’re someone looking to refine your role in the context of today’s accelerating software delivery cycles or just curious about how much DevOps, serverless, and (Wardley) mapping enthusiasts have in common, this year’s event is for you!

Our call for proposals ends February 28th (that’s today, procrastinators!), so there’s still time to share the unique experiences that only you can bring, whether through a 30 minute session or a 5 minute ignite talk. If you prefer to attend and then propose topics on the fly like I do, the afternoon unconference provides that space for emergent value.

Now I’ve been working alongside many customer proxy team members (e.g. business analyst, product owner, product manager) over the years. I’ve learned how to create testable, executable, deliverable user stories in a real-world setting. I wasn’t going into this talk blind. I just haven’t always focused on the Product role.

This time, I looked at the role with the mindset of what it would take for me to check all the boxes in the “good” list. As each slide appeared, my list of TODOs lengthened. I started to feel overwhelmed by the number of things I wanted to improve…

“How you doin’, honey?” “Do I have to answer?!?”

I walked out of that talk thinking I’m not sure I want to sign up for this epic journey. The vision of the idyllic end state was more daunting than inspiring. How could I possibly succeed at this enormous task? Would I want to sign up for that? My initial reaction was no! How could I take on all the technical debt of stretching into a new role like Product? How long would the roadmap to “good” take?

Analysis

When I evaluate things off the cuff, I often consider good-bad-indifferent. Maybe knowing what “good” and “bad” look like wasn’t helping me. I knew I didn’t want to be merely “indifferent”… maybe what I really wanted to know was this:

What does a minimum viable product manager look like?

One of my big takeaways from Problem Solving Leadership (PSL) with the late, great Jerry Weinberg was limiting work in process (WIP) or “one thing at a time” (as close to single piece flow as possible) improves effectiveness. If I take that approach to a PO/PM role, I’m afraid that I would completely fail. So I will reduce the practices to as few as I possibly can without completely losing the value of the role. I want only the *critical* path skills or capabilities! Everything else can be delegated or collectively owned or done without. So what can I discard?

In this thought experiment, I’m proposing finding the least possible investment in each essential aspect of the PO/PM role that would move from bad past merely indifferent to viable (but only just!). I needed to reduce my expectations! If I allow minimum viable to rest somewhere in my default scale, then it fits between indifferent and good. That means I deliberately do *not* attempt to inject all of the good practices at once. So let’s revisit the axes of expertise and the lists of behaviors that are good and bad…

Style of leadership

Minimum viable: leads by example (models behaviors for others without trying to modify their behaviors) + doesn’t worry about respect + consultative decisions + experiments/loosely decides + sometimes available to the team but not constantly + flexible + defaults to already available metrics

For me, this one slides a bit too far toward indifferent… I’m not sure how little I could care about customers and still get away with being acceptable at PO/PM…

Relationship with engineers

Minimum viable: physically co-locates when convenient + T-shaped when it comes to the technical domain (i.e. aware but not trying to develop that skill as an individual contributor) + attends standup + shares business/customer/user information at least at the beginning of every epic + champion for the product & trusts everyone on the team to protect their own time

Approach to continuous improvement

Minimum viable: default timebox + takes on at most 1 action item from retrospective, just like everyone else + plans on an ad hoc/as needed basis (pull system) allowing engineers to manage the flow of work to match their productivity + prioritizes necessary work to deliver value regardless of what it’s called (bug, chore, enhancement, etc)

Product lifecycle perspective

Minimum viable: tweaks customer onboarding in a small way to improve each time + cares about whole cross-functional team (agile, DevOps, etc) + asks questions about impact of changes + allows lack of value in an existing feature to bubble up over time

Sourcing backlog items

Minimum viable: occasionally talks to customers + cares about whole cross-functional team (including Support) + backlog is open to whole team to add items that can be prioritized + intake system emerges + tactical prioritization

I do have twinges about the lack of strategy here, so I guess I’m looking at this part of minimum viable Product *Owner* (i.e. the mid-range focus that Richard points out in his 10th slide).

Decomposing work

Minimum viable: progressive elaboration (i.e. I need to know details when it’s near term work and not before) + thin vertical slices and willing to leave “viable” to the next slice in order to get a tracer bullet sooner + trusts the team to monitor the duration of their work & to self-organize to remove dependencies (including modifying story slicing)

Running through a sprint

Minimum viable: doesn’t worry about timeboxes (kanban/flow/continuous/whatever) + focus on outcome of each piece of work (explores delivered value) + releases after acceptance (maybe this is just continuous delivery instead of continuous deployment, depends on business context)

Meeting involvement

Minimum viable: collaborates with team members to plan as needed (small things more often) + participates in retrospectives + ongoing self-study of PO/PM

Approach to roadmap

Minimum viable: priorities segmented by theme + roadmap includes past delivery/recent accomplishments + adjusts communication as needed/updates for new info + flexible timeline in a living document + published roadmap accessible to all stakeholders on self-serve basis

Surveying/user testing – chat program that both team & user can access

Analytics – NPS score informally collected from customer conversation

Product visioning – I think this goes in with Roadmap for me?

So I’ll agree that the PO/PM role is critical and necessary. I would like for creative problem solvers to fill the role – and to be fulfilled by the role! In order for that to be viable, for people to grow into a Product role, there needs to be education on how to begin – and it can’t be spring-fully-formed-from-the-head-of-Zeus! Christening someone PO/PM doesn’t endow them with sudden wisdom and insight. Skill takes time to develop.

Set realistic expectations for beginners. Help teams to welcome people to grow in the role by offering both challenge and support from all the team members. As with any team need, the agile team has collective ownership to solve the problem, not relying on a single point of failure in the role specialist. Having a beginner PO/PM is an excellent time to reinforce that!

If I were a Product Manger, I would definitely prefer to be a full-featured representative of that specialization! However, I encourage you to revisit Richard’s presentation and do your own decomposition of the Product role. What is absolutely essential? What can you do without?

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

Collective ownership for testing starts with understanding testing. Rework your team dynamics to evolve past duplication and improve performance through whole team testing. Take home practical patterns for improving your team’s collaboration on testing. Because teams who own testing have more confidence in the customer value of their results.

As the Pragmatic Programmers say, “refactoring is an activity that needs to be undertaken slowly, deliberately, and carefully,” so how do we begin? In this session, we will experience the complex interactions of an agile team focused on demonstrating customer value by answering a series a questions:

Where do testers get their ideas?

How are you planning to accomplish this proposed testing, tester?

Why not automate all the things?

Who is going to do this manual testing and how does it work?

How do we know whether we’re testing the right things?

Build your own list of TODOs from these various practical collaboration approaches and begin deduping your team’s testing for a better first day back at the office.

Key-Learning

Approaches to handle objections to executing the testing work

Ways to mentor test helpers, including pairing

Investing in testing the team believes in

Understand how other team members have been testing the work so far

Advising on opportunities to inject test thinking into all of the team activities, from story writing through to unit testing, to make the system more testable

Abstract:
Think manual testing is waste? Think again! If you’re not learning when you’re testing, you’re doing it wrong! People exploring systems can be your best defense against unknown problems and your greatest way of finding unexpected opportunities.
While automation is well adapted for repeating the same thing over and over again, human beings are great at doing things differently.
Doing is not enough! We need to think during our review and examination processes to improve outcomes. How do we design manual exploration to provide value in today’s fast-moving development culture?
Come to this workshop for hands-on experience with the full lifecycle of exploratory testing charters.

Announcing Ministry of Test Atlanta

Last fall was the last of our Software Testing Atlanta Conference (STAC) events. An attendee at my Intentional Learning Workshop chatted with me afterward. I mentioned that I have been a local meetup organizer and have struggled with how much control to retain. My attendee urged me to give the meetup back to the community and I have been pondering that ever since.

I’ve been the primary organizer of the Software Testing Club Atlanta meetup since we began as an affiliate of the UK-based Software Testing Club in October 2013. My charter has always been to serve and develop the local testing community including connecting it with the global virtual community. Not everyone agreed about including digital attendees, but I am willing to experience the friction of a virtual meeting to help people to attend who otherwise would not have a chance. Inclusion matters to me.

I also prefer small groups and experiential events/activities that Justin talks about. I have never had a goal of increasing the size of our meetup beyond what a single facilitator could manage in a workshop.

STAC was just a bigger extension of the meetup for me. I always wanted to reach more people in the local community, so putting together a conference focused on my geographic region was a great chance to bring new local voices to the fore. I never wanted it to be a big formal event, so I’m working on an ATL software testing unconference for the fall: shortSTAC. More on that to come!

This has been an awesome ride over the last 3 years, but we’re re-branding and branching out into our very own Meetup now known as Ministry of Test Atlanta!

As part of our reboot, I wanted to share some thoughts on what challenges a meetup organizer confronts every month and why monthly events are so difficult to sustain!

Meetups are tough for reasons

1. Location, location, location!

People interested in testing are spread out across ATL and traffic suuuuuucks. Plus, I have no budget, so someone has to be willing to host for free or sponsor the venue fee $$. I don’t want to hold the meetup only in one part of the city since that alienates interested test enthusiasts. Proximity to public transit is something I’m not sure matters, but it would make the meetup more accessible to more testers.

Over the past 3 years, we’ve had completely different crowds depending on which part of the city we chose. I preferred to rotate locations to give everyone some opportunity to attend, even though that introduced uncertainty that probably negatively affected attendance… It’s impossible to make the “right” choice for everyone who *might* attend…

Anyway, I work at VersionOne now and that means I can host, so that’s one variable taken care of!

2. Scheduling

We hold meetings on weeknights assuming that people are more likely to do work-related things on workdays – and would be more reluctant to give up their weekend fun time to work-ish things. Getting all of the stars aligned to schedule these meetups monthly *and* give enough time for people to RSVP and then work out the logistics of showing up… Timing is hard.

Since we tend to meet after work, providing food and drink encourages people to attend, but that’s not free… and I have no budget.

3. Funding

Food and drink cost $$ – someone has to be willing to sponsor the foodz, and drink

Possible sources of funding:

donations from individual attendees

local sponsors (probably companies)

I’ll have to check on company budget to see whether I can do pizza & sodas every time but I know I can do it sometimes.

Not everyone wants to present or run a workshop or host a round table or … yeah. People will show up but may not want to provide content. I have to find a willing volunteer to do it for free or someone to sponsor a fee $$.

We infrequently have presentations. Most of our events are workshops or rountables or some sort of interactive experience. My go-to is Lean Coffee since it lowers the barrier to getting groups together and provides value to attendees every time.

I’m definitely interested in scheduling joint events with other Atlanta meetups in the future.

5. Publicity

How do people find out about meetings? I do the social media management, but I have no budget so … mostly word of mouth otherwise? Maybe chat rooms?

I assume that most of the people who want to come to a testing meetup are testers, but not all test enthusiasts are testers. We’ve had development-types show up, so I want to keep it open and inclusive.

7. Viewpoint advocated

I refuse to insist people agree with me. I won’t call it a context-driven testing meetup or an agile testing [PDF] meetup because I want to welcome people who subscribe to other philosophies of testing. That said, I also don’t want vendor talks (and yes I work for a vendor now). This group is for engaging with ideas focusing on and around testing, not for mind-clubbing or selling or exchanging business cards. Active participation is expected and encouraged.

8. Volunteers

Organizing: While I have always had a core group of enthusiastic participants, I’ve never had a formal organizing committee. Being a one-woman-show most of the time is pretty exhausting, y’all. The meetup consumed lots of my free time. I made my professional hobby the primary thing I did for fun outside of the office for years. Um… not a sustainable model. I do not recommend it. At the same time, working with others means compromise, so consider carefully the tradeoffs and find allies who believe in your mission.

Presenting: Members of my core group have all helped out with content for the meetup – for which I am eternally grateful! I’ve also encouraged other local aspiring presenters to practice on us. Occasionally, someone I know from the wider testing community is in town and joins us to share their wit and wisdom. I resisted presenting at my own event for a long long time… until I needed content LOL

As the resident TestRetreat social butterfly, I made sure to introduce myself to all the new faces, although some of us already knew each other from the internet. It’s always nice to put a face to all the Twitter handles in the tester world. After a leisurely breakfast, we began to settle into business mode, which is actually pretty casual for a group of this size.

As per the usual, I came with some ideas rolling around in my head, but I didn’t have a formal plan until I got up in front of the group to pitch them. I settled on a couple of topics: Doing What You’re Told and Building Community in Testing. After hearing the pitches of other attendees, we decided to combine our forces to address these topics along with 2 other ideas, What is limiting your agency? and Personal branding respectively.

Agency vs Doing What You’re Told

Jesse Alford mentioned that he has often heard people say they cannot follow up on a particular suggestion he made when discussing real world problems in testing on the job. He is interested in what limits people’s sense of agency, or being able to be the change they want to see in the world. I felt this related strongly to my interest in the balance between testing as you are requested to work and using our professional judgment to recommend or simply execute appropriate testing. We had several other collaborators join us to explore these topics.

Although I often prefer live-tweeting sessions, I wasn’t sure how we would structure this conversation. We all gathered around a table to discuss these ideas as peers, bringing our diverse experiences. When I lost wifi early in the conversation, I switched to drawing a mindmap on a large piece of easel paper. I find this technique very helpful for visualizing connections as well as helping me to focus on the conversation as it flows. While that may sound strange to some, my own research into teaching and facilitation approaches indicates that other learners find it helpful to keep their hands busy so their minds can be clear.

Hand-drawn mindmap for Agency vs Doing What You’re Told

First, Doing What You’re Told. If we view testing as a service provided to a business, then a business may request various types of testing, effectively buying a requested unit of testing work. The request will vary with contextual variables such as product scope, release cadence, and release purpose. A business wanting to release a minimum viable product (MVP) version of a feature or application has different concerns from a business that has built up an inventory of value ready to deliver that is not yet deployed. In the case of an MVP, the business is looking to explore the market for a particular solution in a problem space. When the concern is idle inventory, the long feedback loop may be related to cost of delay or lack of value realized in a system flow. These motivators are quite different although each has the same desired outcome: deploy a tested set of software features. These requests may address different risk profiles, including the need for both internal and external feedback on quality and value. (We could do a Mary Had a Little Lamb on MVP… but let’s stay focused on this session.)

What do you do when your professional judgment is that a business request doesn’t make sense? For example, some industries are regulated with standards and compliance concerns. While these definitions are often vague, the way a company chooses to satisfy them is very concrete. Auditors may have particular requirements or expectations that influence what testers do to provide early feedback about the viability of software implemmentations. However, I have heard from testers in the regulated space that an audit can be a negotiation about how to satisfy a regulation (problem) rather than a mandate of using a particular set of processes and metrics (solution). Sometimes the mandate comes from within a company. In that case, what can a tester do to provide valuable information? When the pressure is focused on counting some form of testing work, one option is to use session-based test management (SBTM) rather than manual step-by-step test cases.

What’s constrains your agency?

Jesse’s question about agency dovetailed nicely here. Many testers have reasons that a particular approach cannot work for them in their particular situation. Some broad categories of concerns include inexperience with the proposed way of working, organizational hierarchy control, and motivation.

Inexperience can affect perception of a situation in both the problem statement and in the proposed solution. Sometimes the way we frame a problem limits the solution options we can see, i.e. “Why don’t you just …” For example, if we frame a testing problem as visual validation of a feature and then insist that Behavior-Driven Development (BDD) automation is the way to go, we may box ourselves into the corner of heavily imperative Gherkin scenarios. Alternatively, if we stated the problem of visual validation as automation-tool-supported, we could consider approval testing as a way to quickly detect changes while preserving the element of human judgment that helps us to make progress toward quality without maintaining brittle automation scripts. This may satisfy an organizational constraint such as “100% automation” in a way that empowers people while automating the boring stuff (i.e. visual inspection of every screen component).

Some testers work in an environment of strong command and control from the organizational hierarchy. These testers may live with concerns of being fussed at, e.g. you signed off on this release yet we discovered bugs in production. People higher up the organizational ladder may use their power in negative ways (e.g. sociopathic games) or in positive ways (e.g. sponsoring junior team members to develop talent). An official “open door” policy may indicate that employees were told to trust one another rather than earning trust through their behavior. Let’s say you buy into the policy and speak to someone above your boss’ level. Although you may be simply sharing ideas or asking for information, this activity can be misconstrued as undermining your boss.

Dependency on others could take many forms. This may disproportionately affect the “frozen middle” levels of management who may not feel in control. These managers may have the ability to remove obstacles to providing testing value but not recognize the opportunities. When we form the problem statement in a way that doesn’t make us feel safe to act, we can lose motivation to solve it. Our emotions heavily influence our perception of what we can do. If we feel threatened or fearful, we may spend energy on resisting change. However, when we are willing to be self-questioning, we can recognize when we really can make a difference and choose how to act. Through reflection, we can act effectively with integrity.

One way we can try to reconcile what we’re told to do and what we may choose to do is pairing with our colleagues. This provides a dedicated period of time to ask about the intent of the request. In some contexts, no one tells you what to do, so you may pair with someone else motivated to solve this particular problem. When you choose to work this way all the time (i.e. 100% of your work hours), you can overcome physical separation, whether with colleagues in the same location or working remotely. Pairs can achieve a high level of flow though constant exchange of information and quick feedback on ideas as well as solutions. Some of these solutions may be non-testing mitigation of risks.

We only had an hour together to dig into this rich topic, but it definitely has me thinking. In the end, we should remember that software development is a relatively young industry. Sofware testing as a specialization is even younger. Making room for good testing work involves both hearing what you are told and using your judgment about what you can do in your context to accomplish the goal. We can try small experiments in how we work to see what improvements we can make without asking permission. #SorryNotSorry

Well this has turned out to be a longer and more serious post than usual… I’ll tackle community and personal branding in a follow-up post.

One morning, my office had a fancy coffee machine delivered. The machine was fancy enough that we had training sessions to learn how to use it. The machine’s controls involved a few pre-programmed settings for common usage scenarios. Not being a coffee drinker, I didn’t appreciate the intricacies of preparing a morning cup, so while I was interested in the training it was not particularly relevant for me. I just wanted to know where to get the hot water to brew my tea.

Then, we had a local barista Joseph Yancey join us for a morning of coffee coaching. It was his day off, but he loves the artistic aspects of preparing coffee and wanted to share that with coffee lovers. The coffee machine was still somewhat intimidating to me since I didn’t know how to judge the results of the preparation process. Out of curiosity, I hung around to listen to what the barista had to say.

Co-workers arrived at the office and were ready to start their day. They joined us in the break room and gathered around our visitor. Instead of expounding about the principles of great coffee and the brews and mixtures he preferred, Joseph focused on helping individuals to achieve their goals.

As each person explained the kind of outcome they were looking for, he was very patient in coaching. He noticed the intimidation of trying something out of the ordinary and reinforced the idea that no one should be concerned about failing to produce exactly what they hoped for. Instead, he emphasized making better and better approximations of the desired result to accomplish incremental progress. This created a safe space for individuals to develop new skills.

Each person explained what they wanted and he told them how to refine their techniques. He showed them motions with his gestures and posture as a model but he didn’t take over. Each pair of hands became surer by trying for themselves the motions and mixing. He paired with each participant and brought attention to key moments and opportunities during the process without talking down to anyone. Rather than doing it for them, as he expertly would during his day job, he coached them into greater competence and self-reliance.

I noticed his consummate skill in interpersonal interactions and asked him about it. He said that his love for his craft motivated him to help others to greater mastery. When I mentioned that I wasn’t in his core demographic (as a tea drinker), he was willing to tackle that problem as well, teaching me how to judge the heat of the water produced by an electronic kettle so that I could pair it with the various mixtures with more demanding brewing precision. Even I, an edge case, benefited from Joseph’s enthusiasm and understanding.