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.
After 10 minutes Marin got us to draw some tarot cards (see above). They represented complications we’d discovered now that your design is live. Could be something like scalability or cost of the service. Or something more specific like internationalisation or accessibility. Martin would interpret the cards for us so for my team he found out our nurses wanted to be able to access the service on their phone and were finding the web interface was not working well for that. The system was also struggling to be responsive at peak loads and we needed to better handle that capacity.
This is what my team created. Not an amazing result but I’m still pretty happy with the basics. We broke up some key elements and considered options to get something out the door quickly like having patients phone a nurse rather than creating a web service for them too. Although we should have asked for a new sheet of paper instead of trying to cram revision 2 and 3 into the area on the right.
Martin was generous enough to let me take home a few decks of the cards so I’ve run the same type of exercise at my work a few times now. Although the Heroku app tends to give lots of web service exercises and I work with embedded software engineers. So I created a bunch of embedded software exercises they can pick from. A coffee machine, a fitness band, a smart doorbell and a vending machine. Last time I facilitated a session they worked on the vending machine and the two teams came up with this.
Pretty messy and both designs had a key problem that isn’t obvious just looking at them. Except for splitting out some hardware interface concerns all the real smarts is within a single component. The flow chart team is just mapping out the actions that system does but it’s all conceptually happening in one area. The other team spit off a GUI but put everything linking to a “boss’ component in the middle. They are missing the architecture structure I would expect them to have in place.
So I went back through the problem a second time and showed how I would try and discover a way to break up the design. I started with a Use Case diagram to map out who the key actors are and what interactions they want to do.
And as I put an actor and an interaction in place I’d add something to the component diagram. Even if it was just adding another interface.
I was very happy how it worked out as I did this with the team and didn’t have any idea how it would look. We could identify different components that could provide something of value without any other components but also had a clear way to work with other components without there being a “boss” component to pull it all together.
I’m still facilitating Architecture Katas and challenging teams to improve their design skills through these sessions. I find it a lot of fun while having a real impact on how we design our products.
One last thing. Martin Salias has a book and it will (eventually) include details on his Tarot Cards. https://leanpub.com/agileArchitecture