Thoughts from a Thirsty Bear

  “The most efficient and effective method of conveying information to and within a development  team is face-to-face conversation.” The Agile Manifesto’s 6th Principle.   Obvious, isn’t it? The fastest, easiest, best way to exchange information is to actually talk to people . From this simple premise comes the recommendation of “collocated teams” - so that people can communicate with minimal friction. I shall put my hand up and admit that I have fully supported this idea for years, and have regularly encouraged teams to adopt it, usually with fantastic results. There can be no doubt that the approach works extremely well. Not working together in the same physical space forces compromise since it  reduces collaboration unless people actively work to come together. Information flow happens more slowly, and becomes more ‘clunky’. Also people lose the subtle cues from body language, half-heard discussions, and instant team timeouts to discuss import...

Exciting news! Folks may have noticed that I have been quiet of late. Well, I have been expanding the range of skills that Thirsty Bear Software can offer. I am pleased to announce that we can now offer Personal and Business Coaching services . I am now a trained Barefoot Coach . It is worth pointing out that this coaching service is completely different  from what folks call " Agile Coaching " - this kind of coaching is aimed fairly and squarely at helping individuals, teams and businesses unlock their potential and maximise their own performance. Not a Scrum, unit test or continuous integration in sight (although I can  still help with that tech stuff if needed - that is a service we still provide). No doubt I will be publishing an article soon on the difference between the two, but for now I hope that definition is enough. If you would like to know more, then please do get in touch. However, this is just the first step on a longer journey, leading to both a Postg...

Recent posts by Dave Farley and Jim Kinsey , and the release of the Accelerate book by Forsgren et al appear to be bringing dysfunctional development practices firmly into the spotlight once again, most specifically the practice of combining feature branching and automated builds, while calling it “continuous integration". I have already written my own opinion piece on the practice . In summary, I hate it - in a modern, collocated team it is wasteful, suppresses fast feedback, and completely undermines the advantages of powerful teamwork enabled by continuous integration. It harks back to a software dark age that I honestly thought our industry had finally left behind. It really is Continuing Isolation. But perhaps the most damning piece of research about Feature Branching that has come out in recent years is best summarised by Dave Farley: If you are not merging your changes to Trunk at least daily, [the research] predicts that your outcomes are more closely aligned with...

I recently wrote a somewhat tongue in cheek piece with a serious message . For agile - well, actually, any software development project - to succeed, business needs to be fully and intelligently engaged. Iterative delivery processes appear particularly sensitive to this (arguably, they just show it up sooner, but that’s another discussion). So, how do you make sure that your software team(s) successfully deliver what’s needed? A very good question - and one with no definitive answer. But here are a few hints that should give you a better than average chance of success. Firstly, and perhaps most importantly, is to recognise that “ The Business ” generally does not really understand the engineering discipine of software development. They might have an appreciation of it (at least, I hope they do!), but they don’t have skin in that particular game. They don’t cut code daily, so they don’t experience the trials and tribulations of producing the end product. So they don’t general...

So - you have invested in transforming to an agile development process. Your teams have honed their processes until it runs like clockwork, and are resilient to changing needs. Software is being produced cleanly and efficiently with minimal fuss. But there is still something missing. The software simply doesn’t do what you expect. The customers don’t like it, and won’t use it. It has annoying quirks and foibles that put people off. It simply isn’t right. What’s going on? Congratulations! You have discovered the Achilles Heel of all software development. It has to have an undamaged brain. A well disciplined agile team will deliver whatever its business brain asks of it. The team is only as good as its inputs and subsequent feedback on its deliveries. Or to put it another way, so-called ‘agile’, and all other software delivery processes for that matter, rely on sound business thinking. Make Abby Normal your customer/Product Owner, and you will be in serious trouble. At ...

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 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...