I recently had the opportunity to attend Agile Australia in Melbourne, with the theme of this year’s conference being ‘embracing disruption’. All up it was 2 days of learning and sharing ideas with 40 sessions and 5 keynotes to take in. The following is a summary of interesting topics and one-liners from various talks with a little bit of opinion mixed in.
Sam Newman and Zhamak Dehghani presented an introductory talk on microservices entitled ‘Building systems that can pivot’. Microservices, for the uninitiated, is an architecture pattern that promotes the use of many fine-grained independently releasable services, built around single business capabilities. The result is a system with a clear separation of concerns that is optimised for speed of change. They positioned microservices as an evolution of Service Oriented Architecture (SOA) that has come from a better understanding of what makes a good service. The content of their talk was brilliant, but rather than repeat it all here, I’m going to focus on a couple of points that especially hit home as we at Tyro embark on our own microservices journey.
Understand the cost of change
The biggest challenge of going from a single monolith to a distributed microservice system is having many services. Many services = more places to look and with finer-grained systems come new sources of complexity; testing, deployment, monitoring, security, fault tolerance, the list goes on. Service availability, for example, is now far more nuanced compared to the binary world of the monolith. No longer is a system just up or down, rather it needs to continue operating and gracefully degrade its functionality based on the availability of each microservice. The big takeaway from this is that a transition to a microservice system should be managed incrementally. It is a significant undertaking with a lot to learn along the way.
You can’t do microservices without automation
There are clearly many appealing aspects of a microservice architecture, especially for developers, but the costs for downstream teams can be massive without the proper toolchain in place. Where a monolith application could be deployed once, you now have potentially 10s or 100s of microservices to build, test and deploy. Multiply this by 2-4 once redundancy and load balancing are accounted for and an operations team can quickly become overwhelmed. This is where automation is key; automate build, automate tests, automate deploy, automate everything. You can’t do microservices without automation.
Newman also used the talk to plug his new book on building microservices. I’ve bumped this one straight to the top of my reading list.
Measure and Learn
A microservice architecture allows us to optimise for change and deliver features faster, but in order to better understand our customers and adapt, we need feedback. The measure and learn stream of the conference provided an interesting insight into how other teams approach feedback. Woolworths teams demonstrated how they used lean in-store experiments with real customers to quickly test and pivot their new mobile app. Developers from TradeMe went out to the streets with tablets, enticing passers-by with chocolate bars in exchange for feedback on their latest web product. The guys from realestate.com.au presented an interesting case study on how they were able to use AB testing and web analytics to tweak a property listing page, demonstrating an impressive increase in conversion rate.
Not only is getting feedback important in the development stages, but the feedback cycle shouldn’t end there. I know all too often I put things out of mind and move on to the next story once a new feature is deployed to production. We saw lots of boards at the conference, but one that particularly stuck with me was from one of the TradeMe dev teams. It had an “in the wild” section with tasks to follow up on once something is actually deployed. A good visual reminder that there is more work to do before a feature is actually ‘done done’.
Martin Fowler, who many engineers would recognise as a senior figure of agile software development, presented an unexpected but noble talk on dark patterns. A dark pattern represents software that has been intentionally designed to deceive a user, such as sneaking an insurance policy into a customer’s shopping cart at checkout. He talked about the ethics of such patterns and warned developers about the dangers and consequences of their usages. After all, behind any evil piece of code there is a software developer who wrote it.
We had the chance to meet with Fowler after his talk and took the opportunity to question him more on the ethical dilemma posed by dark patterns. His response to this was very pragmatic. Put simply, it is a personal choice that only you yourself can answer. Do what is right for you, but be a catalyst for change. I think this was summed up nicely by the guys from TradeMe with an apt quote from their core values: “Don’t be a dick”.
Agile meets Special Forces
One of my favourite slides from the conference was from a presentation by James Brett and Scott Kinder. An agile guy and a special forces guy whose disciplines are seemingly worlds apart, discussing the commonalities of high performance teams in their respective fields. The talk opened with a cracker of a slide that really set the stage for what was to come; “Screw embracing disruption, CREATE IT!”. Not only do successful teams in complex and adaptive environments need to embrace disruption, but they also need to create it. They made the point that creating disruption starts with having a disruptive mindset. The most important weapon you have is your mind (not hardware), treat every day as a ‘school day’ and embrace the opportunity to learn something new. Some spot-on advice that I think is relevant to all.
Overall, a great conference that has given me a valuable insight into how other organisations practice agile and certainly left me with a lot to think about. No one, however, can put it better than the actual speakers themselves. So check out the presentation slides and videos as they become available. Next, on to part 2 for a review of some quality talks on refactoring and pair programming.