Archive for the ‘Team’ Category

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:

  1. 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).
  2. 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…

I shared some of these challenges on the #zacoachclub channel in the Coaching Circles Slack Group and got some useful ideas to try out:

  • 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?


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: Kick-off to Lift-off

Posted: January 11, 2017 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. 


This talk focused largely on the Context section of the Agile Charter, which is meant to be a living set of artifacts and sessions that help a team clarify their Purpose, Context and Alignment. Alignment, in particular, is a part that will probably adjust frequently as team members interact: often daily. The hypothesis is that a team that starts well may not necessarily finish well; but a team that does not start well will never finish well. In other words, a good kick-off is required for (a team) to lift-off.

The first part of Context is “Boundaries and Interactions“. This is understanding who your team members are; how you will interact with each other; how you will interact with others who are not in the non-core team; who these non-core team parties are; and how we will communicate over differences. Steve described one cool activity to kick this off. For the core team, have everyone create a name-card with a photo/image, their name, their talent, and one fun fact. The team places these cards in the center of a sheet of sorts and then draws a boundary around the group. This indicates the boundary between the core team and anyone who isn’t in the core team.

The team then discusses who else may be

  • Interesting to the team (they can give advice/we value their opinion/they have input);
  • Important to the team or project (key knowledge / have to approve or provide things); and
  • Interested in the team or project

These people or groups are then represented outside of the circle and the team discusses and agrees how the core team will interact with these parties. This could be fleshed out further into some kind of communication plan, however it is necessary to balance too much detail and complexity against something that is quick to review and update as it changes. Remember: the Agile Charter should be a LIVING artifact.

The second part of Context is “Committed Resources“. In this instance, we do mean resources/things and NOT people. The proposed activity for this is to draw a timeline arrow with the end point being the mission for the release (agreed in the Purpose section). The team then makes a list of things / activities / skills they will need to achieve the mission and places them on the timeline depending on when they will be required. These can also be ranked in terms of importance. The team then highlights (e.g. using a red dot) resources that the team does not yet have. The idea is that one needs to confirm the missing resources before the time when they are required is reached.

The third and final part of Context is “Prospective Analysis” or “The analysis of prospects”. Basically this means looking at things that might happen and identifying whether they are risks or opportunities. An easy way to do this, once the team has a list of things that might happen, is to categories them into a quadrant with the vertical axis of [Good]-[Bad] and a horizontal axis of [Won’t Happen]-[Will Happen].

Have you ever done a kick-off with your team? What parts of the Agile Charter have you found particularly useful? Which parts have you not experienced as valuable?


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?

#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:



Leader Transformation


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


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.


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?