Posted on

Theories that Form an Agile Mindset

When people talk about Agile Software Development people will often cite how important having an Agile Mindset is to the success of any Agile project or team. But I’ve never heard a great definition of what an Agile Mindset is. It’s always a mix of personality traits and problem solving goals that no one can seem to precisely describe.

Part of it is clearly an Growth Mindset and that has been well defined and analysed. But it’s more than just that so I’ve been thinking about what that more actually is.

Continue reading “Theories that Form an Agile Mindset”
Posted on

When Agile is Not Common Sense

It’s been about 10 years since I got my Agile training from James Grenning and started an Agile Pilot with my team. Right from the start I was super keen and got people practicing TDD and Pair Programming even though I didn’t really know if that effort would pay off. I just knew we had lots of problems with the old way so I wanted to embrace the new.

So I’d run my own little sessions with the broader team in Sydney sharing Agile concepts and ideas. Giving us a chance to discuss things and keep learning long after James had left. But often I would present new ideas and a few people in the group would respond “oh of course, that’s just common sense”. Initially I thought it was great as they were embracing these ideas as valuable even though it was not what we were doing before. But after a while I started to get frustrated because they we’re not really listening. If some small part of a concept fit nicely with their “common sense” then they took that on and ignored the rest.

Continue reading “When Agile is Not Common Sense”
Posted on

Products and Customer Need

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.

Continue reading “Products and Customer Need”
Posted on

Inclusiveness

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.

Continue reading “Inclusiveness”
Posted on

Three Ways Testers Are Better Able To Resolve Conflict

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.

Continue reading “Three Ways Testers Are Better Able To Resolve Conflict”
Posted on

Avoiding Giving Advice

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.

Continue reading “Avoiding Giving Advice”
Posted on

Dumb Questions

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.

Continue reading “Dumb Questions”
Posted on

Coaching is a Transferable Skill

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.

Continue reading “Coaching is a Transferable Skill”