Category: Agile

What’s with the coach titles?

Agile, Quality, Life, Career … everyone wants to be some sort coach these days.

coach sign

I don’t like the term coach. I feel like it downplays the hard work that goes into teaching. I learn and I teach what I learn. I love teaching so much I often do it for free. During uni I volunteered with Robogals teaching kids programming through Lego Robotics workshops. I had my own community radio show where I interviewed Engineers to promote the field. I give presentations at conferences to teach other people my learnings. I volunteer with Sydney Testers to teach my community how to be better at testing.

Is Coaching just asking questions?

As I teach I’ll ask coaching like questions to help you to explore ideas further. I often do this when I play the dice gamed with other testers.

Roleplay dice

If you have an idea while playing the dice game with me I’ll prob you with questions to try to get you to explain your thinking. The dice game is a fun way to explore black box testing and critical thinking, I’ll be running these on a fortnightly basis. Keep an eye out on the Sydney Testers meetup page for more events like this.

The Coaching habit book

“The coaching habit” book would have us believe that coaching is all about asking questions. Just 7 questions in total. Where as I believe the main function of a sports coach is to provide the fast feedback in the moment to help an athlete improve and perform at their best. 

Coaching is having the knowledge to know when to ask probing questions, knowing what questions to ask and how to follow up on particular questions to gain more insights. I use these techniques to learn not to coach.

Mentoring vs Coaching vs Teaching

There might be different contexts where one might be applied over another but I use these terms almost interchangeable. On twitter recently I said I mentored a colleague in giving technical presentations:

And I thoroughly enjoyed the experience. I love helping other people improve. I love this stuff so much, I do it for free. The mentoring wasn’t ongoing though, it was just a 1.5 hour session with the clear goal of improving 1 thing. So maybe I shouldn’t call it mentoring? Well I view it as a mentoring session, but I also taught content and asked coaching questions. All three; Mentoring, Coaching and Teaching were all involved in this situation.

Here’s the review of that session:

Review from Tania Dastres for a technical presentations workshops

Teaching is Learning

But putting together a blog post, workshop or lecture I consolidate my own learning into key take aways. It helps me practice my communication and I learn to exchange ideas more effectively. The best teachers are constant learners.

Maybe I’m jaded because I had a bad experience where a job with the title “Quality Coach” didn’t quite work out for me but I don’t think there is much point in distinguishing the differences between teaching, coaching and mentoring. I’ll use it all to help you improve.

Agile Australia 2018

On Tuesday the 19th of June I spoke at Agile Australia( access the recording here) on how to get more people involved with testing. You can access my slides; The bug hunt is on. I proposed 5 activities to help get more people involved with quality:

  1. Bug Bashes
  2. Bug Bounties
  3. Dog Fooding
  4. Knowledge sharing practices
  5. Soap Opera testing (you also watch the first three minutes of this video)

Sketch notes

Here are all of my sketch notes on the presentations I attended;

My personal highlights where Nigel’s talk on “Agile is the last thing you need”:

And Martin Fowler’s talk on “the state of Agile in 2018”:

Steven gave an interesting talk on visual strategy maps:

Running a Bug Bash

For any solo tester out there I recommend leading a regular bug bash/mob testing activity. It’s an activity you can run at the end of a sprint/feature dev cycle. You invite the team, get some snacks/beverages together and get everyone testing for around an hour.

Setup

You might want to make sure you have good device/browser coverage by ensuring everyone is set up with data/devices before hand. You might also want to prepare some help docs to help people get started. I like to have a mindmap on coverage ideas prepared before hand so people have a visual indicator of what they are testing. I might also create a bunch of test accounts before hand and distribute them to the team.

I use this whiteboard for running bugbashes at Insight Timer; regression on the left, what’s changed recently in the middle and “other” things to consider on the right

Light Bug reporting

You should encourage light weight bug reporting;

  • maybe people write bugs on sticky notes
  • add bugs to a shared spreadsheet
  • or raise Jira bugs directly from Slack using a /jirio create bug shortcut

The focus should be on finding bugs, not getting caught up in how to report them. You can always clarify issues further after the bug bash if you need more information.

What to test in a bug bash

I have a 3 step heuristic for deciding what to test (think; guide or rule of thumb):

  1. what’s changed recently? Change introduces new risk. what features have been built? What code has been refactored? What libraries have been updated? Focus the team to test these areas first
  2. Regression testing. Have a checklist of at most a dozen scenarios of core functionality (maybe around registration, payments and the main stuff people do with your product). Ask people to consider these cases while doing 1), maybe ask people to put there name next to a case when they test it so you can get an idea of coverage
  3. What other testing should/could we do? Sometimes it might make sense to do a pen test bug bash session or a performance testing bash or a cross browser test bash but it doesn’t have to happen every time

Test in Production

If you can; test in production. There’s no environment quite like it.

Put on your ruby red slippers and repeat after me, "there's no place like prod"
Toto, I’ve a feeling we’re not in Kansas anymore – Wizard of Oz

But if you can’t test in production, make sure your test environment is stable, your data is set up and you’ve given your team the “Do Not Touch except for bug bash testing” request.

Post Bug Bash

Make sure to thank people for their time, count up the bugs and give kudos to your best bug hunter. Testing/Quality is a team responsibility after all. Send out a thank you email with results and award trophies. I’ve handed out this trophy of a rhino bug in resin on a trophy base to our number one bug hunter before:

rhino bug in resin on a trophy base
Bug Bash Trophy

Agile and Stress

I was having a chat with an old colleague on LinkedIn today (Brian Osman) and we were talking about Agile. The question was, “how does Agile at Tyro differ from <Client>*?” My conclusion was that by focusing on certain “Agile” rituals an artificially high stress environment can be easily created.

Here is this conversation:

Bosman:

Samster! How’s it going at EPAM? All good I hope 🙂 . Hey just a question – do you guys *do* agile and if so how does it compare to Tyro?

 

Samster:

There’s lots of people in EPAM who do agile but in the <Client> office in my little corner there is no mention of agile, no Kanban boards, no daily standups (in my team). Every team is encouraged to develop their own process. E.g. my manager at <Client> often doesn’t come into the office until 10:30-12pm so a 9am standup just wouldn’t work. He has kids and often works from home. I know the EPAM cloud support guys we have here in Sydney have standups and mostly deal with support tickets so their work is fairly regular.

So with my manager we have a sync doc that I fill out every day on what I’m working on with a breakdown of roughly how much time I’m spending on tasks. Roughly half my time should be spent on bug triaging and trying to mainstream that process across some of the Sydney teams (about 70 developers/designers/PM’s and researchers) and the other half of my time spent on helping those teams with feature testing. This sync doc is in place of a daily standup and we have a sync up once a week where we go through it and look for improvements. There’s no sprints, no regular retrospectives. The <Client> guys will tend to work based on quarters (3 month cycles). Higher up management will set certain goals for the quarter and every team will set their own goals that hopefully line up with those.

So atleast in my little bubble at <Client> there is very little”formal” Agile but product excellence is a heavy part of the culture.

The funny thing with Tyro’s agile is it didn’t really support flexibility. A bit of an oxymoron in a way.

The context of <Client> and Tyro is vastly different too. Often the guys in the Sydney <Client> office have to collaborate with people all over the world, so they will often have conference calls with guys from Mountain View in the morning, often taking these calls at home and maybe conference calls with India in the afternoon. I have a weekly sync with one guy in India who helps lead the team that is responsible for communicating with public transport providers. The ops team for <Client> project that I’m working on is based in Seattle.

On a side note, I have heard stories of <Client> bringing in agile experts for coaching/consulting to learn about it. They usually bring in the guys that write the books on the stuff because <Client> has that kind of pull.

 

Bosman:

That’s awesome! It’s something like I just read from a <Client staff member> and something I like…lower case agile. Figure out the problem yourself and make your own rules (but don’t break the law….and be nice!). Thanks Sammy! I’m writing a report for a team I’m coaching at <Somewhere> and they want to compare this with places like <Client>. I think they’ll be surprised 😊 .

 

Samster:

Yeah. Otherwise things are going pretty well. No one has kicked me out yet. There have been a few days where I felt I wasn’t good enough to be at <Client> but it wasn’t really as stressful as starting at Tyro was. I think a lot of companies aspire to have a culture like <Client> but that’s actually pretty expensive, but nicely liberating. I think companies also often miss the point of <Client>’s culture, I guess they see the free food and games rooms and think that’s all you need to emulate <Client>’s culture.

I think the whole point of agile, is the being able to adapt to a rapidly changing environment. In the context of <Client>, sure there are some areas of the business that are constantly evolving but focusing more on product excellence tends to put a slower spin on things. There’s a focus on facilitating fast feedback but it’s to help make work easier, not to adapt to the market. There’s no mantra of ship it quickly, but there is a huge amount of effort put into supporting engineers get new code into production. Even <Client> uses a giant spreadsheet of manual test cases for Android/iOS <Client> maps apps on top of all of their other checks and balances.

There is a lot of process involved with getting a new feature into <Client> maps.

Maybe the over emphasis on”Agile”, and adapting quickly creates an artificially high stress environment. There’s always this push to beat competitors to market, to get this work out the door this sprint, to be constantly, “Go Go Go”. People don’t function well under stressful situations and that constant stress can’t be that healthy.

 

Bosman:

I agree with your point …. I don’t know if they’ll meet their growth targets and I don’t know if staff will feel happy about being ALWAYS under the pump so to speak…

 

*<Client> = I work client side as a contractor. I can’t officially say who this client is (because contract) but I get to help test an android app you might use for mapping and navigation. The Client is pretty well renowned in the tech space.