Friday, October 9, 2015

Contributing in mob programming as a non-programmer

Mob Programming is about the whole team working on one computer, taking turns on the keyboard driving (no thinking while on keyboard), and while not on the keyboard, navigating with the rest of the group. It's single piece flow, everyone working on the same value item.

Here's a worry that re-emerged from a discussion I had, something I've needed to address for myself.
What if I'm a non-programmer, I'm learning but not contributing, I'm just slowing the others down.
Well, I'm a non-programmer and I've volunteered to sit in mobs. I continue to volunteer, to the point that I'm working on convincing my team to mob more with me around. So I've needed to address this, and here's what I learned to pay attention to.

  1. Being there "holding space" for testing/quality has value too.
    There's a weird phenomenon I'm observing when I mob with my team. Quite often during our day, one of the developers glimpses at me without me saying anything saying "should we test that?" or "we'll need to fix that". It's as if they are somehow on their best behavior on testing/quality, knowing that stepping away from testing I'm there to remind us - without me even reminding. They work better when I'm around. Sometimes they even acknowledge that in the retrospectives.
  2. Being there as "the only woman" or "the only non-programmer" has value too. 
    I don't really know how my team mates behave when I'm not around. But I've listened enough to others to recognize that me being different has value too. It might be again that people are on their better behavior. But it seems to be also that me being slower in getting what goes on makes them being clearer in navigating. And there's been observable instances where speaking with me in mind makes things easier for the other developers.
  3. My learning has value in the long term even if not immediately
    When I'm there, I'm learning a lot. I'm learning about details of implementation, dynamics of what is easy and difficult, ways developers go at problems and the syntax of the language we're working. Seeing my developers work creates different models on how I test when I'm without them, knowing where they seem strong or weak.
    If I am just learning today, that learning is in use for me the next time we do this. And I get to live to my motto: every day at work makes me, my brain - the most important tool in testing, a little better. I'm sticking around, I matter just as much as the next guy.
  4. Driving and allowing others to navigate has value too.
    Just taking the keyboard and writing what others tell you, even letter by letter has value too. It slows down thinking and makes thinking clearer. I've noticed me being slow gives my team mates room to jump in to correct the other, just because they want to avoid the mistake being made in my pace. Articulating your ideas clearer is good. I can provide that service when there's nothing else I can provide.
    With few rounds, they no longer need to tell a non-programmer introducing variables letter by letter, but they get to work with concepts. Every non-programmer can learn that, and it does not turn us into programmers immediately. Personally, I think ability to fluently read code is separate from ability to fluently write code, and I can do the first as a non-programmer. I love talking around code, but writing by myself makes me sleepy.
  5. There's stuff I contribute when I speak up
    I've noticed I say particular types of things. I pick up half-sentences that are about domain knowledge to correct it, preventing mistakes from turning into code. I ask about using time on something and if we should try something else. I have answers on direct product-owner-type questions with actionable information of connecting features on detailed knowledge of using the product in all imaginable flows that come to my mind.
    Llewellyn Falco told a story about one of his mobs having a team member who contributed by asking "maybe it's called something else" without knowledge what that could even be, triggering the others to realize the place they were looking at being wrong. They could have been stuck there for quite a while, and found what they needed with that remark that mostly went unnoticed.
  6. Positive feedback is valuable
    I've noticed many of the things I say are about my amazement of how nicely things flow, and how smart my team mates are. Hearing someone appreciates what you do with specific examples isn't an everyday thing. Saying "I feel I did not contribute, you are great" has value in itself. But you might notice that your team returns the favor and lets you know they appreciated you being there - even if you slowed them down. 
  7. Beginner mind
    Adding one more thing on my list. There's a bunch of questions only a true beginner can ask. They are typically "why" -questions. When answering why you do things the way you do, the more experienced one tends to sometimes find out that thing they take for granted aren't. 
Give yourself a chance and try mob programming. If you are worried, don't stay away but express your concern and invite the people you mob with to bear with you. In a mob, you're valuable when you're learning or contributing. Learning is a perfect reason to be there. 

1 comment:

  1. Great post! It's amazing to hear about mob programming from your perspective. It makes me even more assured that it's the way to go. :)

    ReplyDelete