The Bamboo Blog

Our thoughts on agile development and web technology

  1. Bartosz Blimke

    Stubbing and Setting Expectations on HTTP Requests Is Now Easy With WebMock


    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.

    If you use Net::HTTP directly then to spec code like this:

    res = Net::HTTP.start("", 80) {|http|

    Continue reading

  2. Damien Tanner

    The Bamboo Hackday


    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.

    We had a couple of opportunities to ask others for help during the day in the form of mini-scrums, but it mostly went pretty smoothly, because everyone is fairly versed in the idea of self organising teams.

    Continue reading

  3. Damien Tanner

    Updating our blog


    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.

    Instead of simply writing cool stuff, we were spending too much time getting Jekyll installed on people’s computers, running into permissions issues with our deployments and generally cursing loudly. The net result that people were saying they couldn’t be bothered.

    Continue reading

  4. Max Williams

    Thoughts on Kiwi.js in relation to Sammy.js


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

    Continue reading

  5. Gwyn Morfey

    The Lego Game


    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.


    • Box of lego
    • Specification document
    • Pile of story cards
    • Pile of fake cash


    One trainer, 3-6 players

    Run 1: Waterfall

    Estimation phase (2 mins)

    Give the players the Specification. Ask them to agree on an estimate (2 mins). Then ignore the estimate and write the actual phase timings (10 min / 2 min) on the Specification.

    Build phase (10 mins)

    Give the players some of the lego bricks and ask them to start building. Halfway through the build phase, give them the rest of the lego bricks. Two minutes before the end, announce that the deadline has been shortened by one minute. Make the process of getting answers to questions difficult and time-consuming - for example, questions and answers must be in writing. Stand on the other side of the room.

    Acceptance testing (2 mins)

    Look for symmetry, colourscheme, size, etc. Find some defects:

    • Wheels? ("it's a plane.. how will it land? you should have inferred it from the specification")
    • Pick a colour (eg red) that's retrospectively not allowed ("it's not in the spec? But we never use red. Marketing hates it.")
    • Announce an "emergency rebuild, since the project is late".

    Emergency rebuild (2 mins)

    Final Assessment

    Add up fines for defects at £100M per minute late (which is actually wrong, and may provoke contract arguments), and £50M per defect. Hand over the remaining cash.

    Run 2: Scrum

    Initial planning (2 mins)

    Join the players. You’ll be playing as both SM and PO. Hand them the story cards, along with a statement of vision. Help them move the cards into swim lanes and write estimates on them, then plan the first 3-minute sprint.

    Sprint 1 (3 mins)

    As soon as a player reaches for a red brick, stop them - no red in the project.

    Continue reading

  6. Bartosz Blimke

    Solving a Problem of Non-Working Key Forwarding With Capistrano


    After I upgraded my Mac to Snow Leopard, Capistrano deployments with key forwarding stopped working. I started getting a following error:

    Permission denied (publickey)

    My fellow Bambinos enlightened me that key forwarding was switched off by default in Snow Leopard. The solution was to change the following two lines in /etc/ssh_config:

    #Host *
    #ForwardAgent no

    to the following two lines:

    Host *
    ForwardAgent yes

    Unfortunately after this change I was still getting Permission denied (publickey) error.

    Today I found the root cause. My ssh key was not added to the authentication agent so the key was not forwarded. The solution was to execute the following command:

    Continue reading

  7. Bartosz Blimke

    Knowledge sharing VI: don't forget the customer


    11. Don’t Forget The Customer

    In a software project you don’t only exchange knowledge between team members but also with a customer. How do we make sure that a person capable of providing required information to a customer is available all the time? We simply follow the practices I mentioned in the previous posts of this series. As a result, we get a whole team capable of providing this feedback.

    We also work very closely with our customers and we keep communication with them as frequent as possible.

    In addition we try to be transparent to them as much as we can. This way, we never have to prepare big status reports and the customers get knowledge about the projects on a daily basis.

    Continue reading

  8. Gwyn Morfey

    Paired Presentations


    We pair code. We pair coaching. Why shouldn’t we pair presentations?

    It turns out that we should, and did. Laurie and I ran a 90-minute session at last week’s Scrum Gathering, talking about some of the new practices we’ve developed in the last year. Feedback from the crowd was good, with the first raising of the Sword Of Integration getting unexpected spontaneous applause. The other paired presentation at the conference, Nigel Baker and Paul Goddard’s session on Enterprise Scrum, was similarly entertaining - the room was packed.

    Now, if it was just about entertainment, we could skip the conference and go see Zombieland. But it’s not: more entertaining presentations are more memorable, and that extends to the content. Tell me ‘be careful of corporate sponsors that, while exerting significant influence in the organisation, risk attaching an aura of fear to the project’, and it might stick, but it might not. Say “BEWARE OF DARTH SPONSOR” while your colleague makes scary breathing noises, and I’ll remember.

    Continue reading

  9. Bartosz Blimke

    Knowledge sharing V: daily stand-ups and big visible charts


    9. Daily stand-ups

    Another great XP practice we follow are daily stand-ups. This is a whole-team meeting without chairs; standing keeps the meeting short. Every team member (or a pair) communicates to the rest of the team, what work was done on the previous day and what still has to be done. This gives everyone an overview of current work status of a whole team. During the stand-ups we also plan work for a given day and assign pairs to user stories. Stand-up meetings are also a good time to share the information about problems experienced and ask for help. Since we work in the open workspace, we use its advantage and we try to raise and solve problems as soon as they arise, without waiting for the stand-up meeting.

    Continue reading

  10. Laurie Young

    Meeting Practices


    We have developed a number of new “Scrum” practices which we apply to our meetings. For us meetings are User Story Workshops, Sprint Planning, Demos, Retrospectives, plus some misc client meetings.

    While we use scrum, and these practices, they are not restricted to scrum, and can be used for any meeting.

    Odd Times

    Meetings start almost on time, but the small delay of a few minutes has already drained the high energy feel from the team.

    Times are naturally rounded. 10:02 gets rounded to 10 and so on.

    Start meetings at odd times. We have our daily scrum at 9:53. This is clearly not the same as 9:52 or 9:54. We now we have replaced not starting on time, with starting with a debate over its 9:53 now?, or now? or now?

    Continue reading