At XP day, I said that we no longer put any reference to scope in our contract. I was immediately challenged to explain, and targeted by a 'Heatseeking Action' - a practice we'd introduced only a few minutes ago - to do so by 12:03 on Thursday. So here are the details.

The contract represents a tiny subset of the communication that happens when a project starts up. By the time the contract's signed, we've agreed a vision, run a stories workshop, prioritised the backlog, drawn up risk factors, discussed likely velocity, and drafted an approximate release schedule. Collaboration is more important than contract, but - particularly for senior stakeholders - contract is still important, so here's what's in ours:

Read more...

Scrum Check is one of the tools that Laurie and I presented at XPDay on Monday. It's a short checklist that helps multitasking scrum masters to prevent any of the Scrum basics from slipping. For best results, take once daily, preferably by turning in a slow circle from your desk.

In fact, for best results, write your own. But as a starting point, here are the questions that I'm currently using:

Read more...

What do you do when you have one person who is the repository of knowledge for a critical part of your project, infrastructure or similar.

You need some way to address this situation, otherwise that poor person will go mad dealing with other peoples problems, never feel free to go on holiday, and if they get hit by a bus you really are in trouble.

Steven Williamson at youDevise told me a cool technique they use to fix this problem, they use Horace. Horace in this case referred to a stuffed toy. A woolly mammoth to be precise.

Read more...

Here at New Bamboo, we specialise on Ruby On Rails web development. However, we started talking more and more about exciting things happening around HTML5 and javascript during morning standup (where we talk about all the cool things we are working/have discovered) , lunch time and our company hack day.

Read more...

I've been working recently on a Ruby application which was making HTTP calls to a remote service. We chose rest-client as a client HTTP library. We needed some way of testing the behaviour we were going to implement.

We wanted to run our tests in isolation, without making any real requests over the Internet.
One obvious option was to use some mocking library to stub rest-client methods and set expectations on them. Doing this is always a pain. You usually end up testing the implementation instead of behaviour.

Read more...

I've been working recently on a Ruby application which was making HTTP calls to a remote service. We chose rest-client as a client HTTP library. We needed some way of testing the behaviour we were going to implement.

We wanted to run our tests in isolation, without making any real requests over the Internet.
One obvious option was to use some mocking library to stub rest-client methods and set expectations on them. Doing this is always a pain. You usually end up testing the implementation instead of behaviour.

Read more...

About a week ago we tried something new in Bamboo HQ. We had a hack day. This was a day we had set aside in advance where we didn't schedule any client work to be done. In the days leading up to it we filled up a whiteboard with ideas to hack on during the day.

We didn't really know what to expect because we'd never done it before, but it actually went really well. We had a scrum as usual in the morning, where people had a final opportunity to 'pitch' their ideas to get others to work on it. Some people joined forces to collaborate on ideas, whereas others worked on their own.

Read more...

This week we ported our blog from Jekyll to (and I mention this anticipating a wave of WTFs) a custom rails solution we built in a few hours. The reasons for doing so were numerous, however the primary one was that it was causing a blocker for people writing posts.

Over time, and much to our surprise, we found that it is much easier to log into a web system to create a post than mucking around with the technical tools we use on a daily basis.

Read more...

A little while back, I posted about Sammy.js and how it had simplified the way I was designing client side applications. In the meantime, my usage has grown to the point where I need a bit more structure, in a similar way to how an application originally built in Sinatra may at some point be moved to Rails to take advantage of some of the conventions there.

With this in mind, I have been looking for something to represent the 'Model' aspect of my application to abstract some of the Ajax requests. What I found last week was Kiwi.js which aims to provide the m the v and the c for the client-side world. I have spent some time this weekend investigating Kiwi, and really like the way it works (see appendix).

Read more...

At Scrum Gathering we presented a lego game that we use to teach prospective clients about agile projects. We've run this game twice internally and once with live clients. There's quite a detailed structure below, but running the game involves a lot of improvisation; really, it's about throwing up the same set of obstacles both times, and showing how an agile approach makes them less painful.

Materials

Read more...