Posts Tagged ‘leadership’

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

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

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

Popcorn Flow

agileafrica.JPG  popcornflow

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

 

 

Leader Transformation

agileafrica

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

Key take-outs for me:

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

Mob Programming Case Study

mob

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

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

 

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

Kniberg

I was very excited at the fact that Henrik Kniberg was presenting at Agile Africa this year. And his opening keynote did not disappoint. First, he made it clear what he meant by Scale. He didn’t mean a couple of teams, or even many teams working on different teams working on separate things – he meant numerous team with various inter-dependencies. And then he told us some ways we could avoid becoming “unagile” when working with lots of teams.

 

He said that the first thing to realise is that for such a complicated ecosystem to work, you want everyone to be operating from a space of high autonomy and high alignment. When you achieve that, then everyone understands the problem and also has the mandate to figure out how to solve it. kniberg1

Kniberg then introduced the concept of a “soup” of ingredients required for an environment in which many teams could thrive and continue to operate in an agile fashion. The ingredients of his soup included:

  1. Shared Purpose
  2. Transparency
  3. Feedback Loops
  4. Clear Priorities
  5. Organisational Learning

1. Shared Purpose

Kniberg emphasised that in order for everyone to have a shared purpose, over-communication was essential. Every team member needs to be in a position where they are able to answer the questions:

  • What are you working on?
  • Why are you working on it – what is its impact?
  • How will you measure when it is done?

He described the following top-down model as an example:

  1. The company agrees on their beliefs. This belief relates to how they are to remain a viable operation. It could be around how the company believes they make money; who their customers are; or what is likely to happen in the future.
  2. Beliefs then break down into North Star Goals. This is a goal that the organisation wants to achieve in order to realise a belief. It needs to have metrics.
  3. Goals are then broken down into “Bets“. It is called a bet because it is a hypothesis: if we do this, then we think (bet) that this will be the impact on our goal.
  4. And, finally, teams have goals which contribute to proving or disproving bets (Kniberg called these tribe goals).

2. Transparency

Being clear about what everyone is working on and why helps to provide context that enables autonomous teams to make intentional rather than accidental decisions. One of the tools Kniberg shared with us was the DIBB Framework.

DIBB Framework

DIBB stands for Data, Insights, Belief and Bets. Basically you have a single space listing all the prioritised Bets and it is very clear what data was used to generate insights that led to the Bets, and then the Belief that particular Bet relates too. Bets can be tracked on a single Kanban taskboard with the columns: Now (what we’re working on now); Next (the Bets we will work on next); and Later (not priority for now). Kniberg emphasised that all of this information should be in a simple format that was easy to share with all (one of the companies he worked for used a simple spreadsheet).

3. Feedback Loops

We all know feedback loops are important. Feedback loops help us adjust our course. Scrum and other Agile frameworks already have built-in feedback loops for single teams. It is necessary to increase the feedback loops to cover multiple teams when scaling. Examples of multi-team feedback loops could be a Scrum of Scrums, multi-team retrospectives, Friday demos, Whole Product Review or Alignment Events, and Management Reviews.

Whole Product Review

A whole product review is when all the teams working on a particular product (whether building features or working as a support team) get together to plan for their next timebox. It includes the following components:

  • A demo by each team of what they have done since the last Product Review (to create context)
  • Break-outs per team to plan ahead for the next timebox.
  • Creation of Team Boards that include
    • The goals for the next timebox ordered by impact
    • Stretch goals for the next timebox – these may not be achieved
    • Risks in the next timebox
    • The deliverables that will be delivered at the end of the next timebox
  • A management review of the team boards on the same day before the next timebox starts

Triple Feedback Loop

This actually came out of a conversation I was listening to during one of the Fish Bowl sessions at the conference (and not from Kniberg), but an idea for these multi-level feedback loops could be:

  1. Normal team reviews (Loop 1)
  2. Monthly product reviews (Loop 2 – with all the teams)
  3. Quarterly Sponsor review (Loop 3 whole day with team and management)

4. Ordered Clear Priorities

Ordered priorities help teams make the right decisions when trade-offs are required. Priorities should feed down into teams from the Company Beliefs and North Star Goals. Clear priorities help teams answer the questions “If we can only do one, which one would we do and why?”.

5. Organisational Learning

In order to improve, we need to learn. We cannot learn if we don’t have time to stop and process feedback that we receive. Or have time to practice skills we are growing. Kniberg suggested a couple of ways to create slack time in teams:

  • A pull team schedule where teams pull work as they have capacity to do it
  • Scheduled slack time e.g. retrospectives, gaps in sprints, etc.
  • A culture of promoting learning over busyness

Some ideas for cross-team learning:

  • Holding “Lunch and Learn” events where teams get together in an informal session to discuss a particular topic
  • Cross-team retrospectives
  • Embedding team members i.e. having a team member from the team that is sharing temporarily sit with the team that is learning

chef The last part of the keynote dealt with the “chef”. The chef is the person who ensures all the ingredients are available for the soup and continuously tweaks them to ensure the soup is as tasty as possible. In traditional organisations, we used to call this person or persons “leaders”. Leaders are not there to tell the team how to solve the problem. They are there to ensure that the team environment contains the ingredients for autonomy and alignments.

Leader chefs:

  • Create a shared sense of accountability
  • Enable teams to align their decisions to company goals and with other teams
  • Ensure that decisions can be made through transparency and clear ordering of priorities
  • Create slack

My main take-outs were:

  • Intentional rather than accidental decisions
  • Scaling needs autonomous teams that are aligned
  • Some cool ideas for creating top-down goal alignment and transparency
  • Some cool ideas for creating peer-alignment and transparency
  • The role of leaders in an Agile set-up

What were yours?

 

https://sketchingscrummaster.files.wordpress.com/2016/08/hendrik-kniberg1.jpg?w=648

With thanks to sketchingscrummaster.com

Being Brave

Posted: March 24, 2016 in Team
Tags: , , , , ,

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

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. 

This was one of the most enlightening talks of the two days for me (enlightening in that I had a new insight). As you can see, even my sketch-note is crammed with un-creative text.

change

An started the talk with some group feedback on the word ‘judgment’ and its associations. Largely, judgement is associated with negative emotions and often results in fear. Fearful people struggle to think clearly which means people who fear a change will self-limit their vision and possibilities. I went to another session later in the conference where we explored the difference between opinion (facts-based) and judgement (interpretation-based) a little more explicitly, but more on that in a later post.

An facilitated most of the session using a tool that I think would be useful for most change in organisations. The tool starts with identifying ‘change monsters’ – these are things that can create anxiety in the people affected by the change – and include:

  • Uncertainty/unknowns/change from the what we know
  • Fear of failure
  • Loss
  • Culture
  • Complexity

For each “monster”, we unpacked the following questions:

  1. What behaviours would we observe in people who were experiencing that particular monster? For example, people who have a fear of failure may want to micromanage everything.
  2. For each behaviour, how did the “change” (in our example, agile adoption) reinforce or enhance the negative behaviour. This was an interesting concept for me as usually change agents associate only positive things with the change that they are championing, and we do not stop to think about how the change itself increases resistant behaviours. For example, in the case of agile, the lack of clear roles may reinforce behaviours related to people’s fear of loss.
  3. For each reinforcement, identify ways in which you can manage or counteract the behaviour and/or the impact of the change on that behaviour.

An provided us with a long list of ideas for dealing with the ‘change monsters’ – you can refer to my sketch-note for most of them. Think about a change you are or have implemented in your organisation. Which monsters and behaviours did that change enhance?

#SGZA 2015: Owning your slippers

Posted: October 29, 2015 in Team
Tags: , , ,

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. 

slippers

This was a very interesting and insightful session. We only had 45 minutes, but apparently Danie, Jo and Kevin also offer a full-day version. They refer to plenty of models that are all tied together nicely in a non-threatening activity (which is pretty fun too) in their workshop. One thing that was very clear from the exercises is just how bad we are at making valid observations that are not clouded by our own perceptions and interpretations. One example is when Danie asked someone to say what they had observed about their group, at which point the person responded “everyone looked happy” (judgement). Danie kept repeating the questions and eventually we arrived at the valid observation that “most of the people were smiling”. This is an observable fact – sans any inferences and interpretations – and can be challenged on facts alone.

We also briefly explored the drama triangle. A person can enter an interaction as any one of the triangle points (rescuer, persecutor or victim) but everyone will eventually end up as a victim. The only way to avoid the drama triangle is to practice mindfulness (owning your own slippers) which will help you stay off the drama triangle entirely. Owning one’s slippers means accepting them for what they are. Until you own your slippers, you cannot change them.

Finally, the facilitating team provided a nice idea for practicing true observation:

  1. Attend a session and write down everything you observe, moment-for-moment. Imagine you are a video recorder.
  2. Review what you have written and note how many items are not true observations of fact, but have been coloured by your Ladder of Inference. (As a variation, you could ask someone else to check your observations for you).
  3. Rewrite these judgments as true observations.

Have you used any of the models in my sketch-note? Which ones did you find useful? How have you practiced using them?

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. 

Questions

This was an interactive workshop type session by the ladies from @GrowingAgile.

My main take-outs from the session:

  1. You can ask powerful questions without understanding the problem: One of the exercises we did was to pick a random powerful question from a pack of cards. We gave our partner two minutes to explain their problem and then asked the powerful question. Majority of the time, the person found the question helpful, even though it was randomly picked.
  2. Your intent matters: The intent is not to fix the problem. The intent needs to help the person expand their own thinking so that they can get themselves out of a rut (and hopefully solve their problem themselves).
  3. Your role matters: Depending on the context, your role in terms of the person may impact the authenticity of using powerful questions.
  4. The most powerful questions are questions about the “why”.

There are some examples of powerful questions in the sketch note. Try using one of them next time you’re struggling with a problem and see what happens. One of my ideas is try them out at one of our Community of Interest sessions.