The Bamboo Blog

Our thoughts on agile development and web technology

  1. Damien Tanner

    The Bamboo Hackday

    by

    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

  2. Damien Tanner

    Updating our blog

    by

    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

  3. Max Williams

    Thoughts on Kiwi.js in relation to Sammy.js

    by

    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

  4. Gwyn Morfey

    The Lego Game

    by

    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

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

    Players

    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

  5. Bartosz Blimke

    Solving a Problem of Non-Working Key Forwarding With Capistrano

    by

    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

  6. Bartosz Blimke

    Knowledge sharing VI: don't forget the customer

    by

    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

  7. Gwyn Morfey

    Paired Presentations

    by

    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

  8. Bartosz Blimke

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

    by

    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

  9. Laurie Young

    Meeting Practices

    by

    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

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

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

    ###Practice:###
    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

  10. Laurie Young

    Talking at Scrum Gathering

    by

    Gwyn and I presented our Bamboo Toolbox at the Munich Scrum Gathering on Tuesday.

    The gathering was my first Scrum Gathering, and was one of the most enjoyable, friendly, and all round rewarding events I have been to.

    We had the presentation slot just after lunch on the second (of three) days, and just before the board panel, which I expected many people to skip, and use as a chance to see Munich. In short, possibly the hardest slot of the conference to attract an audience to! great!

    So I was flattered and surprised when the room started to fill up 15 minutes before the talk, and by the time we started, all the seats were taken, and people were having to start sitting on the floor.

    Continue reading