Scrum, Features And Back? Again

If you've worked on any software development project in the last few years then the chances are you've worked in either a scrum team, on a kanban board or any variation of the two.

Over the past year I've been working in a remote-first distributed team that adopts agile methodologies as part of our daily process, this is our story...

September 2016

Around September 2016 the project kicked off with a team of 4 developers mixed between front-end and back-end programmers, we made the decision to follow a lot of the scrum processes to ensure a collaborative working environment.

We started with two week sprints, at the beginning of which we had a retrospective for the previous sprint and planned our next two week iteration. All the while we were ironing out the kinks of working in a distributed team for the first time.

Scrum was working well for us for quite a while, we got our projects bootstrapped, had quite a few very positive sprints with the odd issue being resolved as part of our retrospective.

That's not to say all of our problems were solved, we probably spent more time than was recommended discussing and testing tools to make the management of our issues easier, we eventually settled on Gitlab issues with milestones for sprints.

February-March 2017 (roughly)

Fast-forward 5 months and we've got our projects bootstrapped and well into the feature development phase, this is when we started to find some limitations to scrum for our team.

We knew we had to complete a certain set of issues to complete a feature that we'd try to focus on in each of our sprints, but we reached a stage when the availability of the team was fragmented with some members having a lot more time than others. This meant that our front-end and back-end were suddenly out-of-sync.

With this it became more and more difficult to pick a single feature to focus on for a sprint; more of our sprints were resulting in a feeling of dejection due to less work being achieved than was hoped for.

We were also only using sprints to time-box work, so why not try something new?

Feature Driven development

At this point we decided to get rid of our sprints and backlog milestones in Gitlab and streamline our issues into the feature milestones.

This was great and gave us an idea of how close a specific feature was to completion through the number of issues still to be completed, it didn't matter whether they were in a worker service, the API layer or the front-end web application, we could see at a glance how close we were to releasing a new feature.

What did we discover?

While everyone was enthusiastic for this change and thought it made a lot of sense for our use-case, especially with the differences in available time, we found that very little work was being done.

I couldn't tell you why this was; it appeared that for our team working without the time boxed constraint of a sprint meant we just didn't focus on what needed to be done and devote the time that we needed to.


After our attempts at going down the Feature Driven Development route we're back to working in a more scrum-like system. We have weekly catch-ups and retrospectives, people post a daily standup on Slack and we try to identify blockers as early as possible.

We've found a system that works for us and obviously YMMV, I'd like to try Feature Driven Development again, maybe if this was something we were doing full time rather than in our evenings and weekends. But if you have been part of a team that's done Feature Driven Development well, I'd love to hear from you the benefits and challenges that you faced.

Dear Recruiters

An open letter

Dear Recuiters,

I know you're only trying to do your job, I greatly appreciate that, and I appreciate every time you've tried to place me with a company that you believe will be a good fit.

But we need to talk; like most people I'm extremely busy during the day, I have a job to do, I've got bills to pay after all. Whether I'm looking for a new role or not, without a scheduled call the chances are I will not answer your call.

Again I appreciate you're just doing your job and have taken the time to try and call me, but if I take 1 call, the next thing I know I'm away from my desk for an hour and I need to make that time up, after all my current employer is who pays me at the end of the month.

If I don't answer your call, it's a safe bet I'll check the number later, and if you leave a voicemail I'll give it a listen and try to find time to call you back. This then saves you time later as you don't keep trying to call me and hit a brick wall.

An even better idea? Drop me an email, if you've got my phone number it's a fairly good bet you've got my email (it's on more of the information I've got publically available than my phone number is...), again I appreciate you want to use your skills of persuasion over a phone call, but if you can't articulate the same message in an email the chances are I'm not going to be interested anyway.

Using one of these two tactics almost guarantees I'll get back to you, what does not is constantly trying to phone me without any sort of message. At the end of the day I don't have the phone number for every recruiter, and like many people I will not answer a call from a number I don't recognise.

Being pushy makes me not want to work with you, calling me after 6pm without a pre-arranged call makes me not want to work with you. When I leave the office I try to stop thinking about work, I don't want to be fielding calls that I'm completely unprepared for after doing a full days work.

All I want from a recruiter is someone who respects that I'm a human, that I may be busy, and heck, I may not be avaialble at all at that time. Multiple calls / chasing emails does not do that, make use of asynchronous communication and save us both some time in the long run.


Keeping Myself Motivated

Coding After Dark

One of the hardest things I've found about being a programmer is keeping myself motivated to do the things I want to do after the 9-5 day job is done. I would love to be able to work for myself, be part of the product team of something I've built from the ground up, but being a programmer by day makes this surprisingly difficult.

As well as writing code for our employers all day there is a general expectation that as software engineers we'll go home and study up on new technologies to bring to table, keep our own skill set up to date and just generally keep our heads in the game, how many of your friends just go home and watch TV?

So what I'd like to do is share a few of the tips that I use to try and keep myself motivated and reach that lofty goal of launching a product I'm involved in from the start.

Don't code 7 days a week

One thing I was definitely guilty of in my first year of programming was spending every single day programming. This doesn't do your mind any good; there's a plethora of other things we need to consider in our lives so if we code every day, where do we find the time and brain capacity?

I'm not saying this won't happen some weeks, especially if you're building something to try and get out of the daily grind, but this should not be a norm

Have at least 90 minutes a day (when coding at night) to relax

Following on from my 7 days a week rule, this one seems obvious. Spend at least 1.5 hours a night just unwinding, ideally before bed. This could be with a book, your favourite TV show, or just talking with family. If you can remove the screen time (not always the easiest with Kindles for reading and TV, but at least put away the laptop / phone).

Only work on projects that I enjoy

This one may seem obvious, but it's easy to keep working on something in your own time that you do not enjoy. You may be worried about disappointing others, or have been talking about something for so long you have to do it. You don't owe anybody anything, take care of yourself and make sure you're enjoying what you do. If you're meant to come back to a project or problem, you'll re-find your passion for it soon enough.

No Day-Job Problems

Over the years I've been guilty of taking my work home with me. I don't switch off easily so there's been times where I'd spend hours trying to solve a day-job problem, just because I hadn't solved it. This does nobody any good, all this does is keeps the problem at the forefront of your mind and stops you detaching your work and home life. Time away from a problem usually helps me solve it quicker anyway, so when I leave the office, the day job work stops at the door. I'm not being paid to solve those problems on my own time!

Spend Time With Non-Programmers

This won't come as a surprise, but a lot of my friends are programmers (or at least work in IT), and that's great, it means we always have something to talk about. However, my close family and my closest friends do not work in IT and some of the most re-energising conversations I have are with them. Talking about music, sports or holidays I've found to be a great way to re-motivate myself, I come back to my computer and I want to write code!

Escape From Reality

As I mentioned at the very beginning as software developers we're expected to spend a lot of our time studying as well as having a day-job. This means reading books on many a subject matter, sometimes the most difficult reads you'll ever have. For this I always try to have one fiction book on the go for every non-fiction book, this way if I want to read but can feel my brain going to mush I can escape into another world and not worry about things for a few hours. This doesn't have to be just a book though, you could easily substitute the book for your favourite video games or even just catching up on the latest albums from your favourite bands. No matter what, escaping from the real world is the real goal here.

On their own I wouldn't find any of these tips ground-breaking, but together? These are the reason I can justify showing up to the office in the morning.

My Symfony Controllers

Last week when I was presenting my "Events In Practice" talk at GlasgowPHP I had an example slide for a Symfony Controller like below:


namespace Demo;

class UserRegisterController
    private $eventDispatcher;

    public function __construct(EventDispatcherInterface $eventDispatcher)
        $this->eventDispatcher = $eventDispatcher;

    public function __invoke(Request $request)
        $user = new User(...);

            new UserRegistered(

        return new JsonResponse();

And I was asked about how I create my controllers with just an __invoke method, the secret? Declaring my Controllers As Services, while Symfony don't "recommend" this approach I find it allows me to keep control of my application structure much better.

The real magic happens in the routing file used

# app/config/routing.yml
    path:     /hello
    defaults: { _controller: app.hello_controller }

By omitting the the :action from the default _controller tag Symfony (from 2.7+ I believe) will automatically call the __invoke method on the controller service.

If you want to read more about this structure of code organisation read up more on the ADR Design Pattern.

GlasgowPHP Slides

Guzzle Segfault

Have you ever been working with Guzzle, php-fpm and Nginx and then as soon as you send a request via the Guzzle client you get a "502 Bad Gateway"?

Well, that's how I spent 2 working days this week, absolutely everything in our code looked fine, running it via a PHP script on the terminal wasn't a problem, but as soon as we used the same code within our development Docker containers, boom, 502.

After drilling down into the code for the Guzzle CurlHandler for what seemed like an age, I eventually noticed something that piqued my interest: Guzzle was trying to write to write to php://temp if you don't provide a sink option in the construction of the Client (the code that covers this:

This got me thinking, "I wonder if Alpine Linux creates the same /tmp folder that Ubuntu et-al do?", turns out, no they don't. After creating the /tmp directory to match where PHP believed the stream for php://temp should go everything worked like a least from the Guzzle standpoint.

I hope this helps someone else out there, but if not, it's at least a reminder for me if I ever see Guzzle segfault on me again...