We’ve been working with a new client helping them understand how Scrum will work in their environment. They are getting ready to transition their team to start sprints. To help the team keep focus on the right things, the Scrum Master and Product Owner put together two 1 page summaries of the Scrum meetings and Daily Scrum. We loved them so much we asked if we could share them here.
More and more people want to work from home. Here are some books we’d recommend on the topic of working remotely:
- Remote: Office Not Required by David Heinemeier Hansson and Jason Fried
- The Year Without Pants: WordPress.com and the Future of Work by Scott Berkun
- There’s No Place like Working from Home by Elaine Quinn
- Agile Software Development with Distributed Teams by Jutta Eckstein
- Manager’s Guide to Virtual Teams by Yael Zofi
- Big book of Virtual Teambuilding Games by Mary Scannell, Michael Abrams and Mike Mulvihill
Here are the new images with the translations, feel free to use them and share them.
A few weeks ago a company contacted us. They needed help. They were busy with a super important project and wanted to do it the agile way, and were a bit stuck. The business and management people were in City A and the dev team were in City B. They had a bit of previous agile experience in the development team but no-one else really did.
We suggested a remote call with everyone in both cities to understand where they were at. We had no idea what would happen, we were simply there to understand and perhaps guide. This 2 hour session turned out to be our best remote session yet!
As preparation for the call, we sent an email a few days before asking everyone to install Zoom (our remote conference call tool of choice) and asking that everyone dials in by themselves using a headset even if they are in the same location. We also gave them a trello board to connect to.
We started the call with everyone introducing themselves and what they do, so that we had a better idea of who we were talking to. The developers all dialed in. The business in City A dialed in together from a conference room, and a manager dialed in separately.
Immediately we could notice the difference in call quality. The group in City A was hard to hear, you were not always sure who was speaking. We also learned that Zoom adjusts volume, so every time someone far from the speaker spoke Zoom adjusted which meant we could barely hear the next person.
Tip 1 – insist that everyone dials in themselves, rather than using a conference phone in a meeting room. (Though having them experience this was also a valuable lesson.)
We then checked that everyone could access the Trello board and shared the link again. We gave everyone 5 minutes of silence to brainstorm talking points or questions onto the trello board. We needed to mute the group in City A as they had one PC and were chatting to type up and disrupting everyone else. (We needed to do this for every “silent brainstorm” we had, and mostly we forgot to unmute them until it was pointed out – so if you have this problem, don’t forget to unmute!).
After the brainstorm we asked everyone to vote for their top 3 topics. There is a nifty power-up for Trello that allows this called “voting”. Once again the group in City A were disadvantaged as they could only vote once for a topic as they had one PC, we solved this by asking them to type in the chat window what they want to vote on and we just included that in the count.
We then spent the next 90 minutes or so talking about their number 1 topic…. though I think almost every topic was touched on!
This is the fun part – we wanted to make this interactive and visual to keep everyones attention – so we were trying something new. We had attempted this a few days before and the technology had failed spectacularly – so we were prepared with plan B, but never needed it
Justin Kotze relocated last year from Cape Town to Stockholm to become an Agile Coach at Spotify. On a recent trip home he shared his top 10 Aha moments so far. Here are Sam’s sketchnotes from the talk.
Linked In:https://www.linkedin.com/in/jay-allen-morris-26bb4643/ Twitter:@JayAllenM
The idea for this retrospective came from specific problems the team was having and, of course, from my obsession with Lego. I can’t credit this idea only to me because I think I picked up parts of it from talks and workshops I’ve attended over the years. I never thought it would be universal, but I shared the idea with someone else and they had the same positive result.
Problems that lead to this:
The communication in the team was broken, they weren’t working as a team, stronger personalities would often overtake the quieter ones and not listen to them. There was lots of silo work going on. All of this had been going on for a while and these issues weren’t coming up in retrospectives. I tried to think about how the team could gain awareness of their behaviour without me explicitly pointing it out as “wrong”. I came up with this Lego retrospective idea, not knowing if it would work but decided to experiment. Below is a description of what you’ll need to try it out for yourself, feel free to make alternative suggestions for improvements.
- Mix of lego, the more random the better
- Pen and paper for the observer to write stuff done
- A large table for the team to play
- Markers and flip chart paper for the team to plan
This particular activity needed the assistance from an outside observer, I didn’t want to use someone from inside the team because I wanted the whole team to participate.
NB. I asked for the team’s permission beforehand to use an external observer and since this person was close to the team, it did not interfere with their safe space. If you do not have such a person then it might be better for the facilitator to be the observer, although it might be tricky to do both.
Summary of activity:
Get the team to work together to create a Lego construction and have the observer write down the team’s interactions with each other and the activity.
Opening the Box: You can use any check-in exercise to set the scene for the retro, helping them focus on the last sprint
Finding the Right Pieces: I explained to the team that this was the section where our observer would come into play and for the most part, she is to be ignored. Then the fun began.
They had 10 minutes to discuss and plan what they were going to build based on what they had in front of them. Then I gave them 30-40 minutes to build something that represented their last sprint with the Lego they had in front of them, with no restrictions on what they could build, the only rule was that they had to build one thing as a team. The reason I did this was so that they had to communicate as a team and create something that represented all of their experiences.
During this section the observer is jotting down observations and interactions, her role will come into play a bit later.
Once the time was up they had to review what they had done and have a mini retro explaining what they learned.
They ended up building a space prison with the heads of the prisoners on spikes, lasers shooting down visiting ships and a solitary confinement chamber. You can only imagine what was going on there. During their mini retro they highlighted the negative things with the sprint based on what they had built.
Connecting the Bricks: Now for the cool part. I said to the team the observer will merely read out what she had written down and observed. Examples of things she wrote down were:
- Andy always interrupts Arnold
- Isla speaks up but everyone ignores her
- Rachel tries to get everyone back on track but get’s spoken over
- Arnold broke away and started building his own thing
- Andy gave everyone clear directions on what do
- No one really listened to anyone else
What’s very important is that the observer did not make any judgements about the team’s behaviour she merely read back to them what they had done.
What was great was seeing the team nodding in agreement in what was read out and in my opinion hearing it in an objective way gave them insights into their own behaviour that they might not have noticed.
We then had a discussion around some of the things they were aware of and some of the things that surprised them. Some of the insights that came out were:
- They weren’t finishing sprint work because they weren’t communicating effectively and also not respecting what each other had to say
- They weren’t completing stories because they weren’t working together as a team nor communicating effectively with the product owner
- The realised traits about their own behaviour that were hindering their success as a team
Pick a Brick: They had a long list of improvements that they could change. The thing they decided to work on first was their communication with each other. They came up with suggestions on how to do that better (including not interrupting each other!). Everyone was an owner of this and we agreed to check in at next retro.
We kept the list as a reminder of the observations that came up and to be used in the future to see where we are going.
“Everything is awesome, everything is cool when you’re part of a team”
We closed the retro off with thanking someone in the team for something they had done or just for being the way they are.
Despite the earlier anger and frustration represented in the space prison, the retrospective ended on a positive note
I was lucky enough to attend the SUGSA meetup with Mark Pearl talking on Mob Programming. Mark is a developer coach from South Africa who has recently immigrated to New Zealand. He is one of the few South African’s I know who has deeply explored Mob Programming and consciously gone about learning what makes it successful. I was excited to hear what he has learned about the topic.
For those of you new to Mob Programming, his definition was simple: Mob Programming is when 3 or more people get together at a single computer to solve a single problem.
Here are some of my key takeaways from his talk:
- Don’t expect your first Mobbing session to be awesome, when he started they held a retro after every session to learn how they could improve.
- Mob programming helps improve productivity by directly preventing things that destroy productivity like (multitasking, interruptions, waiting for info, being blocked, technical debt, etc)
- It will take more man hours to get a feature into production using Mob Programming rather than a single developer. The benefits usually help after that.
- Don’t try to justify Mob programming financially to management before you start, just book a meeting room and try it out.
- Physical setup matters, a meeting room is fine to start, but if you want to do this regularly it needs to be possible in your normal work environment.
As someone who has spend most of the last 5 year’s pair working, I was quite interested to hear how Mark thinks Mobbing is different to/better than pairing. Here is what he said:
- Mob’s are less likely to be swayed by one strong individual.
- Mob programming is substantially less confrontational than pairing
- If one person needs to leave a mobbing session work can still continue, with a pair it stops.
- In general because you can take breaks when you need to without interrupting the flow of work, it is possible to sustain longer mobbing sessions that pairing sessions.
- In pairs, problem solving is limited to the smartest person in the pair, groups of 3 or more have been shown to solve problems beyond the capability of any single individual in the group.
Mark is also busy writing a book on Mob Programming with his learnings: https://leanpub.com/GettingStartedWithMobProgramming
We were recently at a client who wanted to encourage healthy conflict within their teams. This is a common desire amongst teams who have become very easy going with their process. Usually some signs are: everyone agrees to everything or says nothing and just goes along with the group. Very little change or innovation or risk taking happen with regards to process improvement.This is a tricky space as you don’t want to encourage fighting or conflict for the sake of conflict. Rather you want to encourage excited conversations, with the emphasis being on what’s best for the team and having no hurt feelings along the way. Phew! Easy said than done! We have had luck in this by playing collaborative games with teams. In these board games you either win or lose as a team. If one person dies – you all die. This results in each person’s turn being a discussion/argument of what they should or shouldn’t do. As it’s *just* a game, most of these discussion are not taken personally and are a great model for healthy conflict, and learning how to make decisions together as a team. It helps if someone who has played the game before just facilitates the game so that the rules are clear, as they can be complicated. You can tell a lot from watching a team play, so this is great for Scrum Masters to facilitate and observe. Here are some things to notice:
- who is scared to take a chance?
- who dominates decisions?
- who argues and gives up?
- who is risk taker vs risk adverse?
- who thinks ahead?
- who is engaged?
- who wants to save the day and be the hero?
- who dictates solutions?
- what happens when there are conflicting ideas?
- are all peoples turns discussed or only some?
- who moves the pieces?
- what happens when you are in trouble and about to die?
Recently we were asked to teach a group of agile coaches about coaching teams using Kanban. We decided to teach them the principles and then use some example boards for them to discuss what they notice. These turned out to be a great way of teaching the principles so we thought we would share them.
Are you ready to put your Kanban knowledge to the test? Pretend that you are walking through an organisation and you pause and see the boards below. Think about what you see, what you think might be happening and what questions you could ask to either clarify your assumptions or get the team thinking.
Example 1: What do you notice in the board below?
Example 2: What do you notice in the board below?
Example 3: What do you notice in the board below?
Example 4: What do you notice in the board below?
Example 5: What do you notice in the board below?
1: There are no WIP (work in progress) limits on the board. The in progress column should have a limit on the number of items in it.
2: There is no PULL enabled. The in progress column should be split into busy, and ready for review. So that the review column can PULL work when the current work is finished, rather than having work pushed into the column.
3: The WIP limit on the Create column has been exceeded. The limit of 4 applies across both the in progress and done column.
4. The is a bottleneck in Test. You can see this because most of the columns upstream are waiting for work from test to flow. The team should all be working on alleviating the bottleneck.
5. This was a bit of a tricky one. Although there are two column in each step, this still doesn’t enable PULL, because the WIP limit is over the wrong columns. Once something from design is finished, it moves to the Review pending column, and potentially breaks the review WIP limit. You can’t stop something from being finished, you can only delay starting something. So the WIP limit needs to be combined over the Design WIP and Review Pending Columns.
Did you notice more? What questions could you ask these teams? (leave your questions in the comments below!)
The book follows the journey of a company called Growing Gardens, as they embark on a project to write a gardening book using Kanban. You will see how their board evolves as they embrace the principles of Kanban, and encounter problems along the way.
You can download a free sample of the book here: https://leanpub.com/kanbanworkbook
We were recently featured on Agile TD Mondays talking about Distributed Teams.
Watch the video here:
We were excited to get our hands on a copy of Geoff Watts’ latest book: Product Mastery. We loved how his previous book, Scrum Mastery, included stories of real Scrum Masters and some of the challenges they face.
Geoff’s new book for Product Owners similarly looks at important characteristics of Great Product Owners: Decisive, Ruthless, Informed, Versatile, Empowering and Negotiable. Each chapter starts with a story of a challenge a Product Owner faced. Geoff then goes on to discuss what a product owner could do in a similar situation. He includes loads of references to other books and articles, as well as many great tools. Each chapter goes in depth to cover many different options and solutions as well as all the things that might go wrong.
Two pages in, I already wanted to send a copy to some of the Product Owners I know who struggle with these exact things. I think this would be a great resource for many people who find themselves themselves in the Product Owner role, without any clear idea of what they need to do and especially how they might achieve that. If you are feeling overwhelmed as a Product Owner, don’t despair. Geoff’s book is now available on kindle, so you could download it today, and have many of options for what you could do in your situation.