Following on from recent international experience, I will be speaking at Agile Manchester on “How to make multicultural agility work“.
The blurb: “People are different, and when you add country and culture into the mix, a complicated collaboration problem becomes even more complex. In order to lead an organisational change, you need to understand how different cultures behave and work. Whilst agile has many prescribed methodologies, such as scrum, things need to be tweaked: It’s not one size-fits-all.
In this session, I will share my recent experience of working with teams in Poland and Iceland, across retail, betting and shipping technology industries.”
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. 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”
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.
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.
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.
This year, being the first year of Fuza’s operation, has seen a lot of change. Especially as December marks not only the end of the calendar year, but also Fuza’s financial year, I thought it would be a good time to reflect on the past course and future direction. Some key features of this year:
Guy starting work full time
Fulfilling 3 successful contracts, delivering great value
Being happier overall, running and cycling more than ever
Maintained resilience in tougher times, where it was compelling to take an “easier” course
Continued to act in the interest of customers over Fuza, despite commercial pressures
Turned a respectable profit, enough to confirm Fuza as a good idea
Built, and was able to spend time maintaining, excellent relationships
Ticked some things off my bucket list:
Visited the battlefield at Austerlitz
Built a PC
Learned lots. The key things that come to mind are:
The importance of maintaining a work pipeline
The difficulty of engaging small businesses with the benefit of mathematics
I would like to take this opportunity to thank you all for your continued support, particularly those of you who have given me your time to provide contacts, feedback and even contracts. You have all really helped: not just to have the courage to take the plunge, but to make this year fulfilling.
In the coming year, I am intending to refocus Fuza around the mathematics and science of agile, and establishing the groundwork for success in that area. This includes topics such as Lean, data driven decisions (especially regarding decisions around people), and the thoughtful application of neuroscience and psychology directly to agile toolkits.
In January, Fuza will be continuing the exciting work as part of a contract with Tesco Supply Chain.
From February, Guy will be joining the team at Waters in Wilmslow, in an agile evangelist capacity. As part of this, he’ll be getting out and about in the agile community in Manchester.
Alongside this, Guy will be continuing his commitments as a Councillor of the Institute of Mathematics and its Applications. Highlights are expected to include helping to organise the IMA Strategy Review, and stepping up to write Council Reflections for Mathematics Today.
Finally, the personal side of these decisions will inevitably bring some substantial changes, not least the move of my business (and my family) to Manchester in February. I also hope to be ticking more things off my bucket list..!
Thank you all for your continued support and I look forward to sharing more of this journey with you!
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.
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?
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?
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?
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.
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…
Whilst I could share my learnings about biomarkers for personalised medicine, which makes a lot of sense and I do believe it will help the world, instead I will focus on climate change. It was aimed at a more advanced audience and had some excellent content, thanks Stephan Lewandowski!
There are a few key messages I’d like to share.
Climate is different to weather
This is worth being clear on: climate is weather over a relatively long period of time. Weather stations very near to one another can have very different (temperature) readings over time. Rather than looking at the absolute value, if you instead look at the changes in temperature you will be able to find correlations. It is these that give us graphs such as:
Given any time series of climate, it is possible to find local places where the absolute temperate trend goes down, particularly if you can pick the time window.
Interestingly, Stephan’s research has showed that belief in other conspiracy theories, such as that the FBI was responsible for the assassination of Martin Luther King, Jr., was associated with being more likely to endorse climate change denial. Presumably(?) this effect is related to Confirmation Bias. If you’re interested in learning more, take a look at the Debunking Handbook.
Prediction is different to projection
According to Stephan, most climate change models are projections. That is, they use the historical data to project forward what is likely to happen. There are also some climate change models which are predictions, in that they are physics models which take the latest physical inputs and use them to predict future climate. These are often much more complex…
Climate change is hard to forecast
I hadn’t appreciated also how difficult to forecast El Niño is. El Niño is warming of the eastern tropical Pacific Ocean, the opposite (cooling) effect being called La Niña. Reliable estimates for El Nino are available around 6 months away, which given the huge changes that happen as a result I find astonishing. The immediate consequences are pretty severe:
As you can see from the above infographic, it turns out that El Niño massively influences global temperatures. Scientists are trying to work out if there is a link between this and climate change (eg in Nature). Given how challenging this one section of global climate is, it is no wonder that global climate change is extremely difficult to forecast. Understanding this seems key to understanding how the climate is changing.
In any case, our climate matters. In as little as 30 years (2047), we could be experiencing climatically extreme weather. Unfortunately since CO2 takes a relatively long time to be removed from the atmosphere, even if we stopping emitting CO2 today we would still have these extreme events by 2069. Basically, I think we need new tech.
In a previous post, several months ago, we talked about Chaos and the Mandelbrot Set: an innovation brought about by the advent of computers.
In this post, we’ll talk about a present-day innovation that is promising similar levels of disruption: Open Data.
Open Data is data that is, well, open, in the sense that it is accessible and usable by anyone. More precisely, the Open Definition states:
A piece of data is open if anyone is free to use, reuse, and redistribute it – subject only, at most, to the requirement to attribute and/or share-alike
The point of this post is to share some of the cool resources I’ve found, so the reader can take a look for themselves. In a subsequent post, I’ll be sharing some of the insights I’ve found by looking at a small portion of this data. Others are doing lots of cool things too, especially visualisations such as those found on http://www.informationisbeautiful.net/ and https://www.reddit.com/r/dataisbeautiful/.
One of my go-to’s is data.gov.uk. This includes lots of government-level data, of varying quality. By quality, I mean usability and usefulness. For example, a lat-long might be useful for some things, a postcode or address for other things, or an administrative boundary for yet others. This means it can be very hard to “join” the data together, as the way they store something like “location” is many different ways. I often find myself using intermediate tables that map lat-long into postcodes etc., which takes time and effort (and lines of code).
Another nice meta-source of datasets is Reddit, especially the datasets subreddit. There is a huge variety of data there, and people happy to chat about it.
For sample datasets, I use the ones that come with R, listed here. The big advantage with these is they are neat and tidy, so they don’t have missing values etc and are nicely formatted. This makes them very easy to work with. These are ideal for trying out new techniques, and are often used in worked examples of methods which can be found online.
Similarly useful are the kaggle datasets, which cover loads of things from US election polls to video games sales. If you are inclined they have competitions which can help structure your exploration.
A particularly awesome thing if you’re into social data is the European Social Survey. This dataset is collected through a sampled survey across Europe, and is well established. It is conducted every 2 years, since 2002, and contains loads of cool stuff from TV watching habits to whether people voted. It is very wide (ie lots of different things) and reasonably long (around 170,000 respondents), so great fun to play with. They also have a quick analysis tool online so you can do some quick playing without downloading the dataset (it does require signing up by email for a free login).
Why is Open Data disruptive?
Thinking back to the start of the “information age”, the bottleneck was processing. Those with fast computers had the ability to do stuff noone else could do. Technology has made it possible for many people to get access to substantial processing power for very cheap.
Today the bottleneck is access to data. Google is making their business around mastering the world’s data. Facebook and twitter are able to exist precisely because they (in some sense) own data. By making data open, we start to be able to do really cool stuff, joining together seemingly different things and empowering anyone interested. Not only this, but in the public sector, open data means citizens can better hold government officials to account: no bad thing. There is a more polished sales pitch on why open data matters at the Open Data Institute (and they also do some cool stuff supporting Open Data businesses).
Some dodgy stuff
There are obviously concerns around sharing personal data. Deepmind, essentially a branch of Google at this point, has very suspect access to unanonymised patient data. Google also recently changed the rules, making internet browsing personally identifiable:
We may combine personal information from one service with information, including personal information, from other Google services – for example to make it easier to share things with people you know. Depending on your account settings, your activity on other sites and apps may be associated with your personal information in order to improve Google’s services and the ads delivered by Google.
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.
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:
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.