Lean/XP Full-Stack Software Engineer with a DevOps mindset. I do backend development and frontend development. I set up development infrastructures, define software and enterprise architectures, have lots of interest in operations and coach teams in adopting eXtreme Programming principles.
Along the years I have been a bit everything: Software Engineer, (Architect), Technical Team Leader, Scrum Master, Product Owner and Agile Technical Coach.
In part 1 of this series - a Tale of Two Teams - I introduced two quite different teams. One novice team practising trunk-based development, the other experienced but being used by GitFlow. Now I would like to explore why teams use feature branches. What are their reasons? What problems are they trying to solve with long-running branches?
On the experience of working with two totally different teams: one novice practising trunk-based development, the other very experienced being used by GitFlow.
Pulumi is the new kid on the block in the cloud infrastructure as code arena. I was relieved to find Pulumi. Finally, we have testable Infrastructure as Code. We can write fast unit tests that we can execute locally without needing the cloud. However, I was a bit disappointed. Pulumi does not have a full representation of IAM Policy documents. Fortunately, it was relatively easy to build a library that did this!
A set of questions I use during the occasional times I have to run an interview to hire engineers inside an agile team.
Over time, different people have articulated Conway’s Law in various different ways. This is an overview of the variations I found when recently going over Conway’s Law literature.
Branch creation became very easy with the advent of Distributed Version Control Systems. However, it comes at an unquestionable cost. Long living branches break the flow of the IT delivery process, impacting both stability and throughput.
It has been five years since I started with public speaking. I wanted to share my journey into public speaking. My highs and my lows. Maybe my experience as a shy, introverted person can help others.
There is this commonly accepted, hard-grained belief in the software industry. By dropping a build server in a team, they get Continuous Integration magically for free. This belief is further incentivised by the marketing of build server vendors.
In this post, Leena interviews Thierry de Pauw, a Software Engineer who coaches on Continuous Delivery and other Software Engineering Practices. His focus is helping teams to improve the flow of software delivery.
Let’s put aside the ‘bubblegum and unicorns’ of the Spotify Engineering Culture videos and talk about what doesn’t quite work at Spotify, and how we’re trying to solve it. This is a failure/learning report intended for coaches and other change agents who need encouragement that it’s always hard AND it’s always possible to improve.
Over the last 7 years I have heard lots of reasons on why people can’t do Continuous Delivery. This is my summary of these reasons and why they are wrong.
Clarke Ching organised the online conference ToC Down-Under Summit 2021 at Sydney time. I was able to attend the first two presentations of each day. These are my notes of the keynote of day 2 given by Ian Larsen.
Clarke Ching organised the online conference ToC Down-Under Summit 2021 at Sydney time. I was able to attend the first two presentations of each day. These are my notes of the keynote of day 1 given by Justin Roff-Marsh.
Most of us know about Conway’s adage “Any organization will produce a design which is a copy of the organization’s communication structure.” But Conway coined four laws in his 1968 paper “How Do Committees Invent?” What are the other ones? Why are we not talking about them? And what do they tell us about optimizing teams in a distributed world? – Mike Amundsen
This is the paper behind Conway’s Law. I’ve assembled some snippets from the paper that triggered me and added some thoughts.
We are trying to tell something positive about #NoProjects instead of just saying No.
My notes from the Anand Bagmar’s Analytics workshop I followed at AADays 2018 in Poland.
My notes from a performance testing workshop I followed at AADays 2018 in Poland. It was my very first encounter with performance testing.
This is a full transcript of Allan Kelly’s “Continuous Delivery and Conway’s Law” at the LondonCD Meetup. It gives an in-depth overview of what Conway’s Law is, how it impacts organisational and system design and how it relates to Continuous Delivery.
Why I got interested in micro services? Because from my early days at ThoughtWorks was actually helping people ship software more quickly. I spent lots of time looking at Continuous Integration, Continuous Delivery, cloud automation, infrastructure automation, automated tests, and all these sort of things. And realise that actually it was the architecture of these systems that made it hard to ship software more quickly.
These are my notes on Maike Goldkuhle’s session at XP2017 on HR and Agile. I wanted to attend this session because there is very little said about the role of HR in agile transitions.
This is a full write out, almost word for word, of Steve Smith’s presentation ‘Measuring Continuous Delivery’ at Pipeline Conf 2017. I’ve written this presentation down, together with the first version of this presentation at the LondonCD meetup, to be better prepared to review Steve’s book Measuring Continuous Delivery.
Dave Farley describes approaches to acceptance testing that allow teams to work quickly and effectively, build functional coverage tests and maintain those tests throughout change.
Les Hazlewood, CTO @ Stormpath gives an in-depth overview of what makes a RESTful API. The original video on which these notes are based is not available any more. I fell back on the video of JAXConf.