One of the challenges of working with software is that one is rarely building something from scratch. Usually, a team is working across a mix of maintaining existing (sometimes old) code; refactoring/migrating old concepts to new places; experimenting with new ideas; and/or just changing things to make life better. This can make it really hard to decide just how much effort needs to be put into a piece of work. Does it need to be the all-singing-dancing-tested story? Or will a cowboy-hack for fast feedback work just as well? And what does it mean to cowboy-hack in the financial industry vs for a game used by ten of my family members?

I work with a team that is working in the financial industry for a fairly high profile client that is nothing less than obsessed with their brand and reputation. Which is a good thing to worry about when people are trusting us with their life savings. We’re also busy migrating our web offering to a new technical platform, except it’s not purely a migration because we’re also extending our current offering to work on mobile devices, so there’s experimentation and user testing required too. In this environment, it’s very hard to deploy anything that hasn’t got a solid safety net (automated testing) whether it’s feature toggled on or not. In this environment, the focus is on keeping things safe rather than learning fast. And, sometimes, that leads to us over-engineering solutions when we’re not actually even sure we’re going to keep them. And that all means sometimes learning is very expensive and usually takes a long time.

With that context, we have recently had some conversations as a team about how we can narrow down our options and learn more quickly and cheaply for those pieces where we really don’t know what we need to build. A lot of good questions came out of that session, including one about when can we just hack something together to test a theory and when should we be applying due diligence to ensure code is “safe” and tested. Here are my thoughts (using two well-known and useful models – especially when used together) for thinking about when it is OK to experiment without worrying about things that keep us “safe”, and when we need to keep “safety” in mind while we iterate over an idea.

(In case it isn’t clear, there are cheaper ways than writing code to test out an idea – and those would be first prize. However, at some point you probably will need to build something to progress the fact-finding of ideas that have passed the through the first few experiment filters.)

The first model is fairly well known (and you can find a full explanation here):

MVP kniberg

The second is one I’ve newly learned about, and using them together was a great a-ha moment for me 🙂

 

Hierarchy of User Needs

 

How “safe” you need to keep stuff depends on where in the learning phase you are and what your experiment outcomes relate to.

The first phase is testing an idea. This is figuring out if something will even work at all. Will someone like it enough to buy it or pay for it? Do we even have the skills to use this? Does that third-party plugin do all the special things we need it to? At this point, you want to learn as quickly as possible whether or not your idea is even feasible. You may never even use it/build it. If you can even avoid writing code (the book “The Lean Startup” is full of great examples), then you should. It’s about getting as short a feedback loop going as possible. In the diagram, the person wanted something to help them got from A to B. One of the things that was tested was a bus ticket.

The second phase is building something usable. This speaks to the two bottom layers (and some of the third) of the hierarchy of user needs triangle above. Here we probably do need to keep our code safe because it’s not really usable (properly usable) until it is released. We will still be experimenting and learning, but some of those experiments will be around how does this work “in the wild” – e.g. from a user perspective, a performance perspective, or a feature perspective. Whatever you build in this phase you’re probably going to mostly keep and iterate over (because you’ve already tested the idea is valid), so you do have to consider maintenance (and, thus, care about things like automated testing) in this phase. At a micro level, within this phase, there probably will still be ideas that you need to test out and most of the experiments are more likely to be around how rather than what, but there is a blend of both.

The final phase – tackling the rest of the pyramid – includes adding in those “special effects” but ALSO incorporating more of the nice-to-have feedback from users that you should have gained from all your experiments along the way. In the transport example, the car at the end is a convertible rather than a sedan. A sedan would have been perfectly usable, however at some point when they were testing out ideas, the user mentioned that the one reason they preferred the skateboard over the bus ticket is that they liked to feel the fresh air in their face. That kind of feedback is what makes things lovable/special – although in no way does it may it more usable. FYI most organisations running an iterative approach often choose to stop once they get here, due to the law of diminishing returns. The problem with waterfall is because everything was done big bang, you didn’t have the option of stopping when you’d “done enough” (because there were no feedback loops to figure out when done enough was).

Depending on a team’s context, we could be anywhere on this journey depending on which idea or feature we are talking about. Which is why the WHY becomes super important when we’re discussing a product backlog item. WHY are we doing this piece of work? WHAT do we need to get out of it? WHAT is the assumption that we want to test? And what does that mean for how much effort and rigor we need to apply to that piece of work?

Besides helping teams identify what kind of work they should be focusing on, these two models (especially the user needs one) have been helpful to me when having conversations of where UX and UI fit into the Scrum team mix. If you think of UX as part of making things basically usable (the bottom part of that layer if you will); a combination of UX/UI moving you into the pleasurable layer; and UI creating the cherry-on-top – then it’s easier to see when just building to a wireframe is OK (to get feedback on functional and reliable) vs having something pixel perfect with animations (that incorporates what we learned from testing functional, reliable features).

Or, roughly:

User Needs wth UI-UX

Let me know if you find these two models helpful. Have you used them before? Where have you found that they didn’t translate that well into a real life scenario? What did you learn?

Scrum Ceremony Puzzle

Posted: November 19, 2018 in facilitation, Scrum
Tags: , , ,

Image result for puzzleThis is a “game” I played as a kick-off activity with a new team. Thought I would share in case someone might find it useful 🙂

The basic idea is to match the correct Purpose, Outcome(s) and Output(s) to each Scrum ceremony.

Preparation:

  • Print out the Ceremony Boards (each team will need its own set)
  • Prepare the Ceremony Cards (each team will need its own set)

Game Play:

  • Place the cards on the boards in the correct spaces
  • The cards are colour coded as a Purpose/Outcome/Output to help

How we played it:

  • I divided my participants into two teams and made a bit of a competition of it.
  • Both teams started in opposite corners of the room and ran to a table in the middle to try solve the puzzle.
  • When a team thought they had solved it, they would signal and both teams went back to their respective corners (think “Survivor style).
  • I would then check the solve against my solution. If the team had solved the puzzle correctly, then they were the winners. If the solution was not correct, both teams could return to their tables to continue working on the puzzle.

Feel free to try out the game and give me feedback!

Resources:

Image result for yes but improv gameRecently my team played a loose version of the “Yes, But” improv game at the beginning of a retrospective (retro) as an icebreaker. I say loose, because we played it in a round (rather than in pairs) and did two rounds. I started each round with the same statement: “I think we should have snacks at Retro” (this is something that often comes up – tongue-in-cheek – during retro conversations).

For round one, the next person in line always had to respond starting with “Yes, but”. At the end of the round (we were seated in a circle), I asked the group to silently pay attention to how they felt and what they experienced during the exercise.

For round two, the next person in line had to respond starting with “Yes, and…”. At the end of the second round I asked some questions about how the team experienced both rounds:

  • How did the first round feel?
  • How did the second round feel?
  • What made a round difficult?
  • What did or could you do to make a round easier?
  • What does this mean for how we respond to each other as a team?

Interestingly (and unexpectedly), my team struggled more with the “Yes, and” round than the “Yes, but” round. To the extent that one team member couldn’t even think of something to say for the “Yes, and” round! At first I was a little stumped, but as we discussed further we realised that:

  1. As a team, we found it more natural to poke holes in ideas rather than add to ideas we didn’t completely agree with.
  2. When we didn’t agree completely with a statement, we got “stuck” and couldn’t think (easily) of a way to add to the statement.

As an example for point 2, above, one person responded to the statement with: “Yes, and we will need to do exercise”. The person following them really struggled to respond (because they don’t like exercise) and didn’t really come up with anything convincing. As a group, after some thought, we eventually realised that “Yes, and it can be optional” would have been a perfectly valid response. However, as a group, it took us a while to get there. So it definitely wasn’t something that came naturally to us.

For me, these were quite cool insights, and probably good for a team to be aware of, particularly when we’re struggling with new problems or trying to find creative solutions.

Have you tried similar games? What did you learn or experience? How has it helped your team?

6hatsThis is my take on using “Six Thinking Hats” to reflect on a period of time. You could use a light version for a retro – or the full version to review something longer like the stage of a project or a release. It’s usually most effective after some milestone event and where the learnings can be applied going forward. There is still value in doing it at the end of a project, but what you get out of it for future teams may not be as valuable as you won’t always know what will be applicable.

Preparation

In order to save time in the session, you do need to do a fair bit of preparation. Try and collect as many facts about the time period as you possibly can before the session. Facts are anything backed by data and some common “facts” one might include are:
– Team changes (people joining/leaving)
– Events (e.g. release dates)
– Sprint information (velocity; commitment; actuals; sprint goal; etc.)
– Changes in process
– Special workshops or meetings
– Any data provided by metrics

I’ve found the most effective way to use the facts in the session (and the rest of my post assumes you have done this) is to map them onto a really large timeline. I typically use a sequence of flip chart pages that can be laid out so that attendees can literally “walk the line”. I’ve stuck them up on long walls or laid them out on a row of tables and even used the floor where I needed to.

It is also useful (for the reflectors in the team) to send out a description of the hats in advance and ask them to think about each one before the session.

Before you start your workshop, you have to set up the room (also see the tips at the end of this post):

  1. Lay out your timeline
  2. Ensure there is space for people to easily walk along it
  3. Have various stationary points along the timeline with pens and stickies
  4. Don’t forget to have a whiteboard or some other space for grouping the ideas

Materials

Besides your “timeline” of Facts, you will also need:

  • Small pieces of paper that people can write appreciations on
  • Pens
  • Stickies: one colour per hat
  • *Optional* Snacks

For the different hats, I usually use the following colours

  • Facts: N/A (people write directly on the timeline)
  • Instincts: Red
  • Discernment: Blue
  • Positives: Yellow
  • Ideas: Green

Process

The process I follow is largely based on this one and, as they mention, I have found that the order is fairly important.

For an average team, I time-box each section to about 10 minutes. Breaks need to be at least 5 minutes, but could vary depending on the time of the day (e.g. you may need a lunch break). If you are going to use the data in the session to come up with actions and improvements, then your time-box for that part will depend on what technique you plan on using. Obviously these may need to be adjusted based on the size of the group, but as most of the steps are self-paced, one advantage of this workshop is that it works quite well with larger groups.

Round 1: Facts

Have the attendees “walk the line” from the beginning to the end. This is a walk down memory lane and also a chance to fill in any blanks and ensure everyone agrees that the facts are correct. There are no stickies for this step – if people want to add or change anything they do that by writing directly onto the timeline (at the right point in time, of course). Remember to remind everyone that they should only be adding facts.

Round 2: Instincts

“Gut Feel”

Hand out your “instinct” stickies. Remind every one of the definition of an “instinct”. I sometimes skip this round because people struggle to differentiate between “instincts” and “positives/negatives”.

Appreciations and Break

Give everyone a chance to write appreciations (these will be shared later – either at the end of the session or afterwards). It’s also a good point to have a short break.

Round 3: Discernment

“Devil’s Advocate”

Make sure you’ve collected the “instinct” stickies and that the next colour of stickies is available. Remind everyone what the definition of “discernment” is. Everyone repeats their walk of the timeline, this time adding stickies to the timeline for things that didn’t go well or were disappointments.

Cool off

Have another break (in case things got emotional). Have people write more appreciations.

Round 4: Positives

“Keep doing this”

This is the last walk of the timeline. Again, remind people of the definition of “positives” and ensure there are only “positive” stickies lying around for people to use. They walk the timeline one final time and add stickies for things that went well.

Lastly: Ideas

“If I did it again”

There are various ways to capture and categorise ideas. The intention of this round is that attendees use the timeline to stimulate their thinking of how they could have done things better. Or how they would do things differently if they had to do it again. This is  sometimes also described as “green fields” thinking.

And then (now or later)…

If you were using this technique for a retrospective, you would ideally get actions from the information as part of your session. If the session was to reflect on a project, perhaps the data would be grouped into things like “Good ways to kick off” and shared with other teams. I’m quite a fan of the quadrant method of grouping similar stickies to find topics to address (see photos below for examples from a retrospective I did). What you do next all depends on the ultimate purpose of your session.

quadrants

Tips

  • Only let the attendees have access to the writing materials relevant for the round i.e. gather up the stickies from the previous round and “change colours” for the next round.
  • Have a number of “stationary points” – so that people can grab stickies and pens as soon as they have a thought.
  • Related to the above, have an excess of stationary and pens so people don’t have to wait for each other.
  • When preparing your timeline, try use pictures/symbols/colours to create visual patterns and cues for repeat facts e.g. document your sprint information in the same colour and layout for every sprint on the timeline or have a bug symbol where you have added statistics around bugs.
  • Don’t forget to share the appreciations! Especially if you’ve decided not to do so in the session.

I have applied this technique a couple of times and used the output for various things:

  1. We’ve used it to gather data for a team which was unfortunately not very transparent and then used that data to paint a “real picture” for external stakeholders.
  2. We’ve used it in retrospectives to identify improvements to team / process / products.
  3. We’ve used it at the end of a project to create guidelines and lessons learned for future projects and teams.

timeline

Have you used this technique before? What worked or did not work for you? Where might this approach be useful?

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?

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?