Category: Feedback

Blogging pause

I’ve decided to take a bit of a pause from blogging, to reassess how I’m investing my time.

Thanks to everyone who has been reading and commenting. I hope that you found it as interesting and enjoyable as I have! I especially appreciate the time you’ve taken to share counterarguments.

robin.jpg
A friendly robin helping itself to chicken food

If you have any feedback or comments on what format of information sharing you enjoy, please let me know at guy@fuza.co.uk . I am particularly interested in:

  • Whether you think blogging is a smart way of me spending effort (compared to say speaking at conferences, attending meetups, writing whitepapers, tweeting, or whathaveyou)
  • How long/detailed you like blog posts to be
  • Whether weekly (or at least regular) matters to you
  • Content: I’ve tried to put lots of different topics in, do you think I should focus more on any one? For example, mathematics, psychology, agile theory or agile techniques

With your feedback making it more awesome, I hope to be back in the new year with a fresh lease of life!

In the meantime, feel free to reread some of my favourite posts…

 

Lean Manufacturing: Limiting innovation?

I’ve been running a “lean” business for 6 months now, and I’ve noticed that Lean Manufacturing principles applied to software development could lead to bad business. Let me explain:

Primarily, my concern centers around the lean manufacturing principle of waste reduction. The constant strive to reduce waste makes sense in an industrial production line, but does it make sense in a startup or exploratory environment?

An example

Let’s say there are 2 possible features you can work on. Feature 1 has a 90% chance of delivering £1 value, and Feature 2 has 10% chance of delivering £100 value.

Let’s say that the features take the same time to develop. From the maths,

Feature 1 “value” = 90% of £1 = £0.90

Feature 2 “value” = 10% of £100 = £10

And yet even with this understanding, because of the implicit risk and waste aversion of lean, we would say “there’s a 90% chance Feature 2 will be wasteful, whereas Feature 1 is sure to not be wasteful, therefore Feature 1 is a better idea”.

Good outcomes, but not as good as they could be

The waste reduction aspect of lean manufacturing gives us a local optimisation, much like gradient descent. Imagine a ball on a hill, which will roll downhill to find the bottom. This is ok, and it will find a bottom (of the valley), but maybe not the bottom (of the world, maybe the Mariana trench).  In that sense it is locally good, but not globally optimal.

The way mathematicians sometimes get round this is by repeatedly randomly starting the ball in different places: think a large variety of lat-longs. Then you save those results and take the best one. That way you are more likely to have found a global optimum.

So I’m wondering about whether this kind of random restarting makes sense in a startup world too. I guess we do see it in things like Google’s acquisitions of startups, Project Loon, etc. Perhaps we/I should be doing more off-the-wall things.

Closing commentary

Perhaps it isn’t so odd that Lean Manufacturing has “reduce waste” as a principle… In a production line environment, reduction of waste is the same as increasing value.

Still, if the optimisation problem is “maximise value” this leads to different outcomes than “minimise waste”. I would argue we should, in almost every case, be focusing on maximising value instead.

As we’ve seen with following the rituals rather than the philosophy and mindset of agile, it is beneficial to actually think about what we’re doing rather than applying things without understanding.

Comments below please, I know this may be a bit controversial…

 

Deep Dive: Retrospectives

The term “retrospective” is prevalent for any of the Continual Improvement meetings, largely due to the popularity of Scrum. However, this post really refers to any meeting where a change to process is made. Whatever you might call this, it is very important, as I hope I will show in this post.

Why should the team do a Retrospective?

  1. It allows them to talk about their feelings in a safe space (Social Connection/Relatedness)
  2. It allows them to make small changes to their processes, to try to make their delivery better (Mastery/Competence)
  3. It allows them to feel in control (Autonomy)
  4. It allows them to step back and see what they’ve achieved (Purpose/Competence)

So a Retrospective gives a lot of the things that Self-Determination Theory holds are important for motivation (highlighted in bold in the list above). If you aren’t doing retrospectives in some form, then you are perhaps missing out on a chance to motivate and inspire the team, as well as not helping them to deliver more.

Who should run it?

There are a few options here:

  1. An external (to the team) facilitator. This has the advantage of allowing each team member to equally participate. The disadvantage is that the team members may feel that the meeting is happening to them, rather than for them. And of course someone needs to arrange the facilitator.
  2. A scrum master or similar. Advantages include that they are probably good at facilitating, and know how to help the team work well together, and that it is their role so they will make sure the meeting is organised. The main disadvantage is that it can dis-empower the  team (as above).
  3. A team member. This has the advantage of making team members feel engaged with the process (especially if they each take a turn). It has the disadvantage of needing meta-coordination, and can lead to variable quality.
  4. A manager. I think this is a bad idea as it reinforces the hierarchical ideas, unless the manager is a very effective Servant-Leader and able to keep her/his opinions to a minimum!

Who should be there?

Everyone interested in the team performing well. So definitely the team including Product Owner (or equivalent), and anyone else who might having valuable insights to share.

What should the outcome be?

The outcome of a Retrospective should be a very small number of SMART actions. A small number since the team can be considered a Complex Adaptive System, and as such according to Cynefin (and common sense) should be conducting small experiments rather than many large changes. By SMART, I mean Specific, Measurable, Achievable, Relevant, and Time-based. Sometimes these actions will be about how the team work together, other times they might be about improving the working environment, software, tools, or interactions with others. Whatever is important to the team at the time.

It is also very important that a Retrospective is FUN! The  desired outcome here is that the team want to do it again.

What should happen in a Retrospective?

I’d describe a good Retrospective as Serious play. By that I mean playful but about something serious, with serious outcomes. Tools like retromat give great ideas for how to construct these kind of playful sessions. In particular, using colourful postit-notes, images, memes and other creative tools can make the session feel more fun. For me the important parts are:

  • Set the scene and let people check in. It is important here to get the energy levels up and frame this positively.
  • Write down separately comments about the last Time Period in some form
  • Allow people to speak about them
  • Agree on important core issue
  • Get the team to come up with and commit to a SMART solution or experiment
  • Get feedback on the retrospective itself

I think it is important to allow people to separately write things down because it allows the less vocal in the team to say what they feel without interruption by the more extrovert. It also keeps the discussion wide initially, before narrowing. This intentionally mirrors the Explore-Exploit of “the bandit problem” which is often applied to innovation theory. Essentially with Retrospectives we are helping the team to innovate themselves.

How often should we do Retrospectives?

Scrum says once a Sprint, where a Sprint is usually between one and three weeks. However, the team should decide the frequency. More frequent Retrospectives give fast feedback, and shorter feedback loops, so if you are very “agile” then it is likely you will be doing this very regularly. I’ve worked in teams that have a Retrospective each week, and others that have a Retrospective only once month.And of course they can change the frequency whenever they need, through the Retrospective itself. It really depends on what the team wants (more often is better as it gives faster learning).

 

The key to being awesome: feedback

Last week I was talking with one of my friends. “I’m going to get fired, I know for sure I am delivering below what they had hoped” he said.

This isn’t the first time I’ve heard these kinds of fears voiced. I encouraged him, as I am now encouraging you, to SEEK FEEDBACK. There is no need to live with insecurity. Everyone should do this, as it is valuable information about ourselves that we can use to self-improve. Doing this regularly is even better! There is no need to wait a year for your annual appraisal: by getting quicker, regular feedback we learn faster. With this in mind, please do take a minute to give me feedback on this blog, either in the public comments, or privately here:

How can I get feedback?

Often, feedback comes in an annual appraisal with your boss. You will likely also be getting some kind of feedback from your close friends (e.g. “it is really annoying when you turn up late Harry.”) In this post I’ll outline some well-established methods for getting professional feedback.

Pick some people whom you value the opinion of. This probably will be people from work, but may include some friends or family. A broad variety of perspectives and relationships will help you get a fuller picture.

Now there are many different ways I’ve seen for gathering this kind of feedback.

Start, Stop, Continue

This is arguably the simplest for a beginner: simply email some people asking them:

  • What should I start doing?
  • What should I stop doing?
  • What should I continue doing?

They’ll reply with some things, and maybe you’ll want to follow up with a one-on-one discussion to check your understanding on some of the points.

360 feedback

You can do this as “Start, Stop, Continue” or as a custom SurveyMonkey form with some traits you’d like particular feedback on. The “360” element of this is that you should ensure you ask not just your manager, but also your direct reports and other peers. The top link on google when I looked was this example. It is very quantitative and trackable if you do it regularly. I would only recommend this particular site if you have a direction you want to develop in though, as it restricts ability to comment on some things, like say whether they’d really appreciate it if you used some more effective deodorant.

Johari Window

This is a personality mapping test, where you can see how different people see you compared to your self-perception. I found this quite interesting and surprising. This is much more of a long-term improvement and measurement exercise, and again you won’t get specific feedback on performance, etc. in this. Try it out here.

A conversation

This is my favourite. It is best to give the other person time to prepare and get their thoughts in order about the feedback they’d like to give you. Keep it safe by using a start-stop-continue method or other framework if you prefer. If you have particular questions, you can ask them: again preparing this beforehand is great, but don’t hide behind a piece of paper. Ideally you’d both give one another feedback, since this is a great trust-building mechanism and you can both benefit!

Other methods

There are many other ways to get feedback. Let me know if you have another favourite in the comments below.

How should I take it?

Receiving feedback can be hard, especially if it feels critical. Remember this is an opportunity for you to grow, and these people are being nice enough to help you. If you take this with a developmentally-focused, rather than self-critical, mindset, then you’re on to a winner.