Category Archives: Protip

Work Horde, Play Horde

02 Monday Sep 2019

Posted by in Coaching, DeliverAgile2018, Events, Experiences, Experiments, Mob Programming, Protip, Publications, Soft Skills, Speaking

≈ Leave a Comment

I recently hosted a Magic-the-Gathering-themed tween party for 8 players.

Yes, you read that correctly. 8 players in a format I later learned is called Free-for-All (a.k.a. Circle). Little did I know that most MTG games were smaller, with an “epic” game being maybe 6 players… 🤦

While my husband did some excellent turn-based coaching for the new players – about half of the assembled – I noticed something essential was wrong. The kids were disengaged from the game unless it was their turn to play. Considering they’ve been rabid Pokémon fans, I couldn’t understand how they could completely check-out from a “grown up” monster beatdown game…

Then it dawned on me: the turn rotation was too long. The kids had enough time between turns to be restless from the sugaring-up and general high energy of being together outside of school.

This distraction is the same issue that I’ve seen with attempts at mob programming!

For any reasonably sized team (let’s assume <= “2 pizzas”) trying to mob program, short turns are essential. In fact, I’m not sure that group size figures into the turn duration calculation – short turns are just better!

How long is too long? For me, 15 minutes! Bias yourself to less than 10 minutes, preferably 2-5 minute turns. I’m aware that at-a-glance this feels absurd, but let me explain.

The basics of mob programming are 3+ people programming together at a single computer with 1 person directing the current activity, 1 person hands-on executing the current activity, and 1 person observing/commenting/contributing from the “mob” crowd seated around the computer. (In some descriptions, the “mob” may also be considered as part of directing the activity, but 1 person makes the decision about what to do/try next, so I prefer to differentiate between these roles.) Unlike strong-style paired programming, these roles are insufficient to be mob programming: for a mob, you must also have rotation!

As “circus performers” (a.k.a. mob programming facilitators) for Bryan & Bill’s Three-Ring Design Circus at deliver:Agile 2018, my pair Tim Ottinger and I instituted a 5 minute rotation schedule for our mob of conference session attendees (read: strangers). Our task was test-driven development (TDD) and refactoring of a sample programming project.

Short rotations encouraged:

  • low barrier-to-entry experimentation with TDD and mobbing
  • selecting and trying an idea quickly
  • refining communication patterns
  • collective ownership of goals
  • fast feedback

Tim and I were a bit more merciful with our 5 minute rotations in that we encouraged participants to continue the execution of the previous driver where another “circus performer” insisted on a fresh start (read: deleting code) when TDD automation wasn’t passing/green at the end of a 2 minute rotation (the hard-core strategy of one of our other performers). So much excitement!

In the workplace, over the years, I have participated in pseudo-mobs wherein a single programmer or a pair of programmers consult another team member on particularly challenging aspect of a programming problem. Often, this results in another programming team member chiming in with insight or advice and now we have an amorphous gathering around a single programming work station where the work is being implemented. This is even more likely when the consulted team member is also paired programming (i.e. 2+ pairs collaborating on a complex issue in the code).

While pseudo-mobs definitely help with resolving an issue, we miss out on some of the benefits of the mob structure:

  • explicit statements of intent through navigator-driver pattern
  • everyone having hands-on time implementing a solution
  • everyone directly participating in the decision-making and experimentation
  • single piece flow / avoiding merge conflicts (since only 1 unit of work in-progress)
  • novice or new team members developing shared understanding and receiving training opportunities from the explicit exchange of multiple points of view and potential solutions

Now back to the Magic game! Upon reflection, how would I have changed the game play to optimize for faster turns/better rotation?

The common wisdom seems to be smaller groups for quicker decision-making and turn progression, e.g. 2 player (1v1) games or team play (e.g. 2-headed giant, emperor).

I could also imagine a simplification of rules for younger/newer players to lower the barrier to entry…

Upon further investigation, I discovered a co-operative format for MTG: Horde Magic!

All the players form a group working to defeat an automated “horde” deck. The team members all take their turn together to attack and block. (This reminds me a lot of the mob programming format with a product team assembled to “defeat” a difficult software problem.)

In Horde Magic, if some aspect of game-play isn’t fun or isn’t working well within the rules, the team members come to a consensus as to what works best for them. (The mob can iterate on their working agreements as they work through the problem in order to work more effectively together.)

Given what I know so far, I’m looking forward to trying some new things, both at work and at play. Having a good mobbing experience takes a bit of planning and some skillful facilitation, but it’s the game for everyone!

Minimum Viable Product Manager

29 Wednesday Aug 2018

Posted by in Agile, Agile2018, Approaches, Context, Experiments, Metrics, Protip, Retrospective, Scrum, Soft Skills, Training, User Stories

≈ Leave a Comment

At Agile2018, I attended Richard Seroter’s Product Ownership Explained session, where I heard about bad and good product owners. Product ownership/management has many facets including

  • advocating processes and tools
  • style of leadership
  • customer interactions
  • relationship with engineers
  • approach to continuous improvement
  • product lifecycle perspective
  • sourcing backlog items
  • decomposing work
  • running through a sprint
  • meeting involvement
  • approach to roadmap
  • outbound communication

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…

What’s the least I could do?

Decomposition

Advocating processes and tools

Good: contextual & explanatory & collaborative (fitting process to team + pragmatic tool choices + only important consistency + explains process value + feedback leading to evolving)
Minimum viable: pragmatic minimalism (choose a simple process & let practices earn their way back in as value is explained + choose an available tool + allow consistency to emerge + request feedback)
Indifferent: status quo (follow existing process/ceremony w/o questioning + let others choose tools + don’t justify)
Bad: dogmatism (one practice fits all + adhere to ceremony + prescribed toolchain + standardization + trust process + don’t justify)

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

Customer interactions

Minimum viable: meets with customers at least once + builds casual relationship with a key customer + gets second-hand reports on Production pain + occasional customer visit + default information sources

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

Outbound communication

Minimum viable: allows org to self-serve info + shares priorities with manager & customers + environment for continuous self-demo/trying features + transparency

What are the minimum viable versions of the tools of a product owner?

  • Backlog – list of ideas not fleshed out until it’s time to run them
  • Sprint planning – ad hoc meetings in a pull system initiated by the need for work definition to execute
  • Roadmap – technical vision of system capabilities + compelling story of the product value proposition
  • Prototyping, wireframing – whiteboard pictures + text-based descriptions
  • Team collaboration – a big TODO list that everyone can access
  • 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!

Don't worry, people. I so got this!

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?

What is *your* minimum viable Product Manager?

Organizing meetups

03 Friday Mar 2017

Posted by in Approaches, Context, Experiences, Experiments, Lean Coffee, Protip, Retrospective, Social media, Soft Skills, Software Testing Club Atlanta, Speaking, Training, Unconference, Volunteering

≈ Leave a Comment

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!

Please join us to keep up with our events!

 

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:

4. Content

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?

6. Audience

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

Coaching and Coffee

24 Tuesday May 2016

Posted by in Approaches, Coaching, Experiences, Experiments, Protip, Soft Skills, Training

≈ Leave a Comment

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

Now that’s a coaching experience to start your day off right.

Potty training

29 Wednesday Jan 2014

Posted by in Experiences, Experiments, Protip, Soft Skills, Software Testing Club Atlanta, Testing Games, Training

≈ 1 Comment

STC ATL Dec 2013 MeetupMy first experience with testing games was back at my first testing conference when Michael Bolton gave me a testing challenge at lunch: a rubber ball. I didn’t know what I was getting into, but I knew I loved games. And that is a key aspect of how games help us to learn: getting past our resistance by promising us fun. Since software testing is a complex mental activity, exercising our minds is an important part of improving our work.

After attending several testing conferences, I can safely say one of my favorite aspects of these gatherings is evenings filed with testing games. (That is, games for testers, not testing video games.) Whether you’re rolling the dice (more, spoilers), deducing when a pen is not a pen, building a tower of pyramids, or shouting out “Set!” as you casually wander past, testers love a challenge.

So it was no surprise that John had his game bag already on the table when I arrived for the STC ATL holiday meetup. What I didn’t expect was Disruptus, a new-to-me game. He explained for a few minutes and then we jumped right in to playing. Almost immediately, I flipped over a card with an image of a toilet and the improve card:

Add or change 1 or more elements depicted in the card to improve the object or idea.

TMI

Skip this TMI stuff!

Since we are currently potty training at our house, this was a particularly relevant subject for me. I started rattling off ideas as they came to mind. John stopped me and said that I wasn’t coming up with new ideas but instead listing things that had already been done. While I agreed, I found that saying each of the knowns out loud helped me to clear my head for the next idea to come along.

Ideas that sprang to mind:

You know, for kids

    • toilet seat lock for babies just learning to walk
    • toddler height toilet
    • step stool for standing toilet training (boys)
    • separate lightweight plastic toddler toilet – could be portable
    • folding travel toilet seat for toddler on-the-go
    • built-in potty seat for toddler years that is easily removed for cleaning
    • moveable toddler handled seat for better balance
    • splash guard for boys potty training
    • tiny plastic urinal – I’d seen one once at a kids consignment sale
    • toilet target for potty training boys
    • soft-close lid that doesn’t slam down on little fingers
    • tie-in to children’s book/video for better motivating child (i.e. matches picture) – with audio/musical accompaniment for better motivating child
    • toilet with book rack attachment – also good for adults!
    • tie-in to popular children’s character for better motivating child
    • And of course Pinterest is awash in toilet training ideas…

Adult toilets

    • Dune’s Fremen stillsuit (okay, so that’s not real…)
    • water-conserving toilets – high efficiency, multi-flush options
    • recycling water from washing hands for next flush
    • elevated tank to use gravity for flushing
    • recently read an article about posture and advantage of raising feet using step-stool
    • bidet attachment that I saw at a co-working space
    • soft seat vs. hard seat
    • toilet scent spray that a friend mentioned to me & has ridiculous commercial
    • elongated seat
    • elevated seat for elderly with limited range of motion – vs. seat riser/handles
    • foot pedal to raise/lower the lid without using hands
    • putting the seat back down in the first place
    • self-cleaning – or at least those tablet attachments
    • germ resistant surface
    • I’d once seen a toilet with an automated toilet-seat-cover replacement system
    • I’d seen more exotic toilet options in a local farmer’s market store
    • a friend explained the composting toilet to me
    • chemical toilet/waterless toilet for big events like outdoor concerts
    • urinals – I’d seen a public outdoor urinal in Amsterdam that was just two large crosspieces for minimal privacy
    • device allowing women to stand for urination – thanks, Twitter!
    • chamberpots
    • outhouses
Things I’d never heard of
    • Glow-in-the-dark toilet seat – this would be a big hit with the kids!
    • Squat toilets
    • proximity sensor
    • toilet seat warmer – including power saving mode!
    • electric lifting seats for the elderly
    • female urinal
    • sound cloaking
    • toilet slippers
    • pretty much anything shown in Cars 2 when Mater visits the restroom

Motivation

Of course, it wasn’t until much later (esprit d’escalier) that the thing I really wanted to improve came to mind: I hate toilet auto-flush algorithms. As a happy user of toilet seat covers in public restrooms, I always feel concern about whether I’ll have to contend with a particularly sensitive hands-free toilet. Despite my years of experience, I have not yet mastered the art of evading the motion sensor while placing the toilet seat cover.

I would love to rewrite the algorithm to some set pattern of motions that would distinguish between someone leaning toward the seat to place a liner – and so avoid germs – and someone leaving the stall having completed her errand. Even clap-on, clap-off would be preferable to spray in the face from an unexpected flush.

Protip : My husband takes a 2 foot length of toilet paper and blindfolds the sensor. Manual flush never felt so good.

Training through play

So now that you made it past TMI, let’s get back to the notion of testing games for training testers. Do testing games help testers learn how to test? Many testers are making an argument for this.

John Stevenson is one of them. He uses Disruptus to encourage disruptive thinking that leads to innovation – in testing. Create, Improve, Transform, Disrupt: these 4 approaches are important when designing and executing tests. Finding new ways to remix our tests helps us to focus on things that matter but to approach them in a new way, extending our coverage of various paths and potential usage patterns. My experience with only a few turns of this game left me invigorated and encouraged to try new things at work.

How have you used games to learn about testing?