Archive for September, 2009

Six impossible things before breakfast

September 30, 2009 4 comments

Alice laughed: “There’s no use trying,” she said; “one can’t believe impossible things.”

“I daresay you haven’t had much practice,” said the Queen. “When I was younger, I always did it for half an hour a day. Why, sometimes I’ve believed as many as six impossible things before breakfast.”

Alice in Wonderland.

Creativity is a cornerstone of software development. Believe it or not, this is something one can exercise. A great way to train the creative part of your brain (right hemisphere) is to daydream or think about impossible things.

Why don’t you try it and follow the Queen’s advice ?


Make this exercise part of your daily stand up when working on an Agile team. Ask your team members to come up with an impossible thing each. You’ll see how much fun this can be. Make sure they think about it before the stand up starts.

You can also do this exercise at home with your partner or kids. If you do this on a regular basis you will see your creative side improving.

We came across this idea in Tony Buzan’s book “Head First” and practiced for a couple of months. It can actually be challenging to come up with new impossible things every day.

By Barbara Mayerhofer and Marcos Tarruella


How Scrum Saved My Wedding

September 18, 2009 4 comments

So what does a couple do when they are getting married in less than two weeks, and there is a pile of things to get done for the wedding? Well, when the groom-to-be is me, the obvious answer is that they organize the work using Scrum. I had floated the idea to my fiance a little while ago, and she wanted nothing to do with it. In her mind she felt that a list on our whiteboard would be just fine.

When we found ourselves a mere two weeks from the big day, I once again asked, “are you ready to do Scrum yet?” She reluctantly agreed, tweeting her displeasure for the world to see and we got underway. We knew there was a pretty big list of things to do so we started off with a Blitz Planning session.

I grabbed a stack of sticky-notes and we started to blurt out tasks that needed to be completed if this wedding was going to fly. As the tasks were identified I jotted them down onto the sticky-notes. Once we felt that we had a fairly comprehensive list, we took a few minutes to give each story a complexity value. A value of 1 was fairly trivial such as “pick up the wedding rings from the goldsmith”, while a 5 was reserved for things such as, “write our wedding vows.” We stuck with the Fibonacci numbers to allow for uncertainty in the larger tasks.

Since we had approximately two weeks before the wedding it made sense for us to have two, one week Sprints. With a table covered in pink sticky-notes, we moved each of the stories into one of two piles representing each Sprint. Now we were able to do a more fine-grained planning of each Sprint.

We knew that the more complex stories had higher risk associated with them so we made sure to start those as early as we could. We did however remain mindful to not overload Sprint 1 with only the large stories. There were some stories that needed to be done on certain days, and some that had dependencies on other teams which required some clever shuffling.

It didn’t take very long before we had our Scrum board organized into two Sprints. We split the board into columns representing each day allowing us to put the story cards onto the day we intended to complete them. This gave us a really good visual representation of the work ahead. This layout is actually very similar to the Scrum board my team at Point2 uses. Having a visual representation of when stories are scheduled to start and expected to finish is a great tool for the team, as well as stakeholders to get a sense of how well the Sprint is going.

We’re about halfway into Sprint 1 and things are going as I was expecting. Stories are being burnt up on a daily basis, while some of the more complex ones are taking longer than we had initially estimated (sanding and re-staining the kitchen light fixture…..which needed to be done prior to our rehearsal dinner at our house). Some stories we had hoped to start on a certain day have not yet started, while some were completed early. We’ve also seen a couple of new stories injected into the Sprint requiring us to reshuffle the board.

Obviously the Scrum process at home can only be, “Scrum-like”, but as the Sprints progress I am seeing many of the same things that my Scrum team at Point2 experience from Sprint to Sprint. So maybe Scrum isn’t actually going to save my wedding since I don’t think it was ever in jeopardy, but I do think it was a great exercise to see how applying an Agile method in a completely non-technical area yielded many of the same results seen in the software development industry. If anything, applying Scrum to the wedding preparation was a useful tool in devising a plan, allowing us to visualize and execute that plan, and have a little fun along the way….geek-style.

By Hemant J. Naidu

Operating From Above the Line

September 11, 2009 1 comment

When something goes wrong all humans tend to respond to the problem in the same way, no matter how big or small. At Agile 2009 Christopher Avery described what he called the Responsibility Process – five mental states that people naturally enter before reaching a true level of responsibility. But keep in mind that not everyone is able to successfully move out of all states of mind prior to responsibility, as Avery described. In order to be successful at this one must apply these techniques themselves, and recognize that they are in a specific state of mind. The graphic below illustrates the five states of mind.

The Responsibility Process

Lay Blame
After a problem is discovered a person will naturally try to account for the failure. They will try to externalize the cause as laying outside of themselves. Their first response is more-or-less, “there is no way that I caused this issues, so it must have been someone else.”

Once it is realized that the problem may have been caused by oneself, a person will try to justify why it happened. They are still trying to externalize the problem when they make excuses such as, “well there is no wonder that broke since I was being rushed to complete it.”

Once you move past trying to justify the cause of the problem a person will start to acknowledge that it was in fact their fault. While in this state of mind people tend to beat themselves up with statements such as, “oh I totally screwed that up. I can’t believe I made that mistake. It was totally my fault.” We must be careful not to confuse this with responsibility – it is actually self-shame.

After self-shaming oneself a person will start to feel that that yes, they caused the problem, but the circumstances they were in didn’t give them any other choice. People will make statements alluding to having no control, or feelings that they are in handcuffs. “Well, that is just the way we were told to do it so I did it”, is a telling statement.

If one can move past obligation a person will move above the “line” and reach responsibility. The previous four states of mind are considered non-learning states – or to put it bluntly, we are stupid while in these states. We are in a coping stage and any decisions we make will probably be poor. But as we move above the line into responsibility we will find ourselves back in a “learning state”. It is here that we can make good decisions, and can start to produce value. Hearing things like, “the problem happened, but now let’s figure out how to fix it”, is a key indicator that someone is operating from responsibility.

The two grey stages in the diagram are not states of mind, but are additional stages. We are usually in a denial, believing that everything is fine and no problems exist. However once a problem is identified some people will not be able to cope. For instance the mental anguish of shame and obligation can lead a person to check-out without reaching a proper resolution. By quitting, a person does not learn anything and will likely be faced with the same problem in the future.

In order to get above the line, there are three keys. Intention states that a person must be committed to doing something. A person must also be aware that they are in one of the levels. To do this we must look for it in ourselves, and ask for the help of others to identify where we are. Avery suggested recognizing how you feel in each of these stages, and use that feeling in the future to help identify your state of mind. And finally we must confront the problem – you cannot interact with something until you are able to face it.

Obviously this stuff is based on behavioural science and it can be easy for technical people to dismiss. But be honest with yourself and think about these states of mind the next time you face a problem (this works in all aspects of your life – personal and professional). I know that my first reaction to a problem is to assume that someone else caused it. The key is to realize this and get past it. As one gets better at identifying what stage we are in, the quicker we can move from state to state. We always want to be producing value, so the goal is to operate from responsibility as quickly as possible.

By Hemant J. Naidu

Blitz Planning at Point2

September 8, 2009 4 comments

One session that I attended in Chicago at Agile 2009, and thoroughly enjoyed, was Alistair Cockburn‘s Blitz Planning workshop.  First, Alistair is an engaging speaker and is full of great ideas.  Second, it was the last day of the conference and I was eager to start trying some of these new tricks, tips and techniques I’ve learned about all week at home at Point2.

Blitz Planning results in “getting the contents of everyone’s head into a common space” and is meant to be speedy.  In the 90-minute workshop we planned a non-technical workflow (the process of getting up in the morning and getting out the door), then we planned an information kiosk system start-to-finish, and identified the earliest we could do the initial rollout.


Ideas are recorded on index cards by all members of the team as they come to mind and are not subject to scrutiny by other team members.  As a team member writes on a card, they call out their idea to help avoid duplication, and to spark more ideas from other team members.  When the team feels the plan is near complete, the cards are laid out on a table in chronological order, the plan is checked for completeness and any dependencies are identified.  At this time cards may be torn up, and more cards may be written to fill the holes in the plan or re-work it to remove dependencies and shorten the critical path to allow early delivery.  Alistair introduced the concepts of the “technical walking skeleton” and the “business walking skeleton” which contain the bare minimum to make it work, and the bare minimum to provide business value, respectively.  Your earliest possible delivery consists of both the technical and the business walking skeletons.

Unlike the information kiosk example at the conference, the project we planned touches existing systems and contains many moving parts.  Instead of 20-30 minutes to design a system and discuss it, we took an afternoon to write the cards and discuss, and we have more discussions and card-shuffling sessions planned for the next few days.  So far it’s been an interesting exercise and I feel like we’ve identified several potential problems early.  I’ll keep you posted.

By: Tefon Obchansky

Maven with included Dependencies

September 4, 2009 1 comment

One of the most common, and, in my opinion, valid criticism’s of Apache Maven is the way it handles dependencies.

The default way of doing dependencies in Maven is for a build to look for dependency jars in one of a specified number of places. If you don’t specify a location, it will start with your local Maven repository, then a stock set of online repositories (such as ibiblio).

What this means is that you can quickly and easily add a dependency to your project by just listing it in the POM, and Maven will frequently just go get it for you as required. For dependencies that don’t change rapidly (which is generally a bad idea for entirely separate reasons), the local copy is always used, so after the first download you don’t go get the jar again unless it changes.

The downside of this (and hence the basis for the criticism) is that your local repository is considered a cache, and is not checked in to your source control system. Maven aficionados believe that source control should be for what the name implies: source, not jars (which are an artifact, not source code). This is good, except in situations where the local repository is removed (as it’s a cache, and not “backed up” by being in source control) and you want to rebuild your project. Normally, no problem: Maven will simply go back out into the wilds of the internet and get your jars for you again. Except when it can’t, which is where the problem starts.

Let’s say your project depends on foo-1.0.jar, for the sake of discussion. Foo-1.0.jar is found in a repository at No problem. Two months from now, you come back and make a change to your project, and your local repo doesn’t have foo-1.0.jar in it. Maven goes to get it for you, but has gone offline. Oops. Now you can’t build your project at all. Worse, let’s say you *do* find foo-1.0.jar, but it’s been updated. Granted, this is a gross violation of the version scheme, but as is not under your control, it *can* happen – and Murphy was an optimist.

The first level of defense against this is to have a local jar proxy that *is* backed up, like Nexus. Nexus not only provides a safe haven for the exact versions of Jars you need to build your project, but also proxies new jars automatically, when set up correctly. That way, once you use that external dependency, it’s available on the local proxy immediately forever more, in precisely the correct version.

This solution is so good, that I always consider Nexus and Maven to be two parts of one solution – as you don’t really have reliable and repeatable builds without Nexus in the mix.

Another way to go, however, is perhaps even more straightforward, and might be appropriate if you have a limited number of “internal” binary dependencies – that is, binary dependencies that you generate within your organization between projects.

This is the option I want to describe in this blog, and it takes a form very similar to the old Ant style of having a “lib” directory in your project, and checking jars into source control.

You simply create a directory (called lib or whatever you wish, but “lib” might be more standard), and put your jar dependencies in it. Then you refer to each dependency in your pom.xml file with a special syntax, like so:


Now the myjar-1.0.0.jar will be on my classpath during compilation, easy as that. I can then check in that nicely versioned jar file, and have a fully self-contained project, while at the same time being able to leverage the power of Maven and it’s rich ecosystem of plugins. If you’re using the shade plugin, this is an excellent way to create a self-contained executable jar file containing all of your necessary dependencies in one shot, rather than having to worry about classpaths at runtime.

In web applications, you can do even better. By placing the dependency in the correct spot in your source tree, you can have it automatically included in the finished .war file, while at the same time finding it in your classpath during compile time, like so:


This includes the xstream jar in my webapp. Every IDE that can digest a POM file (which include my 3 main ones, IntelliJ IDEA, Eclipse IDE and Netbeans) also automagically find the dependencies.

One minor constraint here is that you must use a *versioned* jar file – e.g. it must be named according to the artifact-version.jar pattern. I consider this a feature, not a limitation, as I’m a firm believer that all artifacts should be properly versioned, so I can tell what source code originally created them. Yes, I know that can be done internally, in a manifest or such, but I like to see the label on the outside of the box, so to speak.

As one colleague put it, now you can be assured of coming back to your project months or years later, even if you don’t have internet connectivity, and be able to build the darn thing again, without going off on a wild jar chase all over the internet.

This pattern can overcome a serious and legitimate objection to Maven, and might be appropriate in many situations. Give it a try, let me know what you think!

By: Mike Nash

TeamCity – Using Personal Builds to help improve cycle time

September 3, 2009 Comments off

So you are working on a large project, many developers committing regularly to the same code base, you run all the unit tests, commit and you break the build. Now everyone on your team is angry (As they should be!). How could this have happened when you ran all of the tests? The reason is that you did not update before running tests locally and committing. The problem is that constantly updating and building can waste a lot of time. Even if you do update, run all tests, then commit, there is still a chance another developer made a commit during that cycle. The solution: Team City Personal Builds.

Personal Builds

The great people at JetBrains have a feature in TeamCity that allows you to use your build server build agents for “Personal Builds”. More great news is that TeamCity plugins that make use of this interesting TeamCity feature are available for IDEs such as IntelliJ and Visual Studio.

So now when you use your IDE tool with the TeamCity plugin you would use the “Remote Run” option to make your commit. TeamCity will then spin up a personal build, apply your code changes to a fresh checkout of the repository, build, and run all unit tests. If your “Personal Build” passes, your code changes will be committed. Now, here is the great part, if it fails, your code changes will NOT be committed, and you will be notified of the failure.

This feature of TeamCity allows developers to get out of the update, run all tests, and commit cycle and offload some of that work to their TeamCity server.

IntelliJ Plugin Setup

  • File->Settings->Plugins
  • Click on the “Available” tab
  • In the search box enter “TeamCity” (The option JetBrians TeamCity Plugin should show up in the list)
  • Right click on the plugin and select “Download and install”
  • You should see a TeamCity option on your IntelliJ toolbar
  • Enter your TeamCity credentials, setup your notifications

So now, when you commit use TeamCity – > Remote Run rather than using the Version Control menu. You will be notified if your commit is accepted or rejected.

Visual Studio Plugin Setup

To download the Plugin, login to your TeamCity server, go to the “My Settings & Tools” page. You will find a download link for the plugin in the “TeamCity Tools” panel on the righthand side of the page.

by Brian Richardson

Top 10 Tips for an Agile Coach

September 3, 2009 Comments off

While at the Agile 2009 conference last week I had the opportunity to attend a session by Rachel Davies and Liz Sedley outlining some great tips for an Agile coach. Their presentation was based on their upcoming book Agile Coaching. They were approaching the topic as though they were an external coach brought into a company just starting Agile, but there was definitely some good take-aways that could be applied in any situation. I will do my best to regurgitate their discussion in hopes that you can make use of them in your coaching endeavors.

10. Get Introduced

  • What are you trying to achieve, what is your expertise? Experience?
  • Explain what you expect from those you are coaching.

9. Agile is not a Religion

  • Try not to come out as a preacher – this will likely switch the team off.
  • You must first understand the team’s circumstances before fixing things.

8. Show Respect

  • Understand the team’s history.
  • Do not tell them they are doing things wrong.
  • Listen to them and find out how they started doing things the way they are.
  • Understand the factors that led to the circumstances they are working in.
  • Be mindful of your language – use names and not labels (refer to people individually)

7. Step Back to See the Big Picture

  • Do not get caught up in individual interactions.
  • Look at the “system” as a whole – the way people are acting is usually a reflection of the forces acting upon them.
  • Do not fix the people, fix the pressures that are acting on the people.

6. Ask Questions to Spark Ideas

  • Improve the team’s thinking so they can think for themselves.
  • Well raised questions challenge people – allow people to discover their own solutions.
  • When a team is struggling, ask them about it – how can you guys make things better?
  • Do not ask why, rephrase the questions.
  • Ask a “thinking” question.
    • How long have you been thinking about this?
    • How do you think this will help?
  • Use the Five Why’s (RCA)
    • Root cause analysis asking “why” five times.
    • Explain why you are asking why five times – tell them what you are doing.
  • Do not ask a question if you really want to tell the team something – you will lose the opportunity to ask it.

5. Take Time Out to Reflect

  • Do not react to everything right away – do not rush into an answer because you are the coach and feel it is expected.
  • Better to think about it and come up with a calm solution, than to panic and provide an answer you have not fully thought about.
  • Agile Retrospectives is a good time to go over these things.

4. Introduce the Elephant

  • If you notice an elephant in the room, casually mention what you see (maybe in a retro).
  • This hopefully will spark conversation – do not push the team into talking about it if they are not ready to.

3. Make Change as an Experiment

  • “Let’s try something for a short period of time and see if it makes things better.”
  • Enable them to evaluate the results and decide as a team whether to continue.
  • Getting the team used to small changes. It becomes easier to introduce larger changes later.

2. Go With the Energy of the Team

  • What is the best problem to tackle first?
  • The one the team wants to solve – it may not be the most important, but it will get the team going.
  • Give the team ownership, and get them going on devising a problem solving solution that will be pertinent in the future.

1. Have Courage in Your Convictions

  • Understand that you are introducing change, but people generally do not like changing.
  • Have faith in your own ability to help the team.
  • Be passionate about what you are trying to accomplish with the team, and be clear about what you are trying to accomplish.
  • Ensure that they do not feel like you are pushing too hard – do not push until they are ready.

By Hemant J. Naidu