The A-Ruminations team discuss the Utility of “Spanners In The Works” and analyse the advantages and pitfalls they bring.
Category Archives: Learning
006 The Five Whys
Tobbe and Kim Discuss “The Five Whys” and the assumptions we make about them.
OBSERVATIONS IN HOW THINGS GO 2
As a society based in the post Industrial revolution, where productivity and maximising profit rule the landscape and dictate our daily lives. We strive for “Efficiency” in our work lives and even our daily lives and many of us never really think about what we’re doing and the costs of our search for better, faster, more!
Efficiency vs Expediency.
Years ago I was developing a database, the demands placed upon the database were simplistic and basic. In essence it was a list, used to check the availability and validity of numbers. The idea was to wash a random bucket of numbers to see if they fit the criteria set by the customer. These numbers could have easily simply occupied a simplistic table format and been fine. The customer would have been happy and content yet, I found the basic minimal number of columns, data points inappropriate for the customers future needs.
Yes, I opted for Efficiency over Expediency. The reason was I have a scientific background and we never throw anything out, especially data. The data is only as good as your mindfulness and awareness while collecting it. Many a scientific study has suffered and been less important because basic and minor data was not collected during the experiment. In science I would never disregard any data which may be needed later. Anticipating future data needs and possible uses, is key to Efficiency.
So I was predisposed to put myself in the customers shoes and try and anticipate possible future data requirements. The upshot of this was that for very little extra effort, an extra few columns and a few extra lines of code; the customer could benefit from future data mining and analysis.
The effort required to develop the database was the same !
So why do we choose Expediency over actual Efficiency ?
The daily activity of trying to finish our work items steers us towards Rapid Solutions which seem Efficient; yet this very Expediency often costs many times more with rework, rebuilds and even the complete redevelopment when parameters shift as future needs become apparent.
The old saying “A stitch in time, saves nine” springs to mind. The mindfulness and mending of a small tear prevents the need for major reworking and effort.
So next time, ask yourself is this done for Expediency or actual Efficiency, and hopefully we can get a head of the curve and put our future efforts into better things than Rework.
The way I see this is that most of us try to do the best we can but a few remind me of the Ferreters of old who would let go any pregnant female rabbits so they would get work next year, to reduce the rabbit population.
Expediency has become our efficiency.
Agile is like using a Chef’s Knife…
Agile has been described as a change in mindset, which is a tricky concept to explain and even trickier to do.
What if agile is additive instead?
Here’s an analogy.
If we only had a butter knife in our kitchen, there would be some tasks that we can do very well, such as spread butter and jam on bread. Imagine if we wanted to chop up tomatoes. The tomatoes would be in very big chunks and it would be very messy with a lot of waste.
Then we discover the chef’s knife and learn how to use it. Now we can chop tomatoes (and other things) with a lot more precision and much less waste.
We do not get rid of our butter knife though (I imagine that trying to spread butter on soft bread with a chef’s knife will result in a very torn and unpalatable result).
Now we can do many more tasks in the kitchen, using the tool that is best suited for the job and the main changes we have made is to purchase the chef’s knife and learn how to use it properly – which is a case of ‘both/and’ not ‘instead of’.
The 12th State of Agile report from VersionOne has just been released, below is some data from the 11th (2017) report about the challenges experienced adopting and scaling agile.
Source: VersionOne 11th annual State of Agile report
Back to our chef’s knife analogy – it would be unwise of us to purchase one and start waving it around – they can be quite hefty and very sharp things. If used inappropriately, they can be very dangerous. We need to start slowly and learn how to use it until our muscle memory kicks in and then we can go a bit faster.
It’s the same with learning new ways of working – we need to know when it’s appropriate to use them and be careful that we don’t cause unintended damage as we build our ‘muscle memory’ and get used to the new practices, principles and techniques.
It’s interesting in the state of agile report data above that 2 factors appear that we can address in fairly obvious ways with training, coaching and deliberate practice.
- Lack of experience with agile methods (47%)
- Insufficient training (34%)
The remaining 10 factors have a lot more complexity and uncertainty to them and will be much trickier to influence.
If we stop thinking of agile as a change in mindset and see it instead as learning a new set of tools, perhaps that would help us to focus on the 2 factors above and reduce the impact of the other 10 at the same time.
It’s nice to get new things – and even nicer when we can still find uses for those items we have grown to love (like a favourite butter knife).
Agile Australia 2017
Melissa Perri at Agile Australia 2017
It’s been two weeks since the Agile Australia 2017 conference in Sydney, it was great to see so many people there and the quality of speakers was very high. Here are a few snippets from the conference.
Melissa Perri spoke about ‘The Build Trap’ and how it is easy to get very good at writing specifications and stories, which is the ‘build trap’. There is more value in understanding the true needs of the Customers and building to those needs. Melissa also had a great way to explain the difference between Product Manager and Product Owner ‘Product Owner is a role you play on a Scrum team. Product Manager is the job’
Sami Honkonen showed us how the Cynefin Framework is one of the building blocks of a Responsive Organisation – it helps us understand why Agile works in a complex adaptive system. Sami also talked about how structure drives behaviour and that it’s not the individuals, but the structure that they are in. I have also found the concept from Sami about designing very small experiments (ones that can be done in minutes) very useful.
Chris Chan at Agile Australia Lightning Talks – ‘Pirate Metrics’
The lightning talks were little nuggets of knowledge and very well attended. The picture above is from the ‘Pirate Metrics’ talk by Chris Chan – his way of explaining AARRR using examples of Pirates going into a bar is engaging. For example – Referrals – one Pirate saying to another ‘Arrr – you should try out this bar, it’s good’
The Deep Dive sessions with the keynote speakers were a bonus – Agile Australia has started doing this in the last couple of years. These give us the opportunity to learn more from the speakers, especially when they cover such interesting and useful items in their keynotes, that leaves us wanting more details.
Complex in Hindsight
When we reflect on a complex event, it often looks predictable in hindsight and this makes it harder to deal with complexity in the future. This post is about complexity in the Cynefin sense – where it is not possible to see linkages between events beforehand – but it is possible to see those linkages afterwards.
The two Cynefin domains that have high certainty are called Complicated and Obvious. The complex events that happened in the past – look like they belong in these domains – when facilitating sessions with people and asking if the past events were predictable, they will often say that they were. It is a good idea to double-check that this is the case – ‘are you saying they were predictable with your benefit of hindsight? Or if we went back in time, is it really an unpredictable set of linkages?’
It is useful to take examples of past events and create a Cynefin Framework from them in order to create a shared understanding among a group of people. The Cognitive Edge Method to do this is called 4-points or 4-tables contextualisation. Once the Cynefin Framework has been created, the labels on the groupings of events become very useful in the future. The group can then say that an upcoming event is like one in the framework, and if it is in the Complex Domain, use an exploratory approach rather than a project management method more suited to the Complicated Domain.
The main ‘gotcha’ with using historical events is this one – that the complex ones do not appear complex in hindsight – so be careful when facilitating that this is not a factor – otherwise, the Cynefin Framework created will have more examples of high-certainty events than actually exist in the environment.
FEEDBACK, DESIGNED BY COMMITTEE, FRIEND OR FOE
In the modern world, with its sense of image, popularity polls and populous mantra; a more primitive relative may observe this behaviour and trend as wishy-washy and indecisive.
Think about the general trend that has become common place, talent shows like Idol, X factor, Voice; shows like Big Brother where people are voted out. Can you say Bah! We follow like sheep, chasing the populous’s approval, hoping it will lead to our goals of increased sales, profit, reduction of wasteful spending.
These shows are a sign of the times, we want to know our profitability before we even start building. Even when built we do trials to tweak or discard prototypes. Feedback has become the double edged sword that can destroy an otherwise perfectly good idea or “hone it to perfection”. All heavily skewed by general knowledge, biases and experiences of the sampled group, dangerous territory for a cutting edge, revolutionary concept or product. The old axiom “the customer doesn’t know what they want, until they see it”, springs to mind.
For the known domain, where the type of product is well established and only slight variation, in either packaging or product is the goal then feedback is definitely the path forward. All the variables are well known or they follow well defined parameters. In this environment feedback enhances, tweaks and maximises but what about more unknown or unexplored environments? What about original thought?
In these more abstract, uncertain, unknown and unexplored conditions experimentation not feedback is the only true viable option.
Let me clarify. Feedback in this context does not include the information gathered by the investigative experimentation from analysis; even though technically results are a type of feedback.
Feedback is considered here as the third party opinions often collected and given even when not asked for. The designed by committee, too many cooks and option paralysis scenarios, most of us have felt it; when the process becomes too process heavy, that forward movement is but an illusion. The end result is often frustration, depression and often listlessness, we are emotionally like sharks and require forward movement to maintain our happiness.
This double edged sword, feedback is seen, even in our everyday lives, in the auto correct functions of word processors, the GPS navigational aids, calculators and even in programming tools to aid the programer. They all have their place and offer improvements in efficiency, yet they also take and undermine.
How many of us have checked to see that auto correct has “corrected” our spelling in an inappropriate manner, hopefully we catch it before we hit the send button.
Calculators are a useful tool, yet we have reduced or lost the ability to do mental arithmetic, in the pursuit for a rapid answer. People now days find it difficult to mentally estimate the total of their shopping, to see if they have enough money to cover it. Without a calculator the modern world stops.
Programming tools are a valuable tool and offer feedback upon our coding options and are often relied upon, for increased speed and guidance. The problem is that it can become a crutch, undermining and slowing the development of coding proficiency. The easy answer given by tools such as this, tempt us into a false sense of ability and takes from us the opportunities of discovering our own techniques and understanding of the code.
My personal favourite would have to be GPS navigation, I hate this one and therefore don’t have it. The course is plotted and locked into your Nav computer and you prefer to do something different, maybe you don’t like U-turns, it’s a very busy intersection, whatever the case, the GPS get almost annoyed offering recalculations again and again, demanding you comply. Then the pinnacle of folly, drivers that drive off cliffs etc by blindly following their GPS tools.
The reliance upon the feedback, given by an ever increasing number of auto correctional tools has resulted in a stifling of human ability for self analysis. The fundamental flaw with feedback mechanisms is that they often suffer from a static and fixed reference point. The coding tools can only give you the options its developers knew. The GPS navigation is only as accurate as its data and does not know your emotional state or wether you hate U turns, you the driver should be in positive control of your vehicle at all times and not defer part of the responsibility to a disembodied voice.
Feedback should never be the sword used to control or influence our direction or outcome, it’s a guide a sounding board. It should be part of the equation but never the solution.
Designed by committee, how many times have we all suffered through this and option paralysis. It all starts as a good idea if we can get a sense of what is required or in what direction we should head, then things will become clear and we will have a greater chance of success. The irony is that when we defer control to external influences we often lose our way. The reason for this is basic, we’re all different so what others may suggest usually doesn’t gel for us.
Feedback should be a guide, a navigational aid for our endeavours.
Unintended or invisible consequences
Have you ever tried to do a nice thing that went completely pear shaped ?
Have you ever said something that was taken out of context ?
These are the unforeseen consequences, that surround us every day of our lives. The basic fact is that every interaction is open to misinterpretation. Sounds absurd but I propose it’s painfully true. The fact no one can read your mind or understand precisely what you mean is founded in the variety of life experiences we all have. We all have a “mental rule book” that we inherit/adapt/devise as we live our lives, moulded by our experiences and more importantly, our interpretation and responses to them.
Management and the unintended and invisible consequences
We are a modern culture of goal driven and result focused beings, rushing towards completion. The result is that there is entry level and management and the erosion of the middle.
The loss of the middle
The rush to completion culture, that is modern life, results in an erosion of the middle. Think about it, there is a devaluing and almost loss reflected by the middle layers of our work place and lives. This doesn’t mean that the middle layers don’t exist anymore because they do and if anything there are more of them. What has happened is the middle has expanded all while an erosion of its substance/quality has occurred. The middle has become a waiting room with no intrinsic value, just a place on the way to somewhere else. We are all trying to be/get somewhere else and therefore are focused forward and not in the present. It’s like people who are so busy, thinking of the next thing say, that they actually aren’t listening. They are actually, just frantically scanning /searching for the next sound bite to hang their comments upon. This type of hollowness is symptomatic of the erosion of the middle. This layer has become what I call “fluff” taking up a lot of room but with no real substance. The term busy work, tends to be made for this middle layer. So why has this happened?
Apprentice easy to learn hard to master
I remember buying a backgammon set when I was very young which had an instruction booklet with it. The instructions/rules were rather simple but it ended with this statement “easy to learn but hard to master” this line always resonated with me because I was a moratore’s son and knew that most things are easy to learn but really hard to master. The mastery of a skilled task takes time, time to encounter all possibilities and time to develop responses and reactions to them.
How many of us have learnt things, passed the exams and only years later, does the penny, actualy drop? Only then do we see for the first time what the concepts heart or the true nature of the knowledge was. Maths is littered with these sort of realisations, trigonometry is one.
I remember being told by a professor at university, when I was demonstrating and discussing with him how we learn and teach. He replied you only really learn something when you have to teach it, when you first learn anything, it is really just a getting to know you exercise, like a first date. This introduction allows you to pass an examine but really only superficially introduces you to the concepts involved. This initial exposure familiarises you with specific terms and basic concepts, so when you actually need to know and teach that lesson you can find the solution more easily and make it part of you.
The act of learning is greatly enhanced by teaching, why? The answer is simplicity itself. Everyone sees and exists in the world differently, these differences mean that when you learn something and try to understand it, you frame it in familiar and logical steps, for you anyway. When others try to learn and understand the same lesson they will also try to make sense of it according to their life view and understandings. So it’s obvious that when teaching you will find a continuum of how others perceive and try to understand the lesson. Some will think very much like yourself, others slightly differently and still others will need vastly different points of reference to come to terms with and understand the lesson. Good teachers must and can rephrase and explain things in a variety of ways, this necessity is what makes teaching the best way to learn because it stretches us to examine what we “know” from other perspectives and points of view.
The unforeseen consequence of teaching is you learn much more completely. This takes time and understanding.
So why do we rush to “completion” ?
Our modern culture is densely populated with 5 year plans, strategies, expectations, milestones and the list goes on and on. Every minute of every day in our lives is under constant scrutiny both internally and externally. We must develop and attain certain milestones within culturally expected time frames or we seem to be ineffectual or below the curve.
There is no room or time for mastery, we learn and we move on. The modern view is that “the now” is only a stepping stone to a future goal. The worth of the journey seems lost to us and only the allure of promotion and success is our goal. We have become tradesmen, with no patience or will to develop into master craftsmen. Society accepts the passable, to feed instant gratification and speed. The respect and value of craftsmanship and quality has become subservient to efficiency and greed. The attention span of the modern world is framed by sound bites and popularity poles.
Bread and Circus rule the day, with distractions and being seen as cutting edge, objectives in themselves.
Think about your workplace, how many times do we heard “they’ve been in that dead end job for years”, “they have no ambition” these statements maybe true but only partially so. The fact maybe that the worker derives get pleasure and satisfaction in developing their skills beyond acceptable and into the realm of mastery. Yet we don’t acknowledge this, we only see the same person in the same role, and evaluate this as “what is wrong with them?”
The absolute irony I noted while I was working IT, no matter how expert and skilled the programers were they were never “appreciated” as much as management. In fact it was sad to watch true masters of coding, having to become management so they could earn more money and get some appreciation. The actual engine which kept the company in business was devalued because they were content applying their craft. The ironic topper to this observation, was that graduates who had studied coding, just used coding to get a foot into a company, so they could quickly move into the management streams. Does the saying “too many Chiefs and not enough Indians”, spring to mind.
Words of wisdom from my father an old muratore “It takes hardly any extra effort to do a good job than a bad one.” This is very true, when you actually think about it, how much time, effort and money has been flushed down the toilet by bad projects with little or nothing to show for it?
The unforeseen consequence of our modern society is we rush to our goals and loose sight of the reasons and real benefits why we started in the first place.
There seems to be a disconnect between the limbs and the governing body, the brain. The “new talent” needs mentors to help and aid learning of best practises, while the “wiser” and older ones need the vitality of youth to physically accomplish the task and encourage new exploration into possibilities.
Companies are run like the military, chain of command, need to know and follow orders. They should be run as a biological system or organism, where there are feedback systems with more than one way to elicit change, the nervous system for rapid responses (management) and the endocrine system for slower invasive moderation (cultural).
Discovery and Re-discovery
We’ve been discussing the concepts of ideation and the workshop activities that we do to generate ideas. These activities use the intent behind ‘brainstorming’ – not that I am recommending the common form, let me explain why.
The method that springs to mind when we mention ‘brainstorming’ is for a facilitator to capture ideas onto a whiteboard while people call them out. There are many issues with using the method in this way related to good old human nature such as our tendencies to focus on the first theme mentioned or our tendency to defer to people in positions of perceived higher status.
There are many better ways to generate ideas from design thinking and other facilitation approaches such as
- Silent brainstorming
- Rapid sketching
- Surfacing assumptions and generating hypotheses
What if we are working on a big, important goal? There are many questions that we overlook because it’s easy to make the assumption that once was enough and doing a process of discovery again might generate more work than we desire.
- Should we facilitate only one of these idea-generation sessions with one group of people?
- How can we know if we have looked at the goal from enough angles?
- If we should do it more than once, then how many times and how much time between the sessions?
Perhaps this is the original intent behind governance processes. We know that humans are very creative and are likely to learn much at the beginning of a piece of work that leads to more interesting ideas as we proceed. In an idealistic world, the process of governance is a way of checking in with a bunch of smart people to help us identify key decisions and make those decisions in a timely manner.
Those same smart people can also assist with identification of the needs to re-discover – perhaps they have learned something useful from elsewhere that could help us to reach our goal sooner or obtain better outcomes. This new information might be a reason to facilitate another ideation session – but how many of us would want to set that up? It seems much easier to take the new information and simply work it into our current set of tasks.
How can you tell and why should you revisit old ground?
Things change, information is not static and the believed facts can also change with time as a better understanding is developed.
So if we acknowledge this reality then the attitude that we should only plan, then act, denies the fact of change. Imagine a set and forget toy on a table, the inevitable outcome is that it will eventually fall off. This is the very reason why biology, engineering, mechanics and programming are full of feed back loops and reiterations, so monitoring and corrections can be made. It is naive to think our projects are somehow exempt from change.
The size, complexity, number of inter-dependencies all increase the requirements for re-discovery, so we should always be asking ourselves if it makes sense to continue, or to pause and do some form of re-discovery at regular intervals.
Validations and Feedback
‘How am I doing so far?’
What a loaded question… When we ask a question like this, are we seeking feedback, or are we seeking validation? Perhaps this is related to the fixed versus growth mindset.
With a fixed mindset, I would be seeking support to validate that I have been doing a great job and that I am considered a superstar.
With a growth mindset, I am truly open to feedback and want to understand how I could improve.
Of course, this then leads us to metrics and the question about how they could be used for feedback and how they might be used for validation.
Rainfall as a metric means that each day we check our rain gauge in the garden and note how many millimetres of rain have fallen in the last 24 hours. This is not feedback – I am fairly certain that the weather systems do not use measurements from our rain gauges to find ways to improve the weather. Instead it is a monitoring metric and we can use it to validate that the mud was slippery outside because we had a lot of rain.
Budgets and tracking the spend against budget looks like a great feedback metric – however, by itself, it is purely for validation. How many of us have been rightly happy that a piece of work we just completed met budget expectations? (Or rightly unhappy if we did not meet the budget expectations?) Remember those feelings for a moment – pride, relief, happiness – or regret, sadness, blame – these are not very helpful if we want to improve how we work and can distract us from seeing other opportunities if we are not careful.
Feedback is when we ask why and how. Back to the budget example, if we ask why we did not meet budget, without blame, we can find out a lot of useful information and opportunities to improve for next time. One of my favourite lean tools is the ‘5 whys‘ – it is fascinating what can be uncovered if we keep asking why (with polite respect, of course). In the case of budgets – it is just as useful to ask why we met as why we did not meet budget – learning what worked well is very useful for next time also.
Validation versus feedback might be one of the root issues with KPI’s – when we are set a target number, it is very tempting to do all that we can to meet that number and then breathe a sigh of relief when we finally meet or exceed it. How many of us have had truly useful conversations about how we did our work, what we learnt and how we can continue to improve in the era of KPI’s? Validation is a very tempting focus and can feel a lot like feedback – but it is hollow praise.
In summary,
- Validation is when we use metrics to show that we did a good job
- Feedback is when we ask why or how we got a result
Be careful which outcome we are seeking when selecting and discussing metrics.