Working with the Polish as a Brit

I have spent quite a lot of time in Krakow, Poland, working with tech firms. I’ve been really lucky and made some amazing friends (and some annoying friends too, you know who you are). I like to think I’ve learned some things, and I hope they will be of interest and of use to others working across the UK-Poland cultural divide.

As part of this post, I’m going to make some hugely sweeping generalisations on national sentiment. These are just what I feel from the people I’ve met in Britain and Poland, and in the interest of brevity I’m not caveating that in each case. Feedback is welcome!

Don’t mention the war

  • The British feel like they entered the war because of Poland, so the Polish should feel some affinity for Britain.
  • The Polish feel like Britain didn’t enter the war until France was invaded. Betrayal may be an appropriate term. (Honestly, I’m probably more in the Polish camp now. Read Churchill’s History of World War Two and try not to be annoyed or frustrated at the “Twilight War” chapters.)
  • Pro tip: Do your research before weighing in on historical events.

Humour

  • Humour. The British know their humour is weird, and think others should enjoy it too by repeated exposure. Jokes are often woven into the fabric of work conversation.
  • The Polish sense of humour seems mixed, to an outsider. Some people like to keep work serious, and then joke when they are not working. Some like to blend work and joking. Universally though, no-one understands British humour except the British.
  • Pro tip: Keep jokes more “Big Bang Theory” than “Monty Python”

Greetings

  • British introductions go something like:
    • A: “Hi, how are you?” B: “Hi, how are you?”
  • Polish introductions go something like:
    • A: “Hi, how are you?” B: “Everything is terrible, I had a lousy weekend and I wish I was still asleep, I’ve got a bit of a cold and my mum made the porridge too dry this morning. How are you?”
  • Pro tip: I personally now prefer the more honest and descriptive Polish way. Maybe give it a go! Perhaps less negative than the Poles often describe themselves, though.

 

IM “noises”

These, it turns out, as with animal sounds, are not universal. Saying “oh” or “ah” may not convey the information or expression you were expecting. Just be careful. I had intended to make a table of these and might do that later if there is any interest.

This article is written with thanks to the many Polish and British people who encouraged my silly inquisitiveness. If I’ve got anything wrong, or if I’ve missed anything interesting, I’d really appreciate you letting me know either in the comments below or email.

A non-IT executive’s guide to Agile Coaches

Agile is an almost management-philosophical idea that is about getting better at delivering valuable working software. There are people calling themselves agile coaches who try and help do this. In this short article we’ll go through one aspect of the agile coach role, inspired by a recent experience. Thanks to those who were involved in this journey, you know who you are!

Agile Coaches aren’t Project Managers

A lot of “agile” is around motivational leadership techniques that you may be familiar with, for example Stephen Covey’s “The Seven Habits of Highly Effective People” or Dan Pink’s “Drive”. If you get a good agile coach, they will help your other leaders and managers to shape and grow a motivated and capable team. Because coaches operate without the rank of a people-manager, changes can be deep cultural changes (if we use the definition of culture to be “what happens when no-one is looking”). The general focus you might expect from an agile coach is one of delivering value quickly and incrementally, failing often and cheaply, learning quickly, working creatively, collaboratively and transparently. With an experienced and capable agile coach or scrum master, you would also expect the capability and delivery of your team to measurably improve – something you may not expect from a Project Manager. That’s all well and good, but there are things you expect of a Project Manager that no one seems to be doing…

You want a Project plan

There are two separate points here, the first about Projects and the second around plans.

A Project can perhaps be considered a resource bucket (time/cost/quality/scope) which work takes place within. The “agile” way of thinking involves considering not fixed time Projects, but rather continually living Products. Instead of having the wrong thing delivered late and over budget, instead agile relies on the ability to have transparency and change direction quickly, resulting in less wasted time, money and effort. Despite what some evangelists may say, I’d argue there is no inherent problem with constructing things as projects, though it may be slightly misleading in that it can create an expectation that the product development will be “done”. There is often new work to do to make the customer happy and to remain competitive, and it’s fine to spin those up as new Projects or as new Product Epics. The language matters, but perhaps is not as important as the underlying sentiment of iteratively satisfying or delighting the customer. If the format of Projects works better for your business, keep with it, though please do try to make the projects small.

When thinking about plans, I find it helpful to think about what we are trying to achieve through having a plan. Often the thing executives want from a plan is transparency and dependability. As people-centric agile practitioners, we want to help provide what you (and the business) need. There are a few well established techniques for achieving this that are part of the standard agile toolkit, for example using story points, and articulating outcomes through a Product Roadmap. Arguably the smartest planning techniques rely on lean (from Toyota Production System), and more recently Monte Carlo simulations. It takes a while to implement lean forecasting, since the usefulness of any of these measures relies on having a reasonable amount of historical data to work with. For this data to be meaningful, it needs to be the same team, similar work, etc. As a rule of thumb, I’d say 3 months is possible, provided the team are stable and get good at breaking things down small (which gives even more data points). The required time depends on how variable the team’s work is, and additionally requires someone like a coach, scrum master or project manager to help support the team, Product Owner, and/or Business Analyst breaking down of work into small chunks. For a plan, we also need to know and articulate what we want to do and why, even if it is just a best guess. In my experience, it is helpful to have one person deciding what-to-do-in-what-order, and they are likely to naturally lead the planning efforts with the support of a Scrum Master or Agile Coach.

From any of these we can get a visual way to show historical and expected progress, with an understanding that we encourage change if it helps deliver more value. “Plans are useless but planning is indispensable” and “No battle was ever won according to plan, but no battle was ever one without one” come to mind. A final message to the executive reading: If you are open to trying new ideas of what plans look like, that is great!


 

Why doesn’t this article mention “sprints” or “velocity”?

Sprints (the idea of delivering a fixed scope over a short time) is a metaphor taken from Scrum, a very popular agile framework. Scrum is one of many agile frameworks, and an agile coach is often not constrained by approach, technique or framework. As such, nor is this article.

Velocity is another idea often implemented in Scrum environments, which is “Average Story Points completed per Sprint”. Often this is used for planning, though for some technical reasons I personally prefer not to use this in most cases. I recommend lean and customer-focused metrics for performance self-assessment and future planning.

 

 

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…

 

Life lessons from chickens

It’s no secret I keep chickens. I find this thoroughly rewarding, as not only are they lovely primordial creatures, but with some love and care will endow a supply of tasty eggs for around the same price as supermarket eggs.

chickens2.jpg
A bird’s-eye view

Chickens are very odd creatures, and one cold morning recently I wondered what (if any) life lessons we might be able to learn from them. Given how many millennia chickens have been around humans, it is no surprise that we have many sayings involving chickens.Some of my favourites:

– “It is better to be the head of chicken than the rear end of an ox” – Japanese Proverb

– “Business is never so healthy as when, like a chicken, it must do a certain amount of scratching for what it gets” – Henry Ford

– “A hen is only an egg’s way of making another egg.” – Samuel Butler

– “The key to everything is patience. You get the chicken by hatching the egg, not by smashing it.”

– “Don’t count your chickens before they hatch”

– “Don’t put all your eggs in one basket”

There is some hilarious truth in many of these statements, in an divination or i-ching way perhaps considering chickens can help us reflect on our own decisions. After all, why did the chicken cross the road?

img_20161011_165954
Still scared

More than these amusing proverbs, chickens fear change. It takes months for them to get used to eating out of a human’s hand, and they scatter very easily (hence the playground speak for scared, “are you chicken?”). In this way, they seem to be very similar to people. A quick google of “people fear change” leads to 223 million pages.

A famous study on “Framing” by behavioural economists Daniel Kahneman and Amos Tversky suggests that our loss aversion (desire to minimise perceived change) almost always altered our choices even when the other choice was identical. David McRaney summarised the study nicely:

Imagine the apocalypse is upon you. Some terrible disease was unleashed in an attempt to cure male pattern baldness. The human population has been reduced to 600 people. Everyone is likely to die without help. As one of the last survivors you meet a scientist who believes he has found a cure, but he isn’t sure. He has two versions and can’t bear to choose between them. His scientific estimates are exact, but he leaves the choice up to you. Cure A is guaranteed to save exactly 200 people. Cure B has a 1/3 probability of saving 600, but a 2/3 probability of saving no one. The fate of hairlines and future generations is in your hands. Which do you pick? Ok, mark your answer and let’s reimagine the scenario. Same setup, everyone is going to die without a cure, but this time if you use Cure C it is certain exactly 400 people will die. Cure D has a 1/3 probability of killing no one, but a 2/3 probability killing 600. Which one?

Most people chose Cure A in the first scenario and Cure D in the second, but both situations presented are actually the same with different framing. The results showed how humans choose the option that minimises loss: the one with the least perceived change. According to lifehacker, because we’re so opposed to inciting change, logic can go right out the window.

By being aware of this bias, perhaps we can avoid the perils of “being a chicken”.

 

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…

 

Agile outside of IT

The Agile Manifesto was created for software development, but there are many lessons we can use outside of IT. This is not to say I think we should “be Agile” in everything.

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Individuals and interactions over processes and tools

Careers such as counselling and caring are starting to do this more. There is more of a focus on patient-centred leadership. In Nordic countries, there is a great company with 19,000 employees called Attendo, which focuses on empowering the individual in order that:

  • Every individual feels participatory and listened to.
  • Every individual feels they are met with respect and warmth.
  • Every individual feels supported in achieving independence.
  • Every individual feels safe and secure.
  • Every individual perceives that their quality of life is positively affected.

Sound familiar? For any creative workers, this is great for autonomous motivation.

Working software over comprehensive documentation

This one is only literally applicable to software, but the focus on value delivery is relevant as part of Lean Startup, for example. This is a way of running startups to help them be successful and less wasteful. Also notably, the value focus of agile can be seen in manufacturing (eg lean, kanban).

Customer collaboration over contract negotiation

Again Lean Startup advocates this. Big companies are trying to do this more too. For example, Diagio (the drinks company) have a “Customer Collaboration Centre” where they involve customers in their strategies.

Responding to change over following a plan

This area is one where I feel there is a lot of benefit. The world still works on a plan-based mechanism. We vote our governments in for fixed lengths of time, we demand financial plans, and we expect deadlines to be delivered to. Psychologically, embracing change can be hard. According to this random website I found, there are benefits of responding to change:

  • Staying current
  • New opportunities
  • Encouraging Innovation
  • Increased efficiency
  • Improved attitudes

The reality is that everything that survives must respond to changing environment. (Human) evolution is a great example of this. Medicine has always been “inspect and adapt”. Even the most conservative of organisations, the Vatican, responds to change, as demonstrated by their use of new latin translations during Mass. McCain Food, as one of innumerate corporate examples, responded to changing customer (and legislative) demands for healthier food by using sunflower oil, rather than vegetable oil. Creating a culture where we respond to change over following a plan will lead to better outcomes in almost any space.

If you can think of something where following a plan makes more sense than responding to change, or any other good counterexamples, please let me know in the comments below.

 

Proof: Little’s Law (why to Limit WIP)

Little’s Law states that:

The average number of customers in a queuing system = ( the rate at which customers enter the system ) x (the average time spent in the system)

Typically this might be applied to things like shoppers in a supermarket, but here we will focus on the application to software development. In a software development world, we often write it the same statement with different words, thinking about tasks:

Average Work in Progress = Average Throughput x Average Leadtime

Little’s law is beautifully general. It is “not influenced by the arrival process distribution, the service distribution, the service order, or practically anything else”[1]. This almost makes it self-evident, and since it is a mathematical theorem perhaps this is correct, since it is true in and of itself. Despite being so simple to describe, the simplest generalised proof that I have been able to find (and which we will not tackle here) is however trickier, since a solid grasp on limits and infinitesimals is required. Instead, we will consider a restricted case, suitable for most practical and management purposes, which is the same equation, with the condition that every task starts and finishes within the same finite time window. The mathematical way of saying this is that the system is empty at time t = 0 and time t = T, where 0<T<∞. A diagram to show this system might look something like this:

wip
Tasks all starting and finishing between t=0 and t=T

Proof

For our proof, we start with some definitions

n(t) = the number of items in the system at time t

N = the number of items that arrive between t = 0 and t = T

λ = the average arrival rate of items between t = 0 and t = T. The arrival rate is equal to the departure rate (sometimes called throughput), since the system is empty at the beginning and the end.

L = the average number of items in the system between t = 0 and t = T. This is sometimes called “average Work in Progress (WIP)”

W = the average time items spend in the system between t = 0 and t = T. This is called W as a shorthand for wait time, but in software development we might call this leadtime

A = area under n(t) between t = 0 and t =T. This is the sum of all the time every item has spent queuing.

Using this notation, Little’s law becomes

L = λ x W

which we will prove now. The following equations can be assembled from these definitions. We will need to use these to assemble Little’s Law.

  1. L = A/T (average number of items in the system = sum of time spent / total time)
  2. λ = N/T (average arrival rate = total number of items / total time, since every item leaves before t=T)
  3. W = A/N (average time in system = sum of all time spent / number of items)

We can now use these three equations to prove Little’s Law:

L = A/T                                                from (1)  

   = (A/T)x(N/N)                                since N/N = 1

   = (N/T)x(A/N)                                 by rearranging fractions

   = λ x W                                             from (2) and (3)

This is what we wanted, so the proof is complete.

What does this mean?

A trick to getting good outcomes from Little’s Law is understanding which system we want to understand.

If we consider our queuing system to be our software development team, our system is requirements coming in, then being worked on and finished. In this case, W is the development time, and each item is a feature or bug fix, say.

To have a quicker time to market, and to be able to respond to change more quickly, we would love for our so-called “cycle time” W to be lower. If the number of new features coming into our system is the same, then we can achieve that by lowering L, the average work in progress. This is part of why Kanban advocates “limiting work in progress”.

Alternatively, we can consider our queuing system to be the whole software requirement generation, delivery, testing and deployment cycle. In this case, we might have W being the time taken between a customer needing a software feature to it being used by them. By measuring this, we get a true picture of time to market (our new W, which is true measure of “lead time”), and we with some additional measurements we would be able to discover the true cost of the time spent delivering the feature (since our new A is means total time invested).

Outside of the development side of software, we can apply Little’s Law to support tickets. We can, for example, state how long a customer will on average have to wait for their query to be closed, by looking at the arrival rate of tickets and the number of items in the system. If there are on average 10 items in the queue and items arrive at 5 per hour, the average wait time will be 2 hours, since the rearrangement of Little’s Law to  L/λ = W gives us 10 / 5 = 2.

I hope that was interesting, if you would like me to explain the proof in the general case, let me know in the comments. I think it would be about 10 pages for me to explain, so in the spirit of lean I will only do this if there is a demand for it.