Posts

Of Goals, Backlogs and Sprints

Image
As an experienced developer/coach, once in a while you get asked a truly fantastic question by a client who has actually done her homework, and you're absolutely stumped by it. I love it when this happens since it is a fantastic opportunity to not only learn, but also to teach the client how to solve similar questions themselves next time. This particular team had been attempting to implement Scrum for some time, with a degree of success. But one thing was bugging them in particular. How to control stories in-sprint. The advice they had been given (and the way I understand Scrum to work) was that sprints are immutable. During the plannig game, the team sets the sprint backlog, populating it with the subset of backlog stories that the team believe they can fit into the timebox. That's it - only a major event causes that to change, in which case the sprint is terminated, replanned and restarted. So when the Scrum Master asked about the 2016 edition of the Scrum Guide ...

Feature Branching - Taking the ‘Continuous’ Out Of Continuous Integration

Image
Feature branch workflows appear to be the flavour of the month for software development right now. At its simplest, features are developed in isolation on their own branch, then merged back to the trunk. More complicated variants exist, most notably Git Flow . Git is undoubtedly a powerful versioning tool. It makes branching easy and reliable, and it is truly distributed. These capabilities open up a whole range of possibilities and workflows to support different ways of working. But, as usual, the sharper the tool, the easier it is to cut yourself if you don't understand what you are doing. My problem is this. Feature branching is a very effective way of working when you have a large, distributed team. Code is not integrated with the rest of the codebase without a lot of checking. Pull requests ensure changes - often done by developers who are in other countries, and often part of a loose-knit open source development team - are reviewed by a core team before being inte...

The Importance of Being Able to Build Locally

Image
A little while back I wrote an article describing how to do continuous integration . But I left out one important step that happens before any code even enters the CI pipeline. A step so important, so fundamental, so obvious  that you don’t realise it is there until it is missing. You must be able to build and test your software locally, on your developer machine. And by “test” I don’t just mean unit test level, but acceptance tests as well. I said it was obvious. But once in a while I do stumble across a project where this rule has been missed, and it leads to a world of unnecessary pain and discomfort for the team. So what happens when you cannot easily build and test anywhere apart from the pipeline? Without being able to run tests locally, the development team is effectively coding blind. They cannot know whether the code they are writing is correct. Depending on where the dysfunction is - compile, unit test or acceptance test stage - the code checked in may or m...

Twitter

Image
I don’t know if anyone’s noticed, but I’m not very active on Twitter any more. No, it’s not the annoying “While you were away” pseudo-window that is keeping me away. Nor is it the Facebook-esque ‘heart’ button (WTF?). Nor is it the endless supply of advertising bots and idiots that seem to frequent the service (I have most of them filtered out)   It’s not even the regular misaddressed tweets meant for the Thirsty Bear Brewing Co in San Fransisco (fine fellows, and purveyors of fine beery comestibles that they are!) Nope. None of the above. It’s the distraction. On 5th November 2008, at 0525 (allegedly - I suspect there’s some sort of timezone shenanigans going on there…those who know me realise I am not a morning person) I wrote my first Tweet: "Trying out this Twitter thing….”) Since that date I’ve got involved in all kinds of interesting discussions, mostly around software development, and often with the Great and the Good of the agile community -...

Getting rid of those annoying ._ files

It all started so innocuously. All I was asked to do was put some photos onto a USB stick that could be played on a TV in my local pub. Easy. JPEGs duly loaded onto the drive, plugged in...and found to be incompatible. Weird. So I checked the JPEG file format against the specification. I changed sizes, I changed encoding type.  Still not playing. Really annoying, and not a little embarrassing! Then I noticed - the TV was trying to display files with names starting with '._'. Where the hell did they come from? And the penny dropped. OSX creates all kinds of special files to work with non-HFS file systems - like the USB drive's FAT32 format. These files are part of the AppleDouble format , and don't show up if you reveal hidden files in OSX (see this excellent article on how to show/hide the hidden files ). So to get rid of them, you can either use a Windows or linux machine, or use the dot_clean command in OSX. Hopefully this will save someone some time tracking...

Don’t overload your Scrum Master!

Image
Aka "Absent Scrum Master Anti-Pattern" There is a question that keeps cropping up when talking to clients. It is  “How many teams can a Scrum Master lead?”.  My answer? Just the one. Let’s take a closer look at why people persist in asking this question, and try to understand better why it is generally a Bad Idea™.  When a team is running well, everyone is happy, and product is being delivered successfully iteration by iteration, feature by feature. There is comparatively little for the Scrum Master to do aside from day to day housekeeping. Everyone knows how the process works, everyone plays their part. The system chugs along and delivers. The SM appears to have a huge amount of slack, which most organisations believe is a Bad Thing - slack means they need to squeeze out more performance (read “ profit ”), in this case by giving the SM something else to do. I.e. another team. And maybe another. And another. Or other random responsibilities. Ignoring the ...

It's time to make immutability the default

Right. I have to get this off my chest. A follow-on from my habitual coding observation in my previous article . How many people habitually write Java code like this? (Clue: I see it a lot) public class Article { private String title; private String author; private List tags; public void setTags(List tags) { this.tags = tags; } public void setAuthor(String author) { this.author = author; } public void setTitle(String title) { this.title = title; } public String getTitle() { return title; } public String getAuthor() { return author; } public List getTags() { return tags; } } Then you can create an object an use it with something like: Article article = new Article(); article.setAuthor("Cam M. Bert"); article.setTitle("French Cheeses"); article.setTags(Collections.asList("cheese", "food")); // etc etc G...