Thoughts from a Thirsty Bear

As AI adoption continues apace, one good thing coming out of this second mass experiment of the decade (the first being Work From Home, caused by Covid) is  data . As more and more companies adopt AI in the software development workflow, they are generating huge amounts of information about its effectiveness. The folks at CircleCI are in a unique position to collect the data across millions (28 million to be precise) of delivery pipelines they host. They have published a summary of their findings  here . So what do 28 million data points tell us about using AI in software delivery? It's..."interesting". TL;DR - AI's effect on branches is noticeable. It increases throughput of branches for median teams significantly (15%), but this increase never makes it to production; they are never released. The production release branch throughput degrades by ~7% for the average team - AI adoption slows down teams by quite a lot. As expected, the AI-induced pressure of generating m...

What makes a high performing team tick? What is it that takes a team from being medium or low performing into elite performance as defined by DORA? On demand deployments, single figure bug counts, next to no downtime. Having worked in high performing teams, as well as having built a few myself over the years, I feel that I have a unique perspective on what it is that allows a team to work effectively together. The "Secret Sauce". So what's the recipe?  It's...." complicated ". But it looks a bit like this: At the top, unsurprisingly there is Technical Excellence . Team members need to be fully aware of and skilled in the various accepted best-of-breed tools and techniques that are out there. These currently include TDD, BDD, incremental design & architecture, refactoring, pairing/mobbing and so on. No excuses, these are all proven techniques that improve both quality and delivery, and should not be dropped unless there is a provable reason to. Even then ...

 We are certainly living in interesting times right now. Specifically here I am talking about the rise of "Artificial Intelligence" (or, more correctly, 'Large Language Models", AKA 'LLMs') in software development. Whether you believe these tools are useful, or will lead to the demise of the human race¹, there is no doubt they are surrounded by the biggest hype cycle that anyone has seen before. There is an unprecedented (many are now saying unsustainable) amount of investment happening in this area. But any investment requires a return which means marketing and sales are working overtime to bring in new paying customers. Unfortunately as a result of these intensive sales campaigns there are companies - many of whom should know better - becoming ensnared in the unfulfilled promises being made by unscrupulous companies, and are " drinking the Kool Aid ". However, once the contracts are agreed by senior management, and the (not insignificant) bills be...

A term that I still hear occasionally is "SDET", or "Software Development Engineer in Test". It is also known by a few other terms - Developer in Test, Test Automation Engineer and so on. Essentially it is a job role for a developer whose main responsibilities are to write automated tests and frameworks to check software. And it is a truly awful case of missing the point completely . It is a job title that indicates a fundamental systemic problem in an organisation. First, some history. Back in the Bad Old Days of the 1900s, we used to develop software using a linear waterfall style process, mostly due to a bizarre and tragic misunderstanding of a single academic paper (Royce, 1970). There was a lot of management thinking that modelled software development as a factory production line, and assumed that there were cost reductions from specialisms - someone creates a software design, someone builds that design, and someone tests what has been written. At the end, som...

Customer feedback. We all know we need it to make sure we are delivering the right thing. But sometimes we all have trouble engaging. The customer might be busy, or disinterested, or both. So here's a little tip that might just help. Like all the best stories, this happened a long time ago in a galaxy far, far away....  We were working on a web front end and associated backend system for a client. But we were suffering from the "disengaged  customer" anti pattern. The customer would not commit to a web front end design, and help us design the look and feel needed for the application. We provided a few options over a couple of iterations to try and start the design conversation, but none connected despite our efforts. So we threw in a " smelly sock ". Something so stinky it guaranteed to get folks going " Ewwww! Get that out of here!". I seem to remember we disabled all CSS formatting.... Sure enough, we got a reaction during the regular show-and-tell s...

Bill Gates chose to open his 2013 TED talk with the words  "Everyone needs a coach" . Someone to provide feedback, and help them see how others see them. True enough - I have helped many people over the years understand themselves, how they interact with others, and how they can resolve inner conflicts and improve. For me, being an effective personal coach is one part of providing quality leadership to companies, and was one reason I went on the Barefoot coaching course a while back. But let's zoom out, and look at the next level in the software industry, specifically the delivery teams. These folks should be the powerhouse of any company, turning customer needs and ideas into reality that can be assessed for usefulness, and ultimately value (whatever that is - value can take many forms. Maybe a subject to explore another day).  However, in companies I work with I am seeing a problem with many of these powerhouses. Something that I suspect is rapidly becoming a  BIG prob...

Established companies today are facing many problems. Recovering from the Covid pandemic. Adapting (or otherwise) to remote working. Keeping up with younger, smaller, faster competitors that seem to be able to adapt much more readily to today’s VUCA environment. The list seems to be endless. To do this, many are changing the way they work - they are undergoing transformation . But…many have a problem… I give you the Pitts Power Paradox of Organisational Transformation! (Not exactly a snappy title, granted). Let me explain. Having been involved in many of these transformations where ‘traditional’ companies are attempting to change the way they do business, I am seeing a common pattern of failure. They ignore one fundamental issue that can be summed up in a single quote: “ All organisations are perfectly designed to get the results they get. ” - Arthur W. Jones Every organisation already has a system in place - a way of working - that gets precisely the existing results. To change the r...

It has finally happened! My first podcast interview, ever! I was interviewed by Ian Gill from  Agility By Nature . I have known Ian for a fair few years now, having worked together and shared a few beers on several occasions! We talked about all kinds of things, from my early tinkering with agile methods, through to where I think the industry is heading, and a lot in-between too, some of possibly (hopefully) a little controversial....  Have a listen, and please do ask questions in the comments. AgilityByNature · An Agile Audience with Chris Pitts and Agility by Nature

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

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

A wise man once said, " I've got a plan so cunning, you could put a tail on it and call it a weasel! ” Unfortunately in software it isn’t quite so easy. Simply renaming a broken process doesn’t really change the way a project is set up. Unfortunately a growing number of managers seem to believe they can turn their projects into lithe, agile weasels simply by wrapping pre-planned waterfall projects into iterations and calling it “agile". Projects like these tend to ring several alarm bells, such as: The entire project is estimated up front (usually taking up a huge amount of development team time) Stories are split by service, and not by end-to-end functionality (usually a sign that key design decisions have already been made without being validated by working code). Ie the now discredited smokestack development approach. So a team (or even separate teams!) might be developing the front end first. Then later develop one of the services the front end uses later....

One of the most common conversations that I have with clients is about continuous integration (CI) - the discipline of pulling together work done as often as possible, usually after code checkin to verify that the project is still on track (ie "it works"). So how many environments do you need in order to get real benefit from CI? Unfortunately the answer is a fuzzy "It depends...". But I always recommend at least 4 for safety/effectiveness. The good news is that if you do it right, downstream environments are relatively cheap to add as the need arises. (I have lost track of how many times I have drawn this diagram in various forms for clients, both in formal training and informal conversations. I am quite glad that I have finally managed to capture it onto one A4 sheet!) So what have we got here? Build & unit test This is the initial stage, normally triggered by a developer checking code into a version control system. It checks out the code ...

I practice, teach and coach Test Driven techniques. Test Driven Design (i.e. using unit tests), Behaviour Driven Development, I use them all on an almost daily basis. I find them useful since they help me do my main job of delivering software. Yet once in a while I am asked  whether I could be more "pragmatic" and less "purist" over Test Driven Development and Behavioural Driven Development techniques. I always find this an odd request, especially when I have been brought in as the subject expert to teach a company, or as a lead developer with a solid grounding in these subjects. But maybe this is not obvious to some, especially those who have never used the techniques correctly - or at all. This article looks bit deeper into the request, and see why I am totally nonplussed by even the idea. Firstly, what does TDD and BDD (arguably the "pure" version of them) usually look like? To me they look like closely related cousins, which makes this brief summ...

(If anyone would like to claim this is their work, I am more than happy to recognise the fact - credit where credit's due. Just drop me a line)

Currently it seems trendy to say that your team no longer estimates. Or that estimating work is pointless (pointless? Geddit? oh never mind....). Hell, even I have said similar on Twitter . So estimation is finally dead. Hurrah! No more picking meaningless numbers out of thin air when you really have no idea how long something will take. Finally we are rid of a process that is demonstrably flawed . Except...is that a twitch I see from the lifeless corpse? I do believe it is! There will always be times when it is genuinely useful to answer questions such as "Will we be able to show our new product at the April trade show?". Or "Which quarter do we need to start ramping up our marketing for the new feature?". All of which require estimates. Not necessarily to-the-day accurate estimates, but still estimates. Even teams who claim not to estimate are finding that it is useful to make a judgement call - dare we call it an estimate - on the size of a requirement ...