Posts Tagged ‘techniques’

noganttMy team were struggling to make their sprint commitments. Sprint after sprint, we’d go into planning, pick the stories that we believed we could finish in the sprint, and get to the end with things not where we wanted them to be. To make matters worse, stories were piling up towards the end of the sprint, leaving testing (and feedback) right to the end. Our best intentions were just not translating into a workable plan and it was hard to see why. And then someone suggested that we try visualise our plan in Sprint Planning 2 (SP02): would it help if we created a Gantt?

My gut reaction (as their Scrum Master) was pretty strong. I had flashbacks to my Project Administration and Project Manager days where my life was ruled by Microsoft Project Plans and unrealistic resource-leveling. I recalled long arguments about how, just because you could get a document through our intensive quality checks in two days, usually, it took about a week, plus you needed some days to rugby-tackle your busy stakeholder into signing it once it was ready. All this meant that your team was (in Gantt terms) “not working” for the duration of the document review task – which was unacceptable when everyone needed to be at a consistent 75% utilisation for the project. Then there were the status reports and percentage complete updates (how do you know you’re 50% complete if you’re not done yet?) and lines that jumped and moved (or didn’t) when your dependencies were mapped incorrectly.

All of the above happened in my head, of course, and we agreed to give the Gantt chart a try during SP02. Thankfully, besides knowing how to draw a basic frame, all my historic experience with Gantt charts meant I also knew which questions the team would need to answer to complete one – plus the mistakes people usually make when creating a visualisation of duration.

Before I share with you what we did, I think I’d better let you know how things turned out. The first few times we did it, people really struggled and it took a while to create the chart. However, with practice, it became just one more SP02 activity, and eventually, I didn’t need to help the team at all.

The visualisation helped us highlight where we were overcommitting ourselves (expecting one person to work on too many things at the same time; forgetting when a team member was on leave at a crucial point; or not finding ways to do some testing earlier). In making our poor planning assumptions visible, it helped the team figure out workarounds before the sprint even started e.g. for very long stories, they’d identify smaller milestones for feedback. Or where they realised that the type of work was very heavily weighted towards a particular skillset, they identified simpler pieces where less experienced team members could pair up and work together saving our “big hitters” for the more complicated stories. We also got better at accommodating sprint interruptions (like public holidays or whole-team-training) and adjusting our sprint forecast accordingly. Lastly, we started taking our Gantt into daily stand-up, and the team would adjust their Gantt plan at the end of stand-up which was a great way to see if we were on track and, where we weren’t, what needed to change.

How did we do it?

This is how we used the Gantt chart. Firstly, after SP01, I would create an empty framework for the 10 days of the sprint. I’d add any known “events” that would impact us, for example:

  • Our sprint ceremonies were on there
  • Any planned grooming slots were indicated
  • Planned leave/training was reflected- with the box size representing whether it was a half-day or full-day
  • Other significant “distractions” were added, like floor release dates
  • Any other planned meetings we were aware of after Sprint Planning 1 (SP01) were added
  • Weekends and any public holidays were blocked out
  • We also made the sprint goal visible on the last day (Review box)

The team would then work down their list of Backlog Items agreed in SP01. After discussing the item and the tasks for the work involved, they would then plot its expected start and finish date on the Gantt. As this was duration-based, in the beginning, I sometimes needed to remind them to add an extra day where a task ran over a public holiday or the person(s) the team assumed would be picking up the task (based on what was going on/availability) was going to be out of office. As they generally had an idea of who might be doing what, durations were also adjusted based on the person doing the work e.g. they would sometimes add extra time if the person was working in a space they were less familiar with. Even without thinking about who would be working on a specific task, the Gantt made it very clear when they were expecting to start more stories on the same day than there were people available to work on them. As previously mentioned, where stories looked to have a longer than usual duration, the team also brain-stormed mini-milestones where testing/checking could happen (e.g. if it was a five-day task, they’d try have something that could be tested/checked every 1-2 days). I added the tasks to the Gantt chart the first few sessions we used it, and once they’d got used to the idea, then a team member started doing it.

Finally, if the Gantt showed we’d been mistaken about our forecast in SP01, it meant we were able to communicate changes to the forecast before the sprint even started.

ganttall


This team had a specific problem to solve. As it turned out, the Gantt chart helped them create a shared view of their sprint plan which could be used to help them test their thinking/approach. It had a bit of a learning curve and took time and energy to create though, so I’d still caution against “just using it” for the sake of it. However, I’m also now likely to suggest a team tries it if they are experiencing similar planning problems to this team.

Have you ever used a Gantt chart for sprint planning? What did your team learn? Or have you been surprised by some other tool that you’d previously had bad experiences with? What was it and what did you learn?

 

 

My team had been working together for three sprints. During this time we’d been grooming and delivering stories (into Prod) but we had not done any sizing. Our Product Owner and business stakeholders were getting twitchy (“how long will we take?” – see How big is it?) and it was time to use our data to create some baselines for us to use going forward (and, as a side benefit, to find out what our velocity was).

Besides the fact that it was a new team, this team was also very large (15 people), some of them had never done an Affinity Sizing type exercise before, and we were 100% distributed (thanks to COVID19). Quite the facilitation challenge compared to the usual exercise requiring nothing more than a couple of index cards, masking tape and some planning poker cards. This is what I did and how it worked out.

1. Preparation

First, I needed something I could use to mimic the laying out of cards in a single view. As we’d already done three sprints of stories, there were a number of cards to distribute and I didn’t want to be limited to an A4 Word document page or Powerpoint slide. This meant a whiteboard (unlimited space) was required and we eventually ended up using a free version of  Miro.

Second, with my tool selected, I needed to make sure everyone in the team could actually access/use the tool. Unfortunately, Miro does require one to create an account, so prior to the workshop I sent a request to everyone on the team to try and access an “icebreaker” board.

Third, I needed to prepare my two boards:

  • The Icebreaker board which was to serve three purposes:
    1. Give people something to play around with so they could practise dragging and interacting with Miro
    2. Set the scene in terms of how sizing is different to estimating. Hopefully as a reminder to those who already knew, or as an eye-opener to those who might not.
    3. Use a similar format/process to the board I would be using for the Affinity Estimation exercise so that the team could get used to the process in a “safe” context before doing the “real thing”.
  • The Affinity Estimation board and related facilitation resources.

The Icebreaker Board

Ball game start

This layout matched the starting point of the Affinity Estimation exercise.

There was a reminder of what “size” was for the purposes of the exercise in red (1) and instructions for how to add the items to the scale (2). The block on the left was for the “stories” (balls) that needed to be arranged on the scale.

The Affinity Sizing Board

(I forgot to take a screenshot of the blank version, so this is a “simulation” of what it looked like.)

same blank stories

“Simulation”

For the Affinity Sizing, besides the board, I also prepared a few more things:

  1. A list of the stories (from JIRA) including their JIRA number and story title in a format that would be easy to copy and paste.
  2. The description of each story (from JIRA) prefixed with the JIRA number in a format that was easy to copy and paste
  3. I asked one of the team members if they would be prepared to track the exercise and ensure we didn’t accidentally skip a story.

A reminder that at the point when we did this exercise, we were about to end our third sprint, so we used all the stories from our first three sprints for the workshop (even the ones still in progress).

2. The session

The session was done in Zoom and started with the usual introduction: what was the purpose and desired outcomes.

From there, I asked the team members to access the “icebreaker board”. In the end, I had to leave the team to figure out how to use this board for themselves while I dealt with some technical issues certain team members were experiencing, so couldn’t observe what happened. However, when I was able to get back to them, I was happy enough with the final outcome to move on.

balls 2

Round 1: Small to Large

To kick things off, I copied and pasted the first story from my prepared list (random order) into a sticky and the story description (in case people needed more detail) into a separate “reference” block on the edge of the whiteboard. The first person to go then had to drag the story to where they thought it best fit on the scale.

From the second person onwards, we went down the list and asked each person whether they:

  1. Wanted to move any of the story-stickies that had already been placed or,
  2. Wanted a new story to add to the scale

A note here – it might be tempting to have some team members observe rather than participate (e.g. your designer or a brand new team member); however, I find that because mistakes will self-correct, there is more benefit in including everyone in the process.

We repeated the process until all the stories had been placed on the scale. At this point, it looked something like this (again, a “simulation”):

round 1 Round 2: Buckets

At this point I used two data points to make an educated “guess” to create a reference point.

  1. I knew that our biggest story to date was of a size that we could probably fit 2-3 of them in a sprint
  2. I could see where the stories had “bunched” on the scale.

So I picked the first biggest bunch and created a bucket for them which I numbered “5”. Then I drew buckets to the left (1,2,3) and to the right (8,13,20) and moved everything that wasn’t in the “5” bucket down to below the updated scale/grid (but still in the same order left-to-right).

buckets

Before we continued, I checked with the team whether the felt all the stories in the 5-bucket were actually about the same size. They did (but if there had been one that they felt might not be, it would have been moved out to join the others below the buckets). After this point, the stickies that had been placed in bucket five at the start of the process were fixed/locked i.e. they could not move.

Then we repeated the process again where each person was asked whether they

  1. Wanted to move a story-sticky that had already been placed into a bucket, or
  2. Move one of the unplaced story-stickies into a bucket

Initially, some people moved a couple of stories on their turn into buckets, which I didn’t object to as long as they were moving them all into the same bucket. Again, I was confident that the team would self-correct any really off assumptions.

We had one story that moved back-and-forth between bucket 1 and 2 a few times, and eventually, the team had a more detailed discussion and made a call and that story wasn’t allowed to move again (I also flagged it as a bad baseline and didn’t include it in future sizing conversations).

Once all the story-stickies had been placed in a bucket, everyone had one last turn to either approve the board or move something. When we got through a round of everyone with no moves, the exercise was done:

stories

The actual outcome of the workshop

Even with technical difficulties and approximately 15 people in the room, we got all of this done in 90 minutes. This is still longer than it would usually take face-to-face (I’d have expected to have needed half the time for a collocated session), but I thought it was pretty good going. And the feedback from the participants was also generally positive 🙂

These stories (except for the one I mentioned) then became baseline stories for comparing to when we did future backlog refinement. Also, because I now knew the total number of points the team had completed in the three sprints (sum of all the stories), we also now knew what our initial velocity was.

Have you ever tried to use Affinity Estimation to determine baselines? Have you tried to do so with a distributed team? What tools did you use? How did it go?

 

Image result for yes but improv gameRecently my team played a loose version of the “Yes, But” improv game at the beginning of a retrospective (retro) as an icebreaker. I say loose, because we played it in a round (rather than in pairs) and did two rounds. I started each round with the same statement: “I think we should have snacks at Retro” (this is something that often comes up – tongue-in-cheek – during retro conversations).

For round one, the next person in line always had to respond starting with “Yes, but”. At the end of the round (we were seated in a circle), I asked the group to silently pay attention to how they felt and what they experienced during the exercise.

For round two, the next person in line had to respond starting with “Yes, and…”. At the end of the second round I asked some questions about how the team experienced both rounds:

  • How did the first round feel?
  • How did the second round feel?
  • What made a round difficult?
  • What did or could you do to make a round easier?
  • What does this mean for how we respond to each other as a team?

Interestingly (and unexpectedly), my team struggled more with the “Yes, and” round than the “Yes, but” round. To the extent that one team member couldn’t even think of something to say for the “Yes, and” round! At first I was a little stumped, but as we discussed further we realised that:

  1. As a team, we found it more natural to poke holes in ideas rather than add to ideas we didn’t completely agree with.
  2. When we didn’t agree completely with a statement, we got “stuck” and couldn’t think (easily) of a way to add to the statement.

As an example for point 2, above, one person responded to the statement with: “Yes, and we will need to do exercise”. The person following them really struggled to respond (because they don’t like exercise) and didn’t really come up with anything convincing. As a group, after some thought, we eventually realised that “Yes, and it can be optional” would have been a perfectly valid response. However, as a group, it took us a while to get there. So it definitely wasn’t something that came naturally to us.

For me, these were quite cool insights, and probably good for a team to be aware of, particularly when we’re struggling with new problems or trying to find creative solutions.

Have you tried similar games? What did you learn or experience? How has it helped your team?

6hatsThis is my take on using “Six Thinking Hats” to reflect on a period of time. You could use a light version for a retro – or the full version to review something longer like the stage of a project or a release. It’s usually most effective after some milestone event and where the learnings can be applied going forward. There is still value in doing it at the end of a project, but what you get out of it for future teams may not be as valuable as you won’t always know what will be applicable.

Preparation

In order to save time in the session, you do need to do a fair bit of preparation. Try and collect as many facts about the time period as you possibly can before the session. Facts are anything backed by data and some common “facts” one might include are:
– Team changes (people joining/leaving)
– Events (e.g. release dates)
– Sprint information (velocity; commitment; actuals; sprint goal; etc.)
– Changes in process
– Special workshops or meetings
– Any data provided by metrics

I’ve found the most effective way to use the facts in the session (and the rest of my post assumes you have done this) is to map them onto a really large timeline. I typically use a sequence of flip chart pages that can be laid out so that attendees can literally “walk the line”. I’ve stuck them up on long walls or laid them out on a row of tables and even used the floor where I needed to.

It is also useful (for the reflectors in the team) to send out a description of the hats in advance and ask them to think about each one before the session.

Before you start your workshop, you have to set up the room (also see the tips at the end of this post):

  1. Lay out your timeline
  2. Ensure there is space for people to easily walk along it
  3. Have various stationary points along the timeline with pens and stickies
  4. Don’t forget to have a whiteboard or some other space for grouping the ideas

Materials

Besides your “timeline” of Facts, you will also need:

  • Small pieces of paper that people can write appreciations on
  • Pens
  • Stickies: one colour per hat
  • *Optional* Snacks

For the different hats, I usually use the following colours

  • Facts: N/A (people write directly on the timeline)
  • Instincts: Red
  • Discernment: Blue
  • Positives: Yellow
  • Ideas: Green

Process

The process I follow is largely based on this one and, as they mention, I have found that the order is fairly important.

For an average team, I time-box each section to about 10 minutes. Breaks need to be at least 5 minutes, but could vary depending on the time of the day (e.g. you may need a lunch break). If you are going to use the data in the session to come up with actions and improvements, then your time-box for that part will depend on what technique you plan on using. Obviously these may need to be adjusted based on the size of the group, but as most of the steps are self-paced, one advantage of this workshop is that it works quite well with larger groups.

Round 1: Facts

Have the attendees “walk the line” from the beginning to the end. This is a walk down memory lane and also a chance to fill in any blanks and ensure everyone agrees that the facts are correct. There are no stickies for this step – if people want to add or change anything they do that by writing directly onto the timeline (at the right point in time, of course). Remember to remind everyone that they should only be adding facts.

Round 2: Instincts

“Gut Feel”

Hand out your “instinct” stickies. Remind every one of the definition of an “instinct”. I sometimes skip this round because people struggle to differentiate between “instincts” and “positives/negatives”.

Appreciations and Break

Give everyone a chance to write appreciations (these will be shared later – either at the end of the session or afterwards). It’s also a good point to have a short break.

Round 3: Discernment

“Devil’s Advocate”

Make sure you’ve collected the “instinct” stickies and that the next colour of stickies is available. Remind everyone what the definition of “discernment” is. Everyone repeats their walk of the timeline, this time adding stickies to the timeline for things that didn’t go well or were disappointments.

Cool off

Have another break (in case things got emotional). Have people write more appreciations.

Round 4: Positives

“Keep doing this”

This is the last walk of the timeline. Again, remind people of the definition of “positives” and ensure there are only “positive” stickies lying around for people to use. They walk the timeline one final time and add stickies for things that went well.

Lastly: Ideas

“If I did it again”

There are various ways to capture and categorise ideas. The intention of this round is that attendees use the timeline to stimulate their thinking of how they could have done things better. Or how they would do things differently if they had to do it again. This is  sometimes also described as “green fields” thinking.

And then (now or later)…

If you were using this technique for a retrospective, you would ideally get actions from the information as part of your session. If the session was to reflect on a project, perhaps the data would be grouped into things like “Good ways to kick off” and shared with other teams. I’m quite a fan of the quadrant method of grouping similar stickies to find topics to address (see photos below for examples from a retrospective I did). What you do next all depends on the ultimate purpose of your session.

quadrants

Tips

  • Only let the attendees have access to the writing materials relevant for the round i.e. gather up the stickies from the previous round and “change colours” for the next round.
  • Have a number of “stationary points” – so that people can grab stickies and pens as soon as they have a thought.
  • Related to the above, have an excess of stationary and pens so people don’t have to wait for each other.
  • When preparing your timeline, try use pictures/symbols/colours to create visual patterns and cues for repeat facts e.g. document your sprint information in the same colour and layout for every sprint on the timeline or have a bug symbol where you have added statistics around bugs.
  • Don’t forget to share the appreciations! Especially if you’ve decided not to do so in the session.

I have applied this technique a couple of times and used the output for various things:

  1. We’ve used it to gather data for a team which was unfortunately not very transparent and then used that data to paint a “real picture” for external stakeholders.
  2. We’ve used it in retrospectives to identify improvements to team / process / products.
  3. We’ve used it at the end of a project to create guidelines and lessons learned for future projects and teams.

timeline

Have you used this technique before? What worked or did not work for you? Where might this approach be useful?

AAEAAQAAAAAAAAPSAAAAJGQ2MTIzYzU1LWM0MjItNDJjZS1iYWM2LWYxZDVmNzJmY2M4ZQ.jpgI may have mentioned it before, but at the beginning of the year I went on wonderful facilitation training which led to some positive work-related changes plus a long list of ideas and possible actions for me to try. Some I haven’t got round to (yet) while others I have been actively working on. Here are some of my thoughts on the latter.

(Side note: the format is the format we were asked to use when making our list – and I quite like it.)

I will use question agendas and review these before and during the session so that there is buy-in and we’re talking about what the group feels we need to talk about

I have been using questions agendas quite actively and have found one additional benefit is that they help formalise my own thinking around outcomes and flows for the sessions, particularly workshops.

One thing I have learned is – when running through the agenda – particularly for longer workshops – don’t just read down the list. Try and tie the parts together (like a story) so that the room gets a sense of the journey we’re taking. Also keep an eye out for nodding heads (a good sign).

So far…

  • I’ve had one session where the team members actually kept each other on track with each step by referring back to where we were in the agenda (I tend to pair the agenda with a task board to show when we’re busy with a topic or done).
  • In another session, the group went off on a technical tangent, and then brought themselves back to review whether they were actually answering the questions they were meant to.
  • In a third session, the group actually added an item to the agenda (admittedly, the item was “we find out what the cake tastes like” 😉 )

I will spend more time thinking about WIIFM so that I can try create excitement for a session

(WIIFM = What’s In It For Me)

I could probably focus a little more on this one, particularly using the information to help make sessions more exciting. Since the training, I’ve tried to be more explicit about ensuring I understand all aspects of a meeting (Purpose, Outcomes & Deliverables, WIIFM, and Roles and Responsibilities), particularly when the session is for someone else. We do tend to spend more time on the Purpose and Outcomes & Deliverables. I could probably still do more here…

I will assume yes and ask the follow-up questions so that the team is involved in the conversation and it’s not all about me

I’ve found this technique so useful that I wrote a blog post about it.

I will be more aware of where I am standing so that I leverage physical location as a chicken

I’ve tried this with mixed feelings about its success with my one team during stand-up (the idea being that if you don’t have work on the board, you stand OUTSIDE the inner circle). It’s been more interesting on the other team because soon after I joined they started doing distributed/remote stand-ups, so physical location is not something one can really experiment with. It certainly is very powerful, and I’m currently part of a coaching program where I’m trying to increase my awareness of how I use my body to communicate, particularly when stressed, so perhaps there’s still something to be explored with this one.


In total, I had about twelve ideas on my list that I wanted to try. As you can see, I’ve only really worked with a couple so far. Probably time to try one or two more and see what I learn 🙂

What have you tried recently to try improve how you facilitate sessions or interact with your teams? How did it go?

top-30-open-ended-questions-570x375I’ve always been aware that open-ended questions are good. They allow someone to answer from their perspective and context rather than being constrained to the limitations imposed by your yes/no options. They also allow someone to challenge an assumption or idea (“How do I look in this dress?”) in a way that is potentially less confrontational (“Does this dress make me look fat?”).

All that said, even after some training in “better questions”, I often find myself regressing back to the good old yes/no in conversations – usually without even being aware of it. That is, until I went on some awesome Agile Facilitation training recently where we learnt a really useful trick:
1. Assume the answer to your question is “yes” (Do we have anything to share with the other teams?)
2. Ask the follow-up question (What will we be sharing with the other teams?)

Ta-da: easy peasy open-ended question! And, if you’re worried about the fact that the answer to your yes/no question may actually be no, if you think about it “no one” or “nothing” are both valid responses to an open-ended question.

I still ask yes/no questions. I am trying very hard not to (especially when facilitating). This trick seems to have helped me become better at self-correcting and gives me an easy way to figure what I can ask instead.

This trick has helped me immensely. Give it a try. Let me know what you discover.

#SGZA 2016: “Just Right”

Posted: November 17, 2016 in Agile, Team
Tags: , , , ,

I recently attended the regional Scrum Gathering for 2016 in Cape Town. This is a post in a series on the talks that I attended. All posts are based on the sketch-notes that I took in the sessions. 

Danie Roux gave an entertaining opening keynote which started off with a re-telling of the well-known fairy tale: Goldilocks and the Three Bears. We also touched on the adventures of Cinderella (and her glass slipper) and the Hunchback of Notre Dame during the talk. Danie challenged us to consider the modern versions of the fairy tales (Shu) against the logic they contained (Ha – or huh?) and their actual origins in history (Ri). Besides some fascinating facts about the origins of some fairy tales, other take-outs from his talk were:

  1. Perspective matters.
  2. Roles are meaningless on their own – they need to be considered in the context of a relationship.
  3. A cadence is a pause. Pauses between notes create music.
  4. The three hardest things to get a team to do are: (1) Talk (2) Talk to each other; and (3) Talk to each other about work.
  5. The definition of ScrumBut: (ScrumBut)(Reason)(Workaround)
    1. Translation: When we say Scrum But we usually go “this is what Scrum would recommend”, “but this is why it won’t work for us”, “so this is what we’ll do instead”
    2. Perhaps we should try for Scrum And?

Finally, he told us the story of his friend and the glass Sable antelope… As a reminder that when we give someone a gift, we cannot be upset with what they do with it (even if they destroy it), regardless of what we invested in getting it for them.

Some references from the talk:

Anything in there that you found interesting?

This is a post in a series on the talks that I attended at my first ever Agile Africa Conference in Johannesburg. All posts are based on the sketch-notes that I took in the sessions. 

Some of the slots were really short, which meant speakers couldn’t really go into a lot of detail. These are sketch-notes from some of the shorter talks.

Popcorn Flow

agileafrica.JPG  popcornflow

Find out more: https://popcornflow.com/

 

 

Leader Transformation

agileafrica

The full title of this case study was “Leader Transformation – a side effect of an agile transition”.

Key take-outs for me:

  • Different parties have different motives and often change driven from the top is feared or regarded as a ‘fad’ to ‘survive’.
  • Beware early successes- sometimes they create a false sense of confidence which leads to running before one can properly walk
  • Start from where you are

Mob Programming Case Study

mob

An interesting talk on the before and after effects of having a team practice mob programming. Some of my key take-outs for if you want to try it:

  • Start by following the rules and then inspect and adapt.
  • There are some things where mob programming doesn’t work very well, e.g. doing research, where learning is not an outcome of the work, and problems that are still very large.
  • You need to mob program with a cross-functional team with all the perspectives (problem knowledge, testing expertise, developers, UX, etc.).
  • You also need to create time for team members to do things on their own i.e. not all of their day is spent with the ‘mob’. This “alone time” could be spent on things that aren’t suited to mob programming and/or other creative initiatives.

 

This is a post in a series on the talks that I attended at my first ever Agile Africa Conference in Johannesburg. All posts are based on the sketch-notes that I took in the sessions. 

I’m not sure if you recall our first experiment with self-selection? Imagine my surprise when I realised that our keynote speaker on the topic, Sandy Mamoli, was the very same person who had been part of the team that created the material we’d used for our own self-selection attempts. As we’d also run a second less successful experiment, I was quite interested to hear a little more “from the horse’s mouth”, so to speak.

agileafrica.JPG

There were some key points shared by Sandy that helped me understand a little more why our second attempt had not succeeded from an expected outcome perspective, but had, in fact, succeeded from a feedback perspective.

  1. Purpose is important. Squads form around a strong purpose that they can buy into.
  2. Self-selection will always fail if management selection is going to be done afterwards to ‘tweak’ the outcomes. (Her solution: make the blueprints for the new squads very visible everywhere as soon as possible after the session.)
  3. She shared a story where squads would not form around a particular vision or goal and usually where that happened there were deeper issues at the root which needed to be resolved before a team would be successful.
  4. Self-selection should NOT directly or explicitly impact reporting lines.

So, upon reflection, after comparing our first and second experiment and adding in some of the tips from Sandy, these were my conclusions:

  • Self-selection should happen independently of reporting lines
    • The first time we did it, there was no impact on reporting lines; the second time we did it, reporting lines were impacted by which squad you moved into.
  • Try keep “people owners” as observers not players
    • There was a subtle form of “Liar Liar” in our second attempt as every time there was a significant shift in numbers to one or other ‘cost center’ then the managers (who were also the Product Owners) had a quick chat about how to re-balance things. In our first experiment, everyone remained in the same “cost center”.
  • Ensure the Product Owners are well prepared in terms of their vision
    • The second time we ran self-selection, one Product Owner had a very clear and mature view of what the squad would be achieving; whereas the other Product Owner was new to the space and hadn’t really had time to formulate their thinking and strategy properly.

Sandy also advised the following:

  • Where squads have fully formed after a couple of rounds, move forward with those squads (regardless of the state of the others).
  • Where squads aren’t fully formed because there just aren’t enough people, have the squad members identify what ‘imaginary friends’ they need to ‘hire’ to form a full squad.
  • Where squads haven’t formed for less obvious reasons and/or people refuse to participate in the process (and choose no-squad), revert to traditional management selection for those people and root cause the reasons for the resistance.

This keynote was very valuable to me as it shifted my perspective of our second attempt from being a failure to being a great source of useful feedback about the state of a particular space. Have you tried self-selection? What was the outcome? What did you learn?

 

This is a post in a series on the talks that I attended at my first ever Agile Africa Conference in Johannesburg. All posts are based on the sketch-notes that I took in the sessions. 

agileafricaSam and Karen started by clarifying what they meant by distributed teams: teams that don’t sit in the same location. They then categorised distributed teams into three main categories:

  1. Teams that work in the same time zone and/or the majority of their working/office hours overlap
  2. Teams that work in different time zones but there is some overlap of working/office hours
  3. Teams that work in different time zones or have different shifts so that there is no overlap of working/office hours.

For each, they then shared some common characteristics and where best to focus energy.

Full Overlap

These teams are characterised by synchronous communication. Here the best focus would be on technology and tools to ensure that communication is as easy as possible when people are distributed. They suggested some ideas like a video wall (expensive option) or running Skype continuously in the background (cheap option) to allow synchronous communication and cues to happen as naturally as possible.

Partial Overlap

Communication in these teams is largely asynchronous (e.g. email), so time together is valuable. Rather than use this time for things that can be communicated is an asynchronous manner, focus on using team time to create understanding. A practical example in the Scrum world is rather than use overlapping time for something like a stand-up (which can also be done via an update in most cases), use it for things like Grooming and Planning where more complicated conversations are required to flesh out understanding and work through difficult problems.

No Overlap

Their main ideas here related to being creative with

  • Tools e.g. creating a video for reviews and stand-up that can be distributed to the other team(s)
  • Rotating a team member who “takes one for the team” and changes their office hours so that there is some overlap with the other team(s).
  • Planning work to try to keep work where there are dependencies in teams that are working in similar time zones.

Besides the advice above, they also had the following general tips:

  • Use Good Technology
  • Have and Use Working Agreements
    • “Bottom Line” – a phrase used when people start to waffle and need to get to the point
    • Talking Over – agreement on what happens if people talk over each other. One idea is to give the facilitator permission to provide the order of who speaks in what order.
    • Multiple back-up plans – So if (when) the technology fails, everyone automatically knows which one to try next (and it doesn’t need to be discussed)
    • Silence – Silence is OK
  • Good Voice Trumps Bad Video
  • Same Experience for All
    • If one person needs to dial in, then everyone should dial in
  • Prepare
    • Prepare for sessions more than you would for face-to-face: agendas, tools, pre-reading, etc.

You can find more tips at RemoteAgileCoach.com.

I’ve shared some of my thoughts on distributed teams in a previous post. What have your experiences been with working on a Distributed Team?