I’m just back from 3 days at Lean Agile Scotland conference based at Edinburgh University. It was a brilliant location, walking distance to lots of beautiful buildings in the city and to the countryside too.
While there I ran a workshop on estimation, which carefully incorporated some locally-relevant facts (did you know Edinburgh is home to the world’s only knighted penguin?)
I’ve made a few notes here of ideas I heard about at the conference that I’d like to look into further.
Designing teams and software systems
Susanne Kaiser (talk description and slides) presented a real-life story of how she helped move an online school from a slow-to-change “big ball of mud” architecture through several iterations of tech and teams, making good decisions at every stage.
Team Topologies, Wardley Mapping, and Domain Driven Design all get a lot of attention at the moment – this talk walked through in detail the challenges that they’re meant to help with, and how each of them complemented one another.
- To design for flow: look at user needs. How can we organise people, teams, tech to meet those efficiently?
- You can visualise which teams need to be involved in different changes – handovers require high communication and coordination efforts between teams.
- Everything evolves. The right choice today won’t stay the right choice long term – and you can anticipate changes.
Right after Susanne’s talk, Kenny Baas-Schwegler presented how he’d introduced Domain Driven Design (DDD) to a single team and how it had helped them (talk description). I found this a really helpful contrast; after Susanne had showed the big-picture, long-term possibilities of using lots of techniques with lots of related teams over time, Kenny zoomed into specifics. With a team and stakeholders who would like help but have never heard of DDD, how can you get them started?
DDD involves a development team and the business stakeholders and experts working together to agree a shared (“ubiquitous”) language for things, and identify different bounded contexts to reorganise parts of the application around. He says often, teams jump in and start defining and extracting all kinds of bounded contexts at once. That’s not helpful. Instead, ask why: why would this be useful, now? What things on the roadmap/backlog get easier if we do this context next?
It’s also tempting to start with the trickiest, most “core” part of the system. It’s true that’s where most value would be if you get it right – but it’s the highest risk, and for a team that’s never used DDD before it’s very easy to get it wrong. Instead, find a medium-complicated, important-but-not-critical area. Something that matters but is safer to practice on.
Kenny was very keen to get the team to own and understand the technique, and to make decisions about how to apply it. He saw his role, as an architect, was to:
- give control to the team
- equip them with tools to understand system design and how to make decisions
- be there for feedback, advice, support
- avoid being a blocker
“I believe software architecture should be embedded in the team, and done by the team. But that’s hard because a lot of the time teams don’t know how to do that.”
He recommended lots of techniques to help build confidence and understanding – one I’m definitely going to look into more is Bytesize Architecture Sessions. If you asked everyone on your team to draw your system’s architecture, how similar would they look?
I definitely haven’t done justice to the whole talk in these few paragraphs – if you’d like to read more, it’s covered in detail as a case study in this Architecture Modernization book.
The end of programmers
Seb Rose talked about whether low-code and no-code solutions are “agile or fragile” (talk description, slides coming soon). There have been decades of tools that promised business people could build the software they needed, without needing to find and pay expensive developers. I particularly liked an example of “The Last One” – a tool in 1981 that made a young Seb seriously consider not doing computing at university as he’d been planning to.
I’ve since found that Personal Computer article online – it’s fascinating how confident they are that this tool would be industry-changing. There’s other articles (InfoWorld, New Scientist) describing it, and the amount the company who made it (DJ “AI” Systems) spent on advertising it. I’ve never heard of this thing before.
“TLO not only worked (eventually), but, for donkey’s years, its publisher made money out of a consulting business wrapped around the software.” (blog post)
Often the case: You don’t need to search and pay for software developers, business people can make things themselves. Although… you’ll likely need some help. And the people who do that aren’t cheap.
This story mirrors what’s seen with a wide range of no-code and low-code solutions:
- They work, in a limited set of use cases – but make that simple by hiding some essential complexity that’s often needed to properly meet the business domain’s needs as you stray outside the “expected” paths.
- There’s a wide range of things you need to do apart from coding: Consider availability, versioning, regression testing – all of that still needs expertise.
- Often, you replace your need to find developers with a need to hire expensive specialist consultants from the tool vendor to get it working well.
And more
It was a packed 3 days and I have a long list of other notes and further reading I’ve taken away. A few more highlights include:
- Ecocycle planning to help teams learn and improve – I’ve used this tool a little in the past, it was great to hear ideas from Sharon Dale on where else I could use it (session description).
- Oodles of doodles (drawing and a bit of psychology from Nicole Stephan Smith) – I’ve started working through a Visual Thinking book months ago, this has motivated me to get back to it (session description).
- How (agile) charts lie: Nicolas Brown uses lots of measures and charts I recognise (I wrote about some here), and went on to describe pitfalls in how you present or discuss them, fascinating insights he’s found from focusing on blocker metrics, and ways he’s helped teams get started (session description).
- Agile coaching in government: Hannah Dell’Armi and Stephen Mounsey have lots of experience. I loved the “high discipline, low formality” approach, setting expectations with teams, and outlining different engagement types to limit their WIP (session description).
This list is to remind me of things I want to come back to – as the speakers share slides or write their own summaries of the sessions, I’ll get links added here.
And a little FOMO
With multiple tracks running at the same time, there’s always more tempting talks and workshops on than it’s possible to go to – I really enjoyed everything I picked but still would love to know more about some that I missed. Willem van den Ende and Rob Westgeest’s workshop on Stigmergy driven development wins the “most FOMO” prize for me this time — the description sounds really intriguing, and a post-it I spotted in the conference closing session made me hope I’ll get another chance sometime.
