tl;dr Codifying your process is useful as it guides others who come after you, but it may give them the impression that they're using your process and therefore have no permission to change it. It may even leave them arguing over the detail of what you really meant rather than thinking for themselves. I was … Continue reading Codifying or Ossifying?
Git tells me that I put my first Oracle database inside a docker container in early 2016. The issue was simple - we were working with a large, old, legacy database and we wanted to be able to run our integration tests against the database. Our solution was to use a Docker image based on … Continue reading Ephemeral Oracle Databases inside docker containers
I went to Go Ape last week with my kids. While I was there, I watched the staff moving around in the trees, helping children and keeping everyone safe. If you've never been to Go Ape, it involves traversing around one of several courses in the trees while attached to a steel cable running around … Continue reading Safety (and HTTPS)
As a tech lead, one of your responsibilities is to deliver robust software that solves a problem, and to deliver it on time. This post is my attempt to set down some things I think are important if you're going to do that. Nothing below is my own invention, but I've tried to avoid referring … Continue reading Delivering
Last year, I attended a training course for my company's chosen brand of agile framework: DSDM. I had some misgivings, having seen some bad projects using this methodology, but I was prepared to give it the benefit of the doubt. Long story short, I was persuaded of its usefulness*. To briefly summarise, if Scrum is … Continue reading Who needs DSDM?
I was recently tech lead on a 4-5 month project with some familiar team members and some new ones. The customers were internal users who have a fair amount of project experience. Early on, the project manager and I agreed to try and do it without sprints. Our reasons were diverse: Work did not seem … Continue reading To sprint or not to sprint
Everyone on the team should understand and be able to suggest changes to the team processes because developing great processes isn't the preserve of experts or coaches. We are often presented with a world of experts. Arguments about some subject or other are perceived to have been won by one side and lost by the … Continue reading Agile essentials 7: Own your own process
One of the risks of iterative development is that the pace becomes too fast for everyone to sustain. In this post I discuss why I think this is a risk and some things I've tried, or considered, to deal with it. Giving a team the time to do a good job is essential. I wouldn't … Continue reading Agile essentials 6: Sustainability
Only build stuff when you need it. Make decisions as late as you can. A decision isn't final until you have finished building whatever is based on that decision, and even then.. The principal that you should only build something when you need it is kind of obvious. For one thing, if you aren't going … Continue reading Agile essentials 5: Just in time
Agile teams are multi-disciplined and communicate closely, which avoids miscommunication, builds trust and makes sure that things happen quickly when they need to. If your team isn't working like that, you need to find a way to deal with it or any Agile processes you have will struggle. In my first tech job, an operations … Continue reading Agile essentials 4: Teamwork
virtualmackem 