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

Do you know where your team's time goes? What are the competing priorities? Understanding this can be the first step to making sense of how a team is working together at a given time, and gives fairly heavy hints how to improve things for the better. A team's investment (time, money etc) can be broadly split into four 'pots': External Demand . User-facing features, new functionality. Internal Demand . Improvement. Kaizen. Failure Demand . This is the surprises. Often nasty, time consuming surprises. Business As Usual (BAU) . Keeping lights on. Those essential maintenance tasks that keep things ticking over. Any team that understands this, and knows how interdependent they are will generally thrive. Wait... interdependent?   Yes indeed. This is a zero sum game, and any team needs to make a conscious decision of how much of their finite budget (people, time, money) to invest in each at any given time. To make things even more interesting, a team only has direct control o...

  Ah meetings. The bane of all our lives. Some are useful, others...less so. But the perception has always been that they get in the way of doing our real jobs. Yet they are a necessary evil - used well, they allow information to flow between people and allow discussion to happen. Before I go on, I should point out that no, this is not another article about how to make your meetings run better, how to write a better agenda (you  are  all creating an agenda for your meetings, aren't you?) and so on. Enough has been written about that already. What I'd like to share today is a calendar hack that I find useful to tame that most annoying and insidious habit to become widespread since we have gone online -  back to back online meetings . Since 2020, when Covid forced us into the most extensive remote working experiment ever, I have noticed a trend throughout industry to book meetings into every slot, one after another. Days like that are exhausting, and people have to dis...

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

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

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

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

Just recently I have been thinking a lot about what really makes a good agile team member. The reason is that over the years I have seen some teams become incredibly successful in terms of delivering products, and other teams crash and burn even though they have the same superficial traits and abilities. I have also seen teams go from zeroes to heroes (and back again), while others remain at whichever end of that spectrum they started at and never change. There is obviously some "secret sauce" (as Jeff Sutherland calls it) that needs to be mixed in.  Well, I think I have identified one piece of this particular puzzle that I had underestimated previously. Recently, one of my tweets  resonated with quite a few people: " Realised that agile has one fatal flaw. It still requires motivated, smart people who care for it to succeed, same as its predecessors. " (actually I was fibbing slightly - I have suspected this for quite a while now. I haven't only j...

Oh dear. It would appear that some people reading this blog and Twitter feed believe that I am writing specifically about them. Naturally, this makes them a little sensitive to the criticisms that I sometimes level at the industry and the comments/observations I make. Let me reassure everyone that the articles I write generally don't relate to any one client, or incident, or person, or project. There really would be little point in writing about anything that is only specific to one project; to be fair it would be deathly dull, and irrelevant to everyone else. Even in the rare case when there is a particularly interesting success or failure story, I ensure that names are changed, and generally wait a while as well before publishing to anonymise the problem and protect the guilty. And remember I have had people I have never worked with before accuse me (albeit lightheartedly) of spying on their project, so some observations must be common across multiple projects. Sometimes I pu...

There has been a bunch of stuff written about the “Broken Windows” effect - the way that even good people will begin to do bad things if everything else is bad around them. In areas that look badly maintained, people tend to drop more litter. Where people are obviously flouting the rules others are more likely to bend them themselves. And in software, when you are working on bad code you are more likely to write more bad code. I first stumbled across the idea in an interview with the Pragmatic Programmers , but the evidence given is fairly apocryphal. So I was pleased to find something more definite . And it does make for interesting reading. The effect is indeed real, and significant. The number of people breaking social norms when they see that others have done something similar more than doubles. It's the 'no-one will notice another little bit of mess' effect. The study quoted in the article reinforces the need to maintain a high level of hygiene in your software....

I talk a lot about getting the "right people on the bus" when talking about teams, especially agile teams. Quite simply, by ensuring the people involved can all pull together rather than undermine each other makes a critical difference to the success or otherwise of the team. Research suggests that this is more critical than we might think . But how do you find these people? How can you recognise them? What traits do these people have? I've had a go at nailing down specific behavioural traits based on my experience of working with good - and bad - engineers over the years. In no particular order: Courage . The "right people" that I talk about are courageous. They overcome their fear of being wrong and are prepared to challenge ideas. They are also " doers ", people who have the courage and motivation to get up and make a change where it is needed. Pride . Not the damaging kind, but pride as in wanting to do a job well. Professional pride is definitely ...

Via Coding Horror : "A recent episode of This American Life interviewed Will Felps, a professor who conducted a sociological experiment demonstrating the surprisingly powerful effect of bad apples. " This is not news. In fact it's something that I and other coaches have suspected for many years. But this study provides some more scientific backing for our suspicions. In short, even one misbehaving team member can upset the entire team and endanger delivery. Getting the right people on the bus makes life much easier, massively reducing the risk of introducing agile thinking to a company and increasing the chance of successful delivery. OK, the study also suggests that a good facilitator can defuse the effect of the Bad Apple, but as the study shows , people capable of doing this are few and far between (only one team out of the entire study had a team lead capable of counteracting the problem).

Just spotted in a job ad for a lead developer: "You will be expected to implement a rigorous Agile Development process and work with the Technical Architect who will define the technologies and toolsets"

Have you ever noticed how some teams do not have a "buzz"? That certain energy that differentiates a good team from a great team. Anyone who has worked for any length of time in software will almost certainly have experienced the lacklustre plod of a team in crisis. But there is a rarer but not unknown phenomenon created by the further collapse of teamwork and common sense. I call it the Black Hole Team. Here, all joie de vivre has been crushed out of the team. All hope of changing, evolving and improving working practices has been extinguished. Team members are simply coding zombies, attending work not out of pleasure or professional pride, but instead simply to churn out second rate code that gets them from 9 o'clock to 5. By this stage the team has become so dense (sic) that new team members have the life and energy actively sucked out of them until there is just the shell left. So just how does a team collapse to this level? The ways are many and varied, but common ...

I use Cruise Control. It’s my automated build weapon of choice. Why? For no other reason that it was the first one that I got my hands on. I (mostly) understand it, trust it and know its quirks and foibles. It also has a neat feature – it shows project metrics. These are shown as pie and scatter charts displaying successful and unsuccessful builds. Both of these provide useful indicators about the health of a given project. Taking the scatter chart first. This is a calendar with day on the X axis, and time on the Y axis. A dot is placed on a calendar every time there is a build – red for fail, blue for success. From this you can get a feel for the following: How many checkins are being done per day How successful they are How long a build stays broken Whether the Team is staying unusually late or coming in at weekends All of these are useful indicators as to how things are going in general. I look for regular checkins during standard working hours an...