Archive for the ‘Scrum’ Category

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

Image result for help your team

I think a better title for this talk by Gavin Stevens would have been “How to be an awesome Product Owner”.

The basic structure of this talk for Product Owners was:

  1. A dysfunction and how you will notice it
  2. What you (as the Product Owner) can do about it
  3. Some ideas for how you can take action

The seven dysfunctions that Gavin touched on were:

  1. The team has lost sight of the vision
  2. The Corporate Mentality is that the PO is the leader of the team
  3. The team is not autonomous in the sprint
  4. The team isn’t motivated to finish the sprint early
  5. The PO is the middle man
  6. The PO needs to check everything
  7. The PO is not with the team

The team has lost sight of the vision

What you will notice are “weird” statements or questions like:

  • “How does this fit in?”
  • “Why now?”
  • “If I had known…”

The solution is to ask the team those weird questions when they are planning / discussing their work before the sprint starts.

Corporate Mentality: the PO is the leader

You will hear language like “Gavin and team”. Or “well done to Gavin for this great delivery”. The organisation has not yet realised that the PO is a leader – not THE leader.

What you need to do is create an understanding of the team structure. That the team structure is flat and that there is no single leader in a self-organising team.

The team is not autonomous in the sprint

The team doesn’t seem to be able to make decisions about how they work in the sprint. You, as the PO, are always the “go-to” guy.

What you need to do is empower the team.

Some ways you can do this are:

  • Don’t interfere during the sprint. Trust that the team knows what the goal is (because that was your job) and let them decide how to achieve it.
  • You make the decisions about why, and maybe what, but never how.

The team is not motivated to finish the sprint early

The team doesn’t seem motivated to try to achieve the sprint goal before the end of the sprint. This may be because, as soon as they finish, more work is automatically added to the sprint.

You need to create space. People need time to be creative. One way to achieve this is to tell the team that when they hit the sprint goal, the remainder of the sprint time is theirs to do with what they please.

Gavin mentioned that what the team then chooses to do is also often insightful. If they’re bought into the roadmap, they’ll usually choose to pick up the next pieces on the backlog. If they choose to do something completely different, then it’s usually a good idea to question why they feel that the work they chose to do is more valuable.

The Product Owner is the Middle Man

Which also means the PO is a blocker. Because if you’re not there, everything stops.

Some of the signs that you are a blocker are:

  1. You are the admin secretary who needs to check everything before the team releases
  2. Selfish backlogs – no one besides the PO is allowed to touch the Product Backlog
  3. You are a layer between the team and stakeholders

If you find the reason you are checking everything at the end is because it’s not aligned to what you expected, then you need to examine all the up-front areas where you are responsible for conveying what the team needs to deliver the right thing

  • Have you communicated the vision properly?
  • Did you help the team ask (and answer) the right questions in grooming and planning?

Once you believe that you have given the team the right information to build the right thing, then make each team member the “final checker”. Any team member can do that final check that something is ready to release (because a second set of eyes is usually a good thing – it just doesn’t need to always be the PO).

Fixing selfish backlogs is “relatively” easy – let others add to the Backlog. Ordering is still your decision, but what goes onto the list can be from anyone.

The Product Owner needs to check everything

The reason for this is normally related to a lack of trust: this happens when the PO doesn’t trust the team. Some of the signs are the same as when the PO is the middle man.

Building trust is a two-way street: the team need to trust the PO as much as the PO needs to trust the team.

One way to build trust is to create a safe space. Do this by

  • Allowing team members to learn from their mistakes
  • Not blaming
  • Protecting the team from external factors
  • Taking the fall when necessary

A second way to build trust is to tell team members that you trust them. For example, when a team member says “I’ve done all the tests and I think this is ready to go. Can we release?”, then don’t answer with a yes. Rather say “I trust you know when it is ready so you can make that call”.

The Product Owner is not with the team

The Product Owner needs to be available – to the team and to stakeholders. Although the PO should not be a middle man, one of the main functions of the role is to act as a translator between the team and stakeholders. How much you need to sit with your team does depends, and is somewhere on a continuum between “Always” and “Never”.

Some things you can try to make yourself more available are:

  1. Don’t schedule/accept consecutive meetings
  2. If you do have downtime and work in an environment where working distributed would be an option, rather choose to spend it at your desk if possible.

 

I found this an interesting talk and what was especially great was it paralleled much of what we have experienced as a team. Are you a Product Owner? What are your thoughts on what Gavin had to say?

Advertisements

I have a new Product Owner (PO). She is new to the team and also relatively new to the Product Owner role as a whole. One of the things that I have needed to coach her on is Backlog Refinement or Grooming – and how to do so at the various levels of the Product Backlog. This is something I’ve seen many teams struggle with in the past. Either the team sees stories too late (and there’s a rush and they don’t really problem-solve); or they see them too soon (and we go into the detail far too early and forget most of it when/if we eventually pull the work into a sprint); or there’s some gap between understanding the problem and getting into the detail which means some team members get left behind and never really own the work.

So, this time, I decided to try a different way of evaluating how far a story/epic/feature was in its “readiness” journey (and, thus, how much more grooming the team still needed to do and at what level). And, what I decided to try was overlaying the ADKAR change management steps on each of the items that the PO had ordered near the top of our Product Backlog for the next couple of sprints.

So, for each item we care about, we regularly check whether the team has moved through:

1. Awareness

Do they even know this is coming? Do they know what it is? Are they familiar with the domain and the problem space?

2. Desire

Has the team engaged with the problem? Do they understand what we are trying to solve for the user? Do they WANT to solve this problem for the user?

3. Knowledge

Have we covered all the aspects of the problem? Have we started thinking about how we might want to solve the problem and what questions we want to answer or explore? Are we starting to get a feel for the steps involved and how we can break this thing down?

4. Action

We’re doing what we need to do to be ready to start on this work in the next sprint. We’re ensuring ourhighest ordered stories are INVEST.

5. Reinforcement

We’ve finished our story – what did we learn? (The Sprint Review is one natural place where this happens.)

 

Mostly, both in change management and backlog refinement, people seem to tend to launch in around steps 3 (Knowledge) or 4 (Action). Together with the Product Owner, I now try make sure we’ve moved through each of the first four steps (ideally in order) before we pull a story into the sprint. And if we realise we’ve missed a step, we try to go back to it as quickly as we can. This doesn’t need to take long at all – for the Awareness step it’s often just a short communication – after a stand-up, or perhaps in a Review when sharing the roadmap. In fact, for the Awareness step, I’ve noticed that it doesn’t have to be a long thing at all. Often the best way to move teams through the Awareness step is to repeat something brief many times, over many channels, and over a short period.

We’ve been trying this for about two months now and, so far, it seems to be working better than anything I’ve tried before when checking to see that the state of the backlog matches where the team’s understanding is of a particular piece of work. And, because we’re not skipping any important parts of our team coming to grips with the problem, we seem to be uncovering important questions and potential challenges earlier in the process.

What tools have you tried to help with Backlog Refinement? Or where have you borrowed from one problem space (e.g. Change Management) and found it has helped with a challenge in another problem space (e.g. Backlog Refinement)?

Image result for grooming backlog

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

  1. 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.
  2. 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.
  3. 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.
  4. 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

  1. 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
  2. Listening out for impediment words
  3. Using open-ended questions to help the team develop insights or notice information

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:

  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?

Scrum-Task-Board

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?

chasm1I’m currently a member of a coaching circle and our topic last week was “Non co-located or distributed teams”. Then this week someone from our marketing department approached me. We’ve decided to bring our public website in-house and they need a new team, but history has shown us that finding new developers of the calibre we want is no easy feat. One option we haven’t explored to date is developers who work remotely (which would mean we could look farther afield) and he wanted to know what my opinions were. I offered to compile some information for him, including some of the conclusions from my coaching circle discussion, and then figured it was worth adding it to my blog too.

I have worked in distributed teams before – from formal project teams with developers on-site in Cape Town working with off-site analysts, testers and project managers in London; to informal ‘leadership’ teams across offices over three locations and two countries; to performance managing direct reports working in an office 2000 km away. The common point of success or failure every time? The people on the team. The next biggest point of frustration every time? The type and quality of communication tools available.

People

There is a lot of literature out there around the types of behaviours you want in agile team members and, obviously, each company also has its own set of values and culture it looks for in new hires. This list is a list of traits that stood out for me as things that made someone great to collaborate with when working in a distributed fashion. All too often, people without these traits made distributed collaboration quite difficult and sometimes impossible!

  • Emotional maturity – able to communicate without getting emotional about things; can handle openness.
  • Strong team norms – when the team agrees to try something or work in a particular way, this person will take accountability for whatever they have to do even if it wasn’t their preferred way of doing things
  • Effective communication – verbal and written. Can write and read well. Can get their point across and summarise well.
  • Takes responsibility for preparation – if things are distributed beforehand for people to read or prepare, then this work is done. Doesn’t walk into meetings “blind”.
  • Knows how to use tools and knows about conference call etiquette (this could be covered as training for the whole team).
  • Is proactive in staying ‘in the loop’ – will ask questions if they see something that they don’t know about (defaults to information gathering rather than assuming if it was important enough someone would let them know).
  • A T-shaped person – or at least someone who is prepared to do tasks that are not ‘part of their job description’

 

Other Success Factors

This list was compiled by my coaching circle:

  1. Face-to-face is necessary for initial trust building and to create coherence. Where possible, having everyone co-located for a period at the start of the project makes a huge difference. Also gets people used to the way others work without the ‘noise’ of not being co-located.
  2. Would be helpful to find ways to have online virtual interaction (outside of work) e.g. online games/ice breakers/other experiences.
  3. Face-to-face tools are a must.
  4. After an extended period, it helps to have team members ‘rotate’ as traveling ambassadors.
  5. Need to understand cultural differences. Probably worth having a facilitated session to highlight/understand these.
  6. If you have teams working in areas, then have an on-site SM/coach per team.
  7. Keep teams small.
  8. Try pair/collaborate with an offsite person as often as possible.
  9. If you have teams in different locations, have a dedicated facilitator in each location for meetings (like planning, review).

CoherenceCulture

Links

What has your experience been with working in or with distributed teams? What did and did not work for you?

These are some tweets I made while reading “User Story Mapping” by Jeff Patton.

It’s a great read that I highly recommend!

2

How inspirational!

1

 

 

 

 

4

I like this because it can be applied regardless of the type of product you’re delivering or product life-cycle stage you are in.

3

 

5

If you have the book, I’m referring to the picture on page 71

 

 

6

10

A.k.a. an organisational profile

 

789

1

Grooming ideas

 

2

Grooming to envision a product that is valuable, usable and possible to build.

 

 

 

 

 

 

 

 

 

 

3

Grooming to plan your development strategy. Intention is building what you need to learn the most, first.

4

Grooming to plan your next development cycle (sprint).

5