Disclaimer: This is a timeboxed stream of consciousness rather than a polished piece of writing. How I express some of the ideas could likely use some work. Also, as always I will inspect and adapt my position on these ideas (maybe even over the course of the article), so please give me any relevant feedback.
This idea triggered from a podcast featuring Seth Godin*. One concept he put forward was a marketing “revolution”. The example goes, no one wants a quarter inch drill bit, they want a quarter inch hole. The idea is you shift from marketing your product to marketing how you fulfill a customers need. He added to this by tracing further up. They don’t want a hole, they want a way to insert a toggle to mount a shelf. They don’t want that they want… and keep going up until you hit something like the feeling of happiness from x. Fundamental feelings of safety, joy, love… these are what people are really seeking in their lives.
I will also include some warning smells along the way. Things that will give hint your design is not testable.
1. Dependency Injection
This is one of the first things you’ll learn in doing TDD. It doesn’t matter if you’re doing London Style or Chicago Style you will eventually hit cases where you need to swap out the real item. It may be because that real object would touch the file system, a database or a network. Or it may be because it forms a convenient seam between your code and something more complex.
Smell: Singletons and classes that new their dependencies.
The past year has been one where I’ve had to focus even more on diversity, inclusiveness and what all that means. I’ve long held the view that diverse teams are better teams as they bring with them diverse experiences and knowledge. That diversity can give a diversity of solutions so it’s more likely your team will apply the best or even discover a novel solution. It’s a theory I hold closely that is backed up my some academic research tool
However I’ve also experienced the high productivity homogeneous teams can experience. It can be much quicker for the team to create social cohesion and disagreements are rare. It can free people up to focus on what they are producing (which for me is software) with few concerns about social interactions.
I’m not talking about “scary conflict”. There is lots of healthy conflict at work when you have a diverse and inclusive team. It might be technical decisions (tabs or spaces?), product plans (high risk or high return first?) or casual choices (where do we go to for lunch today?). When I think of “scary conflict” I think of personal grudges, unprofessional behaviour or confronting office politics. Those conflicts need to be resolved but are much more confronting.
Early on when trying to apply Agile methods to software development I found a lot of the challenges were in the area of software testing. Not just because a lot more automated testing was being done, but because requirements would shift and change rapidly. Many levels of rapid feedback needed to be in place to ensure the development didn’t misstep for too long.
I started exploring more places a focus on testing and quality could be applied. And that led me on a journey earlier and earlier in the development timeline.
There is a famous experiment in behavioural science called the Marshmallow Experiment. In the simplest version of this experiment they sat down a child in front of a marshmallow, the instructor told the child that if they sat there and waited the instructor would come back with an additional marshmallow and they could have both. However if they took the one marshmallow before the instructor returned then that was all they would get. Once the child understood the instructions they were left alone for 15 minutes.
In a recent assessment of people applying for graduate and intern positions at my work we wanted a way to quickly assess them as a group. Ideally we wanted to see their individual skill at work, how well they worked with others and all in under an hour for groups of up to five. So I suggested we get them to do some Mob Programming on a Kata exercise. It wasn’t something we tried before but the idea wasn’t completely out of the blue.
My go to tool in coaching is to ask a question. I used to try and give people advice but I learned that no one listens to uninvited advice. Telling people want to do can work in a position of authority but they wont take the time to ask why you want them to do it differently and are happy to abandon it all when you leave. So I take a different approach and ask them about what they are doing already.
My team has a challenge that I haven’t run into before. We all want the code to be better quality that it is now. However we don’t agree on what “better” is.
Even simple things can lead to long discussions and debates so it was a struggle to get some serious progress. Reviews could get bogged down because a refactoring someone did triggered a debate on its merit. We needed a format to allow us to work through some of the fundamentals and find where there was consensus. So I booked us in to do some mob programming together except we were not going to write new code. We were going to focus on only refactoring.
It’s been interesting over the last year for me as I explore where coaching for software teams and coaching for sports people overlaps. This year I got to be coach for a Roller Derby team which is the first time I’ve called myself a coach for more than a brief workshop. In my day job I’m involved in many activities that have nothing to do with coaching so I rarely call myself an Agile Coach. But to that sports team I am the coach. And while I’ve been involved with Roller Derby for 5 years I have very little training in coaching sports teams so I started applying all the things I’ve learned coaching software teams.