Micro Frontend Architecture | Luca Mezzalira (DAZN)

I started the day in the Execution room (it sounds a bit dramatic phrased like this) and didn't really know what to expect with this talk, but it may have ended up being my favourite one. The speaker stated his problem clearly - how to make it work with hundreds of distributed developers/teams - and also noted that the solution he came up with challenges common software development wisdom, but to keep an open mind.

The idea is to share absolutely nothing. Not even a button. Don't create a library of shared components, like headers. Really, how often does your header change anyway? Trust your developers. They can duplicate and maintain this. The goal is to minimise dependencies. Don't centralise.

The rest is structured based on "Domain-Driven Development." Each team has their own domain (e.g. Catalogue, Subscription, Payment, ...) and completely independent technology stack.

The benefits:

• Quicker on-boarding, because you only need to understand your own domain deeply
• Easier to scale teams
• Freedom for developers to innovate and own something end-to-end

He also mentioned the positive impact on turnover. In London, it's apparently not uncommon for developers to change company every year, year and a half. This makes it easy to try new technology which is often the main reason to jump ship.

There are frameworks that enable this nowadays, like single-spa and frint.

Planning your Agile Architecture | Will Demaine (Fat Llama)

This was an excellent talk, and well delivered as well. The speaker described the steps you may want to follow to modernise your application and enable a more agile architecture, from lessons learnt first hand through different companies. If I had to undertake a project like this I think I'd find the slides or recording again to refresh my memory first, but for today my key takeaways would be that this is a long process that you want to tackle iteratively, so that you can continue to deliver business value along the way. No one will let you just take off and deliver nothing new for 8 months while you rewrite the thing from scratch.

Have solid foundations in place (monitoring, feature flags, ...) before starting. Take your time and do it right the first time or they won't let you migrate more services!

Another point I found interesting: create a gateway for the clients, the things that you can't roll back like mobile apps. Even if it's just a proxy to start with.

Embracing empathy | Tim Hudson (Adyen)

Pie charts bad. Bar charts good.

(Also, look into the Design Sprint / Design Sprint 2.0 books.)

Solving Problems to Build a Compelling Product | Deborah Clarke (Cartrawler)

User research is vital but not the only important thing. Combining with other incentives can lead to better focus and great breakthroughs. Innocuous, small moments of delight can increase your conversion rate.

A Journey from Complexity: Reducing Technical Debt | Fabrizio Fortunato (Ryanair)

Interesting to follow the evolution of the RyanAir front page over the decades! Some tidbits I found of interest:

• Impact of page load. Any speed increase has a direct impact on revenue.
• They use "micro-pages." Concept similar to micro-frontend except it relates to full pages, each page is its own app. So everyone is only responsible for their own page independently, and loosely coupled. Single SPA per page, that can be released independently but still has shared components (interesting contrast with micro-frontend above).
• They eventually wrote two different apps for mobile and web, as optimising for one over the other never quite worked and only served in increasing complexity. Now optimised for each flow. Still haven't decided whether to use mobile or web format on tablets.
• They use GraphQL, serverless, Brotli.

Design and prototyping | David Hoang (One Medical)

• Prototypes should be low cost and provide high insights. The goal is learning. Having a prototype together with a vision/roadmap is powerful.
• "Validating" a prototype or design is about gaining insights. About learning. Not about proving something right or wrong.
• Design is not magic, it's a rigorous process.
• Include User Testing in every sprint.

Prototyping is successful if you get insights that provide value to your user.

The examples related to medical applications were compelling. From paper (e.g. stuck onto a 3d printed watch model, to test for smart watches ahead of releases), to powerpoint, to node-based prototyping, to Figma.

The tools we use: Challenging dogma in the design process | Emmet Connolly (Intercom)

Tools influence output, and can even generate trends.

Use these tools and remain sceptical, don't let the tools push you around and end up with a design monoculture (noticeable in the history of the web).

"Design Ops" - a concept I hadn't heard of.

Ensuring the Success of your Remote Engineering Team | Panel

I really liked that the conference kept the talks to 30 minutes, but I think that's one case where it would have been better to get an extended timeslot, maybe 45 minutes. As it stands even with only two panelists (+ one moderator) we barely had time to scratch beyond the surface.

Keeping a budget for internal face-to-face interactions, some kind of annual get-together has a great impact on morale and engagement and pays for itself.

The cost of saving on office space is not the point (numbers like €17,000/person in Dublin, €11,000/person in Sligo were mentioned). Talent is the point. Working remotely helps to attract and retain people.

Onboarding strategies were briefly touched on. One of the companies hires mainly senior people with 10y+ experience while the other also hires new grads so the strategies are different. It's great if you can get people to HQ for this, makes sure they understand the company's values and culture, and also the tools at their disposal.

To keep people connected, having non-work related communication channels like a #showyourdesk Slash channel or "whose view is better this week?" can help.

Time zones are a challenge for global meetings. Some expectation that you will go the extra mile for the business, since you are not tied to a regular 9 to 5.

There were concerns about working from home and whether people are really working. In general the opposite seemed to be a concern for the panelists: when people work from home you can't see the black bags under their eyes, or if people are stuck. People know working from home is a privilege and work hard to prove themselves. One of the companies measures employee productivity to make sure they don't burn out - though you have to be very careful about how you measure people.

The secret sauce is flexibility. Work is only one part of life.

How about accountability and self-determination? Decisions should be made by the person who needs to. Empower people. Get that right. Measure what you want success to look like.

With regard to people not contributing, teams are tight and it becomes obvious who is and who isn't. You do need to be more proactive in searching for information with remote teams. One-on-one meetings every two weeks to touch base. They are still refining the process. Seven seems to be a magic number, you can see if people are performing for any type of team.

Accessibility | Brian Dalton (Aer Lingus)

I missed the beginning but seeing how a user who relies on accessibility features uses a computer and navigates the Internet is always powerful. Lots of work to be done still.

From keyboard to navigation to simple, silly things like "times shown in red are not available." Label your fields.

Five phrases that shout your agile isn't scaling | Tony Grout (Atlassian)

The Agile manifesto 17 years ago didn't talk about how to scale it! From 17 to 70000 people.

Some interesting suggestions that challenge conventional wisdom. My favourite: it's well-known that smaller teams are more productive. Studies have shown that teams of 9 to 16 people were 6% less productive than teams of 5 to 9. However, if you decide to make 2 teams instead you now have twice the unpredictability because you've added a dependency on another team. Think carefully, run the experiment to see if bigger teams may be better.

Encourage people to think about "teams" over "team." For example, if the UI team is currently the bottleneck, instead of engineering twiddling their thumbs or overengineering something while they wait, perhaps they could create tooling to help the team. That slows them down and helps the other team.

One team working faster can cause everyone else to go slower. For example, a UI team wanting to be pixel perfect.

Those closest to the problem should make the decisions.

Kessel Run: A Digital Transformation Story within the World's Largest Bureaucracy | Adam Furtado (Kessel Run / U.S. Air Force)

An interesting choice for a closing keynote for day one.

The transformation described is absolutely incredible. The speaker spent a fair amount of time at the beginning to explain the current state of things, years/decades of risk aversion leading to becoming unable to adapt to change and thus less safe. Twelve to fifteen years to go from an idea to something in the users' hands, 96% of project behind schedule or over budget, 40% never delivered... They went to Pivotal, who helped them to learn about modern software development practices, devops, etc but more importantly how to change the culture. Now deploying is a non-event and they went from 10 years to 120 days for delivering.

It's truly inspiring and the project they presented as an example showed the real-world benefits: allowing soldiers to stay safe at home and with their family rather than go on months-long refuelling missions around the world, thanks to streamlining the refuelling planning process with software. Definitely a worthy goal.

It was however a bit strange to hear about software described as a differentiator and weapon to cultivate on the battlefield, and how to improve warfare. I suppose keynotes are meant to make you think rather than just give you warm fuzzy feelings, and this talk sure fit the bill!