Skip to content

Growing Agile
Syndicate content
Coaching agile coaches
Updated: 12 hours 21 min ago

Simple Visual Scrum Meeting Overview

Tue, 04/25/2017 - 10:00

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.


 

Categories: Companies

Remote Working – Recommended Books

Thu, 04/20/2017 - 15:05

More and more people want to work from home. Here are some books we’d recommend on the topic of working remotely:

Categories: Companies

Agile Testing Manifesto – More Translations

Wed, 04/19/2017 - 09:00

Our Agile Testing Manifesto has been translated by Victoria Slinyavchuk into both Ukrainian and Russian!

Here are the new images with the translations, feel free to use them and share them.

Ukrainian:

Russian: 

 

Categories: Companies

The remote backlog grooming / refinement session

Tue, 04/11/2017 - 16:04

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

Categories: Companies

The remote backlog grooming / refinement session

Tue, 04/11/2017 - 16:04
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 […]
Categories: Companies

Sketchnote: 10 Aha Moments from Working at Spotify

Tue, 04/04/2017 - 09:40

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.
 

 

 
 

Categories: Companies

Sketchnote: 10 Aha Moments from Working at Spotify

Tue, 04/04/2017 - 09:40
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.        
Categories: Companies

Guest Post: Lego Retrospective

Tue, 03/28/2017 - 10:11
This blog post is by Jay-Allen Morris, a Scrum Master in the local South African community. Thank-you so much for your awesome retrospective idea Jay-Allen!

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.

Tools needed:

  • 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

 
Technique

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

Categories: Companies

Guest Post: Lego Retrospective

Tue, 03/28/2017 - 10:11
Categories: Companies

An Introduction to Mob Programming

Tue, 03/28/2017 - 09:47

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

Categories: Companies

An Introduction to Mob Programming

Tue, 03/28/2017 - 09:47
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 […]
Categories: Companies

Encouraging healthy conflict

Wed, 03/22/2017 - 10:40

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?
We usually debrief what we notice during the game afterwards and then see if the team notices this in their daily interactions. This allows you to potentially spend time on specific things with teams. For example, teaching them how to suggest solutions vs tell people what to do. This particular technique – whilst helpful in the game, is also great for developers mentoring inexperienced developers to learn. In a few weeks time, play the game again and see how things have changed. Some examples of great collaboration games are: Forbidden Island and Forbidden Desert. These can take from 10 min to 45 min to play. Pandemic is also good – but the rules are much more complex and it might take longer to play.

 

Categories: Companies

Encouraging healthy conflict

Wed, 03/22/2017 - 10:40
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 […]
Categories: Companies

Assess Your Kanban Knowledge

Tue, 03/14/2017 - 10:40

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?

Some thoughts:

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

kanbanbookHow did you do?
If you’d like to improve your Kanban knowledge our workbook provides a step by step guide to help you learn about and implement the principles of Kanban with your team.

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

 

Categories: Companies

Assess Your Kanban Knowledge

Tue, 03/14/2017 - 10:40
Categories: Companies

Agile in Distributed Teams

Tue, 03/07/2017 - 10:00

We were recently featured on Agile TD Mondays talking about Distributed Teams.

Watch the video here:

Categories: Companies

Agile in Distributed Teams

Tue, 03/07/2017 - 10:00
We were recently featured on Agile TD Mondays talking about Distributed Teams. Watch the video here:
Categories: Companies

Book Review: Product Mastery

Fri, 03/03/2017 - 13:07

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.

 

 

Categories: Companies

Book Review: Product Mastery

Fri, 03/03/2017 - 13:07
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, […]
Categories: Companies