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.
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.
If you have a career as a software engineer at some point you’ll be asked to diagram a software system. It might be a system you plan to build. It might be to help explain/document a system that has already been built. Or it might be part of an interview question. These days most people seem to have given up on UML and will create a wild mix of arrows, boxes, circles and words. But there’s a lot of other methods that are useful and the best results usually involve a mix. So here are the techniques I’ve found useful in a super quick way.
One of my favourite things to do with software engineers is to practice together. I like it because often we’re not trained to collaborate and it can be a difficult adjustment. If we throw people into collaborative techniques they can struggle as they try to navigate their way through the process while protecting their reputation. I’ve seen teams so nervous about suggesting a “wrong” idea that they will struggle to suggest anything when presented with a trivial problem. So I like to get teams to practice on something that feels a bit like a game.
I first got to experience an Architecture Kata at the Aglie 2018 conference in San Diego. I got to attend a workshop my Martin Salias on Architecture Kata with Tarot Cards. In his workshop we formed into groups of 3-4 and selected a kata exercise from Ted Neward’s Heroku App – we got some kind of medical advice service. We then got 10 minutes to work on our first release. The Katas ask for a lot so you immediately have to consider what to prioritise so you get that real feeling of a sprint plan being executed even though you’re just drawing out a design.
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.