Posts Tagged ‘facilitation’

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.

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. 

This key-note was done by the famous Jim Benson and actually spilled over into subsequent impromptu session. Jim is a very entertaining speaker and doesn’t pull any punches when it comes to challenging the “accepted best practices” of Agile/Scrum/Kanban.

His talk started with some context: what do we mean by systems and what should we be optimising them for? His opinion: we want purposeful systems – systems that work towards achieving their purpose. Extending from that, we should be optimising systems to achieve that purpose – and nothing else. Processes can be defined as rules of conduct (for people) that optimise a system to achieve its purpose. If we consider processes as rules of conduct, then it makes sense that an imposed process (your process) would enslave me whereas an inherent/organic process (my process) would help me. Also, the inspect and adapt loop becomes the mechanism to continuously adjust our rules of conduct (process) based on the reality in which the system is operating.

Now, before one can optimise for purpose, one needs to understand what the purpose of the system is. Jim suggested some basic questions one should be able to answer:

  • Who is my customer?
  • What problems are we trying to solve?
  • How do we engage professionalism over professionals?
  • How do we work in small batches?

As mentioned, the key-note extended into another session and I don’t recall exactly where in the talk that happened, however at some point we started discussing how, in the past, we worked in social hierarchies (good old organisational charts) whereas now we tend to operate within social networks. One downside of social networks is that they have some communication challenges, particularly between networks. One tool Jim shared with us to help with this was an exercise to create a shared story for a team (who should be operating as a social network).

A shared story is created by the team and consists of four parts:

  1. The vision of the team: Why are we doing what we’re doing?
  2. Expectations of each other: What are my expectations of you? What are your expectations of me?
  3. Boundaries: When does someone need to talk to me about something that they are working on? When do I need to talk to someone else?
  4. Victory: How do we know when we have succeeded? What does victory look like?

The shared story should be regularly updated and revised by the team.

Some other cool snippets/ideas I picked up during the keynote and subsequent continuation:

  • Using a scary scale to help prioritise stories. Teams rank a story as being either a kitten; or a crocodile; or a zombie; or a zombie crocodile (in order of scariness). The idea is that you want to be tackling and learning from the scariest stories first so that you can hopefully make them less scary.
  • When having stakeholders rank work, give them only two options: Do (above the line) and Ignore (below the line).
  • If your team is struggling with poor quality or not-quite-done stories, then inspect and adapt as stories move to done. Ask the question: how do I feel about this finished task/stories? If the person doesn’t feel happy, then unpack what still needs to happen in order to feel happy or comfortable about the story/task. Over time, these things would probably evolve into a more team appropriate definition of done.

What are your thoughts on some of what Jim had to say and share?

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?

 

Dark Stories

Posted: August 19, 2016 in Team
Tags: , ,

darkstoriesI was following one of the Australian Agile conferences on Twitter recently and someone posted something about a talk on “Black Stories”. The click-trail eventually led me to this link and I decided that the card game sounded quite appealing (regardless of whether it would prove to be useful as a tool or not). A search for “Black Stories” for sale to South Africans almost ended in vain, but thankfully I decided to submit a query to http://www.timelessboardgames.co.za/ and they got back to me almost immediately to say that they had a set of “Dark Stories” in stock. A quick Google confirmed that this was the equivalent thing and, seeing as it was a Friday afternoon and I was in the mood for shopping, I ordered a box, which arrived the following week.

Since then, I’ve played a couple of games with my team. Our organisation has a horrid culture of people being late for meetings (generally five minutes; when I’m planning a session I always plan for at least 10 minutes) so having something for us to do while people dribbled in seemed a great idea. And, if it encouraged people to get there on time, even better! At first, people didn’t really figure out what was going on (I only play one card per session and we time-box it to 10 minutes, so sometimes people arrive after we’re done) but they’re slowly getting the hang of it and I have noticed that the percentage of on-time arrivals is increasing. I also like that it encourages some lateral thinking, which is also something we don’t practice very often in our day-to-day, so hopefully it will stimulate some more creative problem-solving too.

So far, I haven’t managed to take my box home yet to play it in my personal capacity, but that’s OK. A chance to make meetings more fun is far more valuable. If you’ve been struggling with this or getting people to rooms on time, I’d really give this a try. Do you have any other easy tricks or tools you’ve used in the past to set a good tone for a meeting or encourage other helpful behaviours?

We’ve all bbigcompanyeen there. Someone describes a problem that they want solved (and possibly suggests how they think you should solve it) and in the very next breath asks: “So, how long will it take?”.

Invariably, we get talked into providing some kind of gut feel indication (days/weeks/months/quarters) based on nothing much besides (perhaps) experience. But how often in software do you actually do a rinse-and-repeat of something you’ve done before? In my 10 plus years in IT, never. Never ever.

Unfortunately, we don’t yet work in a world where most people are happy with “we’ll be done when we’re done” so a vague timeline is always needed: if only for coordinating training or the launch email and party. So where does one start?

First, there are some principles/facts-of-life that are important to bear in mind:
1. The cone of uncertainty
2. Some practical examples of the developer cone of uncertainty
3. A good analogy of why our estimates always suck, no matter what data we’ve used

In the beginning….

For me, the first time you can possibly try get a feel for how long your horizon might be, is after you’ve shared the problem with the team and they have had a chance to bandy around some options for solutions. At this point, assuming your team has worked together before, you can try do some planning poker at an Epic level. Pick a “big thing” that the team recently worked on, allocate it a number (3 usually works) and then have the group size “this big thing” relative to the one they have previously completed. I prefer to use a completely random number (like 3) rather than the actual story points delivered for this exercise because otherwise the team might get tied up debating the actual points and not the gut feel relative size.

Now, if you have a known velocity and also know the points delivered for the big thing we already built, you should be able to calculate an approximate size for the new piece and use your velocity to find a date range with variance (don’t forget about that cone!). For example:
– If we agreed our “Bake a cake” epic was a 3
– And then sized the “Bake a wedding cake” epic as a 5
– And “Bake a cake” was about 150 points to deliver
– Then “Bake a wedding cake” is probably about 3/5*150 = 225 points to deliver
– Which means you’re probably in for 225/velocity sprints (with 50% variance)

At the very least, this should help you pin-point which year and perhaps even quarter this thing is likely to be delivered. (Don’t make any promises though – remember the cone!)

When we know more….

Now, if you’re doing things properly, your team will groom the big epic and slowly start agreeing on small to medium stories and perhaps even slices. Ideally you’ll have a story map. At some point, you should have a list of stories (or themes or whatever) that more-or-less cover the full solution that the team intends to build. At this point, it is possible to do some Affinity Estimation, which will give you another estimate of the total size (in points) relatively quickly that you can sanity check with the help of velocity against your previous guesstimate. If you’re working with a new team and haven’t got a velocity yet, this is also the time when you can try ‘guess’ your velocity by placing a couple of stories into two-week buckets based on whether the team feels that they can finish them or not. This article explains this process in a bit more detail.

Keep checking yourself…

You will probably find that when you do Affinity Estimation that you will still have some biggish stories in the list, which is OK. Over time as these break down, it’s probably a good idea to repeat the exercise (unless you’re so great at grooming that your entire backlog has already been sized using Planning Poker). Until you have sized everything in detail to ready stories, Affinity Estimation is the quickest way to determine a total remaining backlog size that is reasonably useful. Over time, if you maintain your burn-up, you’ll be able to track your progress and re-adjust plans as you go along.

Did you find this post useful? Have you used these techniques before? What other techniques have you used to try build a view of your release roadmap?

Hindsight is 20/20

Posted: December 2, 2015 in Team
Tags: , , ,

There has been a lot of change in my space in the past year. A lot of it hasn’t been managed very well (which creates a lot of ‘people noise’). I’ve been exposed to a number of change management models over the years, including ADKAR and this cool exercise. I quite liked this tool about Levers of Influence which one of our People Operations (a.k.a. HR) team members shared with us. Although I already knew we’d done very badly when it came to change management, when I reviewed the two biggest changes (moving to Feature Teams and reducing our release cycle to having a release window every month rather than a synchronised release every nine-ish weeks), the tool helped highlight examples of what we had done badly, which also meant we could see where we needed to focus our efforts from a recovery perspective.

Levers of Influence

Levers of Influence

This is my retrospective on the change relating to monthly releases and what we did, did not, and should have (probably) done.

1. A Compelling Story

The idea to move to monthly release cycles had been brewing in the senior heads for a while, however we were going through a major upgrade of one of our core systems (in a very waterfall fashion) which meant that anything unrelated to that was not really discussed (to avoid distractions). Our upgrade was remarkably smooth and successful (considering its size and time span) and about two weeks after we went live with it, senior management announced that the release cycle was changing. Not many people had seen this coming and the announcement was all of two sentences (and mixed in with the other left-field announcement of the move to vertical feature teams rather than systems-based domain teams). In hindsight, most people didn’t know what this shorter release cycle meant (or what was being asked of us). Nor was the reason why we were making this change well communicated (so, to most people, it didn’t really make sense).

In hindsight:

  1. The why for the change should have been better communicated. We want to be able to respond more quickly and move to a space where we can release when we’re ready.
  2. The impact should have been better understood. One of the spaces that has most felt the pain is our testers. With a lack of automation throughout our systems and the business IP sitting with a few, select people, the weight of the testing has fallen onto a few poor souls. Combined with this, our testing environments are horrible (unstable, not Production-like, and a pain to deploy to), so merely getting a testing environment that is in a state to test requires a lot of effort across the board.
  3. We should have explored the mechanics/reasons in more detail with smaller groups. For example, it was about 3-4 months before people began to grasp that just because one COULD release monthly, it didn’t mean that one had to. The release window was just that: a window to release stuff that was ready for Production. If you had to skip a release window because you weren’t ready, then that was OK. (A reminder here that our monthly release ‘trains’ are an interim/transition phase – we ultimately want to be able to release as often as we like.)

2. Reinforcement mechanisms

One of the motivating factors for senior management to shorten the release cycle from nine weeks to one month was that our structures, processes and systems for releasing were monolithic and, although the intention had always been to improve the process, it just wasn’t happening. In a way, they created the pain knowing full well that we didn’t have the infrastructure in place to support it, because they wanted to force teams to find ways to deal with that pain. So, in this case, there weren’t any reinforcement mechanisms at all. The closest thing we had was a team that was dedicated to automating deployments across the board that had worked together for about six weeks before the announcement.

In hindsight:

  1. There should have been greater acknowledgement of the fact that we didn’t have the support structures, etc. in place to support the change.
  2. We shouldn’t have done the release cycle and Feature Team change at the same time (as there weren’t structures, processes and systems in place to support that change either).
  3. We should have been more explicit about the support that would be provided to help people align structures, systems and processes to the change.

3. Skills required for change

Shortening the release cycle certainly created opportunities for people to change their behaviour (whether in a good or bad way). Unfortunately most of our teams didn’t have the skill sets to cope with the changes: we were lacking in automation – both testing and deployment – skills. Throwing in the Feature team change with its related ‘team member shuffle’ also meant that some teams were left without the necessary domain knowledge skills too.

In hindsight:

  1. We should have understood better what skills each team would need to benefit from the opportunities in the change.
  2. We should have understood the gaps.
  3. We should have identified and communicated how we would support teams in their new behaviours and in gaining new skill sets.

4. Role modeling

Most people heard the announcement and then went back to work and continued the way they had before. When the change became tangible, they tried to find ways to continue doing what they did before. (A common response in the beginning to “why are we doing this” would be “that’s the way we’ve always done it”.) The leaders who had decided to enforce the change were not involved operationally, so could not be role modelled. Considering the lack of skills and reinforcement mechanisms, role models were few and far between.
In hindsight:

  1. If we’d covered the other levers better, we would have had people better positioned to act as role models
  2. Perhaps we should have considered finding external coaches with experience in this kind of change to help teams role model
  3. Another option may have been to have had a pilot team initially that could later act as a role model for the rest of the teams

 

Have you ever had a successful change? If so, which levers did you manage well? Which ones did you miss?