Thoughts from a Thirsty Bear

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

Right. I have to get this off my chest. A follow-on from my habitual coding observation in my previous article . How many people habitually write Java code like this? (Clue: I see it a lot) public class Article { private String title; private String author; private List tags; public void setTags(List tags) { this.tags = tags; } public void setAuthor(String author) { this.author = author; } public void setTitle(String title) { this.title = title; } public String getTitle() { return title; } public String getAuthor() { return author; } public List getTags() { return tags; } } Then you can create an object an use it with something like: Article article = new Article(); article.setAuthor("Cam M. Bert"); article.setTitle("French Cheeses"); article.setTags(Collections.asList("cheese", "food")); // etc etc G...

Working as a jack-of-all-trades agile coach, one of the biggest problems I face is the stagnation of my knowledge. If you do not stretch yourself by working with more knowledgeable people from time to time, you don't develop. You may even go backwards. Prescott's Pickle Principle summarises this as: "Cucumbers get more pickled than brine gets cucumbered" or, put another way, "A small system that tries to change a big system through long and continued contact is more likely to be changed itself" (from Jerry Weinberg's excellent Secrets of Consulting book) Much as I hate to admit it, I am that "small system". So it is healthy and fun to occasionally sit down with like-minded people, and re-baseline your knowledge. That is exactly what I did the other Saturday. I survived a dull and freezing Wimbledon to attend Jason Gorman's " Intensive TDD Workshop " (the one-day super-intensive version of this one ). I won't go i...

Move along. Nothing to see here. public class HelloWorld { public static void main(String[] args) { System.out.println("Hello World!"); } }

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