Posts Tagged ‘culture’

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?

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. 

As we’re also looking to move a very complicated, fragile system over to a new technology stack, I found this talk by @NigelBasel quite interesting. One of the most interesting parts was his application of Conway’s Law to the problem: the software had evolved and modeled when there were only a handful of developers working on the system; and now it needed to change to model the communication structures required between a number of teams working on the same codebase. He also showed us the output from a really cool tool (I think) called Gource which he’d used to model changes in their source code repository over time. Made me wish I could see the same animation for ours! I’m sure it would be fascinating!

Nigel gave a suggestion of two steps one could take when faced with this legacy code-wool problem:

  1. Stop digging (yourself into the hole)
  2. Get out of the hole (carefully)

They’re still progressing on their journey, but these are the steps they’ve taken so far to try and bring their code base back under control:

  1. They identified and fixed any coincidental cohesion – they moved parts of code which logically belonged together and just happened to be where they were because they were written into things like libraries and services.
  2. They shifted their thinking of layers to services and considered things like whether certain services like authentication be provided by 3rd party tools and removed from their code base. If a service seemed to make sense, they created it and then migrated functions as they were needed, thereby “starving” the old code base.
  3. The considered their code base in terms of business features and the data required and tried to group these together
  4. They write all their new code using their new strategy (as far as possible)

One issue Nigel admitted that they haven’t really got to grips with yet was version control. He emphasised that their journey is not yet done. I’m hoping we will hear more about their adventures and learnings once they have traveled their path. Did you find any of these points helpful? Do you have experience changing old code to reflect new organisational communication patterns?

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?

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