Archive for category Lonely Planet SPP Dev Team
Turn any wall into a whiteboard! This stuff is the bomb.
I haven’t used this brand before, but there are a few variants on the market. Once you get over your fear of writing directly on the wall, being able to write anywhere is very liberating.
At Lonely Planet, there was a team war-room where all the walls were painted with whiteboard paint. The kind we had wrote well, and erased well too. For a while, we had an entire business case sketched up on the wall and stakeholders could come and talk through the whole thing. We could change the slides right there on the wall, on the fly. A great place for thinking. Look out though, your wall is going to look like this in no time!
Here is another brand.
Special props to Nigel Dalton and Gus Balbontin on this one.
Are the stories that are talked about in planning always the ones that actually get played during a sprint? In an ideal world they are, but seldom does a sprint run according to the ideal.
This team was getting a lot of work done, but still seemed to have cards left over at the end of a sprint. Were the cards taking longer than expected? Were additional cards being added? No one could quite be sure.
One of the team members came up with a solution. After the team had agreed the stories that would be played for the upcoming sprint, he took a photo of the cards. This provided a visual record of what the team had agreed would be done.
It was stuck up next to the backlog and as cards were completed they were ticked off on the photo. At the end of the sprint it was easy to see what had got done, or not, out of the planned cards, and which new cards had been added into the sprint.
This is a great example of a team member taking matters into their own hands and using their own visual language (photographs) to come up with a fresh take on planning.
Spotted: SPP development team
Retrospectives are the place for everyone to have their say on what’s working and what isn’t. But does everyone have their say? Who’s talking? Who’s not?
Sometimes it’s hard to tell who speaks and who gets drowned out. To get to the bottom of this, one of our team began mapping who spoke during the retro, almost as a doodle. It’s a simple idea which has been evolved by other members of the team as they had a go at it. The latest incarnation of the heat map shows who is interacting with who. The secret sauce here is empowerment. This mapping process started because Dan felt empowered to just do it, and each subsequent team member who evolved the map felt empowered to adapt and improve it.
When you can easily see who’s interacting and who’s not, you can see where the whole team is missing out on important contributions from some members, and we can ask why.
I’ve talked about cards that are never going to get prioritised and should end up in the Dead Card Cemetery. But what about small cards that are important enough to keep in the backlog, but that keep getting deprioritised behind other things in the backlog? I’m talking about the really tiny ones, often bugs, no more than half an hour’s worth of work. Maybe you could try an opportunity bucket.
A purist might say that if a card is important enough to be worked on then it will be prioritised into the backlog. But actually, there are always things that have too little value on their own to be prioritised. The team I currently work with created a ‘bucket’ of these at the bottom of their board. Cards get plucked from the bucket if it’s late in the day and not worth picking up a bigger card from the main backlog, or if they’re doing some work in that part of the code anyway and can fix something from the opportunity bucket while they’re in there. It’s proved to be a great way to knock off tiny cards that would otherwise have languished in the backlog.
Spotted: LPOS development team
Teams get their best work done when they can concentrate and focus on the task at hand. Switching back and forth between different tasks interrupts your train of thought and it can take a long while to get back on that train. Tom DeMarco recognised this more than a decade ago when he wrote “Peopleware“.
But of course sometimes interruptions are unavoidable. When we say we value conversations as the highest-bandwidth channel of communication teams can use, we are inviting interruption. Or someone from another team has a technical question. Or sometimes a production issue comes up that needs immediate attention, or a developer is the only person who can help unblock someone else’s work.
So how can we minimise these interruptions? The team chose a ‘fireman’. Someone whose job it is to extinguish any of these fires as soon as they happen. Team members take turns to be the fireman, and the fireman for the day is clearly shown on the team board so that everyone knows who they can tap on the shoulder to help them. As well as keeping the rest of the team focused on their work, it means the people with the questions don’t feel guilty about interrupting someone.
Spotted: LPOS development team
Team says: “That bus is getting full. Looks like it might be an Indian bus“.
Ok. You have achieved continuous delivery. You can now release your features whenever you like. But how do you know when it’s time for a release? You want to keep the value flowing out to your customers. How do you track which cards are going in the release?
One way is to use a release bus.
All the stories that will go out with the release are moved onto the bus as they are signed off. There are limited seats on the bus – when the seats are all full then it’s time for a release. There’s no reason to wait until all the seats are full though, a release should still happen whenever it’s required. On the other hand, a release bus that has run out of seats is a sure sign that there are getting to be too many stories in the release and that it might be a good idea to release in order to minimise complexity and risk.
Spotted: LPOS Team
Dan says: “Just for interest – I thought it would be interesting to see whether any notable patterns came out of it.” – Dan Heath
Sometimes at retro it’s hard to remember everything that went on during the iteration. And sometimes you don’t spot problems at the time they are actually happening. There’s just too much going on.
The brilliant Dan Heath set up a camera with a script which took a photo every 5 minutes and stitched them together as a movie. The team can watch the iteration at retro and can see the cards moving (or not moving) on the wall. Where did they become blocked? Anyone remember why? Who took the last bit of cake?
Dan’s script stitches the images together into a month by month archive of activity on the board, and it only captures images during working hours, so you don’t get hours of spooky darkness.
He was happy to share his scripts. Here are the crontab entries, other scripts are available by email (although Dan warns they were done as a really quick hack job – “the nastiest hack I’ve written since uni”):
# ************* Crontab ***************
# m h dom mon dow command
*/5 8-18 * * mon-fri export DISPLAY=:0 && /home/robh/boardcam/vlc-cmdline/run.sh
1 19 * * mon-fri /home/robh/boardcam/vlc-cmdline/run_daily.sh
Spotted: LPOS development team
Team says: “The days are decreasing at exactly one per day, but the feature cards definitely aren’t!”
We’ve seen agile burn-down charts many times. But here’s a different approach. This team runs a lean/kanban board, and they don’t estimate in points, so they decided not to use the traditional burn-down chart. Sometimes, there are immovable deadlines and in this case an author was going on the road to research a destination. Tickets were booked long ago and there was no possibility of delaying the release.
As the release date approached the team simply kept track of the number of feature cards versus the number of days left. This was a nice simple metric which stared them in the face every day, and gave urgency to the task of ruthlessly cutting scope to meet the date. The days always decrease of course, but the card count can increase as additional stories are uncovered. Sometimes product owners can be reluctant to cut scope, but this made it painfully obvious that it was necessary in order to meet the release date. When the number of remaining cards fell below the number of remaining days the back of the beast was finally broken.
Spotted: LPOS Team