Posts Tagged ‘lessons’

In my opinion, one way to make a team coach feel really useless, is distribute their team across multiple locations where it’s really hard to observe their interactions with one another. For me, a lot of my “obvious” work and channels disappeared when that happened and it’s taken me a while to find alternative ways to provide the insights and support that my team needs. I also had to take a step back and acknowledge that when working distributed, certain elements of effective co-located collaboration no longer matter or have negligible impact on team greatness, whereas new elements turn out to be important levers. The trick, it turns out, is to identify what exactly those are. And I suspect, as always, that they will be different for each team.

For example, the daily stand-up or Scrum. A time for the team to sync up and share what happened the day before so that they can plan and adjust for the day to come. An opportunity to celebrate achievements and adjust for disappointments. A good time to interact and build some team rapport. The standard method is everyone stands up (to help maintain focus and brevity) around a task board (for visibility) and speaks to what they achieved yesterday (speaking and moving their tasks to show progress and create psychological ownership) and what they hope to achieve today that will help the team achieve their sprint goal. The Scrum Master and Product Owner observe – and perhaps facilitate – and ask questions where blockers might be hiding in what the team has to say. And the outcome is everyone on the team walks away with a plan for how they will contribute to the team’s success today – and a commitment to each other that they will do their utmost to complete what they have agreed to do for the day.

There are some parallels when we are working distributed – the task board, for example. There are some practices that are just impractical – like standing up. And there are others that may detract more than they add (for example, in our case, it seems less confusing to have one “driver” for the session than to pass control during the stand-up). Sometimes the limitations are tool-related. Sometimes it’s just the nature of working as a distributed team.

So what changes have I tried when facilitating a distributed stand-up? So far, these ones seem to be working:

I try to watch all of the faces. We use Zoom and there is a setting where you can view all of the attendees on a single screen. Whenever we have a distributed meeting – not only stand-up – I spend most of my time and attention watching the faces of the attendees. It’s a good way to notice how people are responding to the session and give clues as to when people are tired (my team can’t do distributed for much longer than 45 minutes), or confused, or distracted, or are trying to ask a question.

I make a note of who has spoken or been “spoken for” in terms of the plan for the day. Basically I listen out for what each person or pair is doing today and at the end of the stand-up, I explicitly ask individuals to share where I haven’t managed to tick them off on my list of names. Note, this is less about everyone having a chance to speak, and more to ensure everyone has made visible to the team what they plan to do for the day. I’ve noticed it’s really hard for my team to keep track of this themselves in a distributed stand-up.

I try to notice if people are trying to say something and find ways to ensure that they get a chance to speak without speaking over the person who is currently speaking. Sometimes this may mean providing an order for people to speak in (you then you then you) if a group happens to accidentally speak over each other.

In my opinion, certain on-line tools (like a digital task board) may satisfy the superficial purpose of the physical tool (e.g. visible stories and tasks for the team to talk to), but not necessarily the deeper purpose (e.g. the psychological ownership that comes with writing and moving a physical sticky). So I’m continuously researching and experimenting with new ways to achieve these outcomes within the context of a distributed team.

For me, the following facilitation activities are still valuable when facilitating a distributed stand-up

When necessary, introducing the session to re-confirm the purpose and outcomes – especially if there are newer team members or things have started to go a little off-track

One thing I have noticed, is paying attention in a distributed session is REALLY exhausting. It is also very difficult to split your attention between people “watching” and understanding the content. In my case, I have decided to prioritise the former over the latter, which sometimes leads to other interesting side-effects. On the upside, I’ve become great at asking “stupid questions” 😉

What have your experiences been with distributed stand-ups? What were the challenges? What were the opportunities?

I am currently working with a distributed team and we use JIRA for our sprint task board. We use it in our daily scrum (I can’t call it a stand-up) via Zoom. Over time, I’ve noticed that there are some things that come “for free” with a physical board, but are hidden or not as obviously visible on a digital board (at least not in JIRA). We have found workarounds for some and not for others and, perhaps, depending on the team, not having some of this information “in your face” might be OK. However, I thought I’d make a list of things to look out for if you happen to be using a digital rather than physical board for your team. Also this blog is all about learning 🙂

Please note, I’m only basing my observations on JIRA for this blog post because that is what we use. I suspect that most digital task boards have similar issues.

1. Who’s doing what?

My teams in the past have used personalised avatars to indicate who’s doing what task(s) for the day. We found this had two related benefits:

You were naturally constrained to the number of avatars you happened to have available to you (although it was still fairly easy to take on more merely by initialing the sticky).

It was very easy to see at a glance where a task had too many people, or where one person seemed to have spread themselves to thin, or where someone hadn’t committed themselves to a task.

When asking the question, “what do you notice about our focus?”, it was easy for the team to notice where they may have over- or under-committed themselves for the day. Or to notice and confirm where they were swarming for the day.

In JIRA, only one person can be assigned to a task. It’s not visually obvious where multiple people are working on a task. Also, because we usually only expand the story we’re currently talking about – and usually our full sprint of stories doesn’t fit into the view if we expand all rows – it’s very hard for the team to see good and bad patterns in how they have allocated themselves to tasks for the day.

2. Where are we stuck?

One of the tools one can use on a physical board when it seems a team is taking a while to get things done, is to start dotting tasks. The idea is that a task gets dotted for every day that it has been in progress and not finished. As the task develops measles, it’s pretty obvious where someone may be blocked or may need help.

JIRA does have the concept of task-dotting, but it’s very hard to see (it’s a light gray) and unfortunately the dots don’t stick around. They disappear as soon as someone moves the task to the next column on the board (so, for example, a task that may have been in progress for two days will suddenly have no dots when it moves to the show me column).

When dots have measles, it’s easier for the team to notice where tasks are dragging on for days and do something about it. You don’t really want tasks that have started to take more than a day to finish.

3. How big is our story?

This is probably (hopefully?) a JIRA funny. When we’re viewing the active sprint and sprint board, the story points aren’t visible. Assuming you use story points, they can be useful in helping the team notice when a story is taking too long – a supplement to the burn-down (see below) and tasks with measles (point 2 above). We have a workaround in that we add the story points to the end of the story title. It would be cool not to have to do this.

4. What’s our progress?

JIRA generates a pretty cool burn-down. But it’s not visible on the sprint task-board (which is the view we use for our Scrum meeting). How you’re doing on your burn-down is quite an important piece of feedback for how to adjust your plan for the day. Our workaround is to publish it on Slack before we meet, but it would still be useful to have it visible for the conversation.

5. What’s our goal?

I love (good) sprint goals. I find they give the team something specific to aim for that still allows for creative ways to respond to minor changes that emerge during the sprint. Goals are also a really useful way to bring the team back to the bigger picture in terms of sprint progress: “Are we on track to achieve our goal?”; “What are you doing today to help the team achieve the goal?”. So we create an awesome team sprint goal and ideally we want to have it front-of-mind when planning our tasks for the day. On a physical board, this is easy: it can be as simple as printing your goal on a piece of paper and sticking it to the board (ideally in colour and with sparkles). On a digital board, one needs to get a little more creative. In our case, we write the goal as a story at the top of the sprint and try remember to refer to it before we start our daily conversation. It seems to be working, but it does blend into all the other sprint work.

6. There are other aggregate data questions that are harder to answer

As Jacques de Vos once said: “If you have to scroll, you can’t see the whole“.

With a physical board, the team can usually notice useful things when answering questions like:

What do you notice about our tasks in progress?

Where do we seem to have the most focus?

What do we notice on the board about stories not started?

What do we notice about the state of our overall sprint in terms of stories in progress and not started?

Usually a quick glance at how stickies (whether stories or tasks) are grouped in the various lanes of the task board can provide a lot of insight into how things are going – especially if the distribution pattern is looking different to what the team is used to and/or expects to see. With JIRA, this view isn’t easily available. Expanding all of the rows creates a very busy view which is also not guaranteed to fit without the need to scroll. Collapsing the rows hides the task distribution (which may hide other things) and also the story status is represented by a word rather than the story’s location relative to the board’s columns and other stories.

7. There’s usually a driver

The way we use JIRA, someone screen-shares the taskboard in our Zoom session and that person automatically becomes the ‘driver’. What I’ve noticed about this is:

People are less likely to interact with the board during stand-up: they’d rather ask the driver to make updates or create emergent tasks

Some people are scared to drive (probably a tool thing – either JIRA and/or Zoom), so never do

The driver can get distracted by the mechanics of having the right story expanded, or making changes in JIRA, or whatever – so are not always fully present in the conversation

If the driver ends up being someone in a “leadership” position (e.g. a senior developer, the Product Owner), then sometimes they subtly control the decisions the team makes in terms of what they plan to do for the day because they can move things or assign things before the team have finished their discussion

All of the above means that the negative aspects of “you do it, you own it” sometimes sneak in…

Write down in detail what information you really need the board to show so that it becomes your information radiator. Then lose all pre-conceived notions of how a board should look and how your tool sets up its boards. Based on the info you need: what could a board in your digital tool look like?

Try to represent the info you need in something other than your tool (i.e. JIRA) – maybe Google Draw or something. Once you have something that works, try implement that in your digital tool.

If the problem is too many things on the board, could your sprint/commitment be smaller to fit everything in one view?

Create a filter that filters out “old” done items and try to only work from the top story (limit work-in-progress).

Shift some of the information elsewhere e.g. Say pairs work on the story – they break down tasks in another place (Trello?) and feed back only relevant info to the greater team on the story which is in JIRA. Feedback to their mini team is much more granular and on another board/tool.

Do you use a digital board on your team? What challenges have you experienced? What did you try?

I’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.

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.

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.

Purpose is important. Squads form around a strong purpose that they can buy into.

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

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.

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?

My natural personality is more introverted. My natural reaction to conflict is avoidance where possible. These personal attributes often make some of what I, as an Agile Coach, need to do, quite challenging. This week there were two conversations that I knew I had to have. One was with my Product Owner around something he had done that had affected me negatively on an emotional level. The second was with a ‘difficult’ team member who was responding to me quite defensively in sessions and I needed to unpack the why. Neither of these were conversations I relished having (especially as I would need to raise the topic of discussion) and they caused me at least one sleepless night.

Thankfully, over the years, I have had training in various ways to open conversations like these and I often rely on this training to try to at least start the conversation off with the right language and framing (invariably the wheels do fall off as the conversation progresses). One of my favourite fall-backs is the “I think, I feel, I need” tool which, as artificial as it sounds and feels, seems to work really nicely – especially when you’re raising something where the impact on you is subjective (like an emotion). I also try to remember to focus on describing actions and behaviours rather than attributes and, finally, to try to start any question with “What”. As I mentioned, I try. I’m not always successful 🙂

Anyway, in both cases this week, I kicked off the session with much trepidation, introduced the elephant I wanted to discuss, and then mentally closed my eyes and waited for the fall-out, unsure of whether I had the courage to face whatever that fall-out was in a constructive way. Thankfully, for both, there was no real fall-out and I felt that we managed to have a constructive conversation without damaging any relationships. I ended the day feeling quite buoyant and really grateful that I had screwed my courage to the wall to have both conversations. Being brave usually pays off, you see, because often what we fear is only in our own heads.

What are the things that you fear in your role? What tools and techniques do you use to help you feel more brave?

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

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:

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.

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.

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:

There should have been greater acknowledgement of the fact that we didn’t have the support structures, etc. in place to support the change.

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

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:

We should have understood better what skills each team would need to benefit from the opportunities in the change.

We should have understood the gaps.

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:

If we’d covered the other levers better, we would have had people better positioned to act as role models

Perhaps we should have considered finding external coaches with experience in this kind of change to help teams role model

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?

I recently attended the regional Scrum Gathering for 2015 in Johannesburg. 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.

I was extremely interested in hearing Biase talk about the journey a large bank in South Africa has recently embarked on to realise the benefits of integrated DevOps. Sadly for me, as we have many of the same challenges, their journey is not yet complete so they haven’t yet answered all the questions! I guess no one will ever have the perfect answer, however some recommendations would have been helpful 🙂

Their journey began with a pilot to try to realise the benefits of a team owning the entire value stream and not having different hand-offs between delivery, release management, and support. Some of the benefits of doing this would include:

Improved quality

Increased knowledge sharing

Increased organisational effectiveness

Shorter time to market

The ability to deploy faster with fewer failures

Their pilot initially consisted of two teams:

A feature team (building the features); and

A DevOps team (building tools to support CI and deployments for the feature team)

The feature team prioritised the work that the DevOps team did and their working relationship was governed by a set of principles and a working agreement. Apparently, through this experiment, they have realised that having two teams doesn’t really work and it is better to integrate DevOps skills into each feature team. Their challenge now is there aren’t enough DevOps skills available for the number of teams that they currently have, so they are trying to find ways to change that. Rather than taking a push approach, they are trying pull techniques like hackathons, demodays and gamification, to encourage the Feature Teams to build the skills from within.

Biase highlighted a number of challenges they experienced at the start of their journey and also the value of finding experts to help teams work through the technical issues. Their next set of experiments on this journey are related to

Growing skills from the ground up

Creating the necessary culture shift

Allowing for organic growth

I look forward to hearing more about their journey to come. What is your experience in including DevOps skills in your cross-functional feature teams?