Thoughts from a Thirsty Bear

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

Well, that’s a nice surprise! I have just received a very nice email telling me that I have been nominated in the Agile Special Recognition Award category at this year’s Agile Awards .

Paraphrasing an overheard conversation, " This agile process is creating all sorts of problems for us. We are finding all sorts of problems that we wouldn't normally find. "  <pause>   " Oh. Wait. They were always there, weren't they? We just never realised... " All agile processes are designed around regular feedback. They try and touch all phases of delivery as soon as possible, forcing issues to the surface early before they become too damaging. The process is designed makes problems visible regardless of how uncomfortable this may be. They are an unforgiving mirror on the reality that we are often too close to see. But visibility is only the beginning. Just because something is visible does not magically change it into something better - it just means that you know it is there. To change something requires a conscious effort. Your success or failure depends entirely on how you react to the information you are provided with. This reac

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

I am in the process of revisiting exactly what defines agility and what makes it tick, but collecting my thoughts on the subject reminded me of a couple of classic poster summaries from those jolly fine fellows at Energized Work  back in 2007. Well worth a look.

I am pleased to announce that Thirsty Bear Software is now working in association with RADTAC to provide courses that lead to Certified Scrum Developer . These are three day technical courses that cover the technical aspects of agile software development - basically the same training that I have been providing to companies outside of the Certification bunfight for years, except now formally assessed and accepted by the Scrum Alliance as satisfying the technical requirements of their new Developer Certification framework. The next public courses are planned for the following dates, and are subject to change: 14-16 May 21-23 August 8-10 October 19-21 November  The courses are all held at the RADTAC offices in Central London, close to St Paul's Cathedral. For more details, and to book your place, please contact RADTAC directly.

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

"You want to buy an agile? We sell you an agile. Very cheap. Very easy." Doesn't make sense, does it? And yet many companies accept equally nonsensical marketing speak because they want to " do agile" . " Agile " is not a physical thing that can simply be bought or sold; it's not a commodity. It is a concept. A philosophy. A mindset. A way of thinking. You cannot just be handed one to use. It requires you to make a fundamental change in yourself. If you are not prepared to invest in that change, then you are wasting your time and money trying to achieve the goal. You have simply bought an agile , and put it on a pedestal in the corner. " Look, that's our agile. Do you like it? " (actually no. It's a dodgy colour and clashes with the curtains....) Equally, any company claiming to be able to implement agile simply by putting in place a simple process is making the same mistake. Unless an organisation changes the way it think

I like Jenkins . It handles continuous integration jobs well, and is easy to learn and setup. But I have always wondered why it colours successful builds as blue out-of-the-box. To use green to indicate successful builds you need to install the Green Balls Plugin . Well, those nice chaps at Jenkins HQ have revealed all . It's all to do with Japanese culture, and of course the original Hudkins developer,  Kohsuke Kawaguchi , has a Japanese upbringing. Culturally, in Japan red implies 'stop' and blue means 'go'. You learn something new every day....

(yes, I confess I found the Keep-Calm-o-matic for this and the previous article graphic )

Well, the CALM- Alpha event has come and gone, and some people have already been voicing their views on the conference. From my point of view, it was a bit of a curate's egg - good in places, not so great in others, although we simply got back what we as delegates put in. So what did I take away from the unconference? This is only the beginning There was a reason for it being called CALM- Alpha . This was the first attempt at pinning down common ground between complexity theory (in this case, the work being done by Cognitive Edge with the Cynefin framework). The organisers had no real idea where it would lead, and this was a 'fail safe probe' to test out the possibilities. So no wonder it was at times a little confused. We are only just starting down this path. Hell, I don't think we even know if there is a path there yet! So yes, it was a somewhat painful experience at times. Too much jungle, not enough machetes. But worth it? Definitely . The softw

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.

...they've all got it in for me! Excruciating Carry On pun aside, here's the long overdue link to the talk I gave to the Limited WIP Society  way back in March 2010 (my fault for not posting it here - it's been up on the SkillsMatter website for ages). (Sorry, this is just a link. I can't work out how to embed this directly into the blog page - any ideas, anyone?)

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