Thoughts from a Thirsty Bear

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 important issues or design dec

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

“The tools we use have a profound (and devious!) influence on our thinking habits, and, therefore, on our thinking abilities. ”,  Edsger W.Dijkstra ...or in other words... "If you already have a hammer, it is very tempting to treat everything as a nail" My views on using electronic tracking tools  are already fairly well known . But another area that creates a huge impact is the choice of version control system. Using the right software will help your project deliver quickly and efficiently. Choose the wrong one, and the project will be nobbled by unnecessary, damaging and sometimes downright dangerous processes and maintenance overheads right from the start.  In order to avoid the trap highlighted by Dijkstra, it is essential to match the tool to the way you develop and not the other way around .  Let’s consider a fairly typical, highly productive and successful team. In my experience they tend to follow a fairly well defined pattern of working:

Team: “ Coach! Coach! This agile process stuff you sold us doesn’t work! ” Coach: “ Did you build working software regularly? ” Team: “ No, it was too difficult. ” Coach: “ Did you extend your definition of Done as far as you could? ” Team: “ No, it was too difficult. ” Coach: “ Did you make quality part of your process? ” Team: “ No, it was too difficult. ” Coach: “ Did you review what you were doing at all? ” Team: “ Yes, but we didn’t like what we discovered, so we ignored it. ” Coach: “ So are you absolutely sure it was the agile process that caused you to fail? ” Team: “ Oh yes, absolutely…. ” Coach: " <sigh> " * honest....

Those jolly fine people at Energized Work are at it again with their "No Bull" paper which provides us with Simon Baker's personal view of the state of software development 12 years(-ish) after the Agile Manifesto. Now, I know Simon and Gus, the founders of Energized Work, well. I have worked with them extensively, and I have nothing but respect for what they have achieved - quality software development with integrity. I also agree with most of what they say and do. I also know the Energized Crew pretty well - a network of committed, high quality software experts who know exactly what they are doing. They have all embraced the whole "agile" way of working. The other thing notable about Energized Work is their well stocked beer fridge. So it is no surprise that the paper resonates with my general views on the software industry today, and the opportunities for improvement that we are missing as an industry. I would encourage everyone to read the paper for

Unsurprisingly, here at Thirsty Bear Software we have a certain affinity with our bruin brethren, not only in the wild, but also in literature. I have found that one particularly famous bear can teach us a lot about how we behave, how we can improve ourselves, and even about the way we develop software. I am, of course, talking about Pooh Bear, of Winnie-the-Pooh fame. But what can the Bear of Little Brain tell us about true agility? Are you sitting comfortably? Then let's take a stroll to Hundred Acre Wood.... “Here is Edward Bear, coming downstairs now, bump, bump, bump, on the back of his head, behind Christopher Robin. It is, as far as he knows, the only way of coming downstairs, but sometimes he feels that there really is another way, if only he could stop bumping for a moment and think of it. And then he feels that perhaps there isn't.   Winnie-the-Pooh ,  A. A. Milne This is the starting point for many teams, including some self-declared agile teams. They are wor

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

There’s A Hole In My Sidewalk – by Portia Nelson   Chapter One I walk down the street. There is a deep hole in the sidewalk. I fall in. I am lost… I am helpless. It isn’t my fault. It takes forever to find a way out.  Chapter Two I walk down the same street. There is a deep hole in the sidewalk. I pretend I don’t see it. I fall in again. I can’t believe I am in the same place. But it isn’t my fault. It still takes a long time to get out.  Chapter Three I walk down the same street. There is a deep hole in the sidewalk. I see it is there. I still fall in… it’s a habit. My eyes are open. I know where I am. It is my fault… I get out immediately.  Chapter Four I walk down the same street. There is a deep hole in the sidewalk. I walk around it.  Chapter Five I walk down another street. So which chapter is your team at? Be honest now.

Analogies are useful to a point. They allow people to relate new ideas back to something they are familiar with, giving them a safe framework from which to explore new territory. However they can also be immensely damaging and misleading. I was recently reminded of one  particularly well worn example of the latter type that needs to be laid to rest once and for all: Building software is not the same as building a car. Developing a software product is definitely not a simple assembly line process. When building a car on an assembly line, you make the individual components - wheels, engine, chassis, seats etc - and then construct the finished item from these. Each component has already been designed in its own right, and they have all been proven to fit together many times previously. There is absolutely no creativity involved in the construction process. There are limited opportunities for different combinations of components (and those that are possible are well tested).

It’s always a bit of a shock when you get unexpected feedback, especially from someone who you have known for a while. It happened to me quite recently with a conversation that went something like this: Friend : “ You’re dead against agile tools, aren’t you? ”  Me (confused): “ Erm...not exactly.... ”  Friend : “ But didn’t you persuade several teams in < major co > to throw out < agile tool vendor > the other year? ”  Me : “ Not me. The team simply decided that the tools were not providing value to the way they worked... ” However, thinking back I think I can see how some people have formed the misconception that I think agile tools are Satan’s Spawn, and should be eradicated at every opportunity in favour of a simple pen, 5x3 cards and at a push an Excel spreadsheet. Reality, as always, is a little different.... My view is that many teams prematurely select an “agile tool” before they know what they need. Teams (and departments, and companies) are like k