Splitting, Refraction and Facets

 

Chatting with Steve and Tobbe – we were discussing refraction – light going into a prism and then splitting into a lovely rainbow. It is useful to slightly separate things and it can help us to clarify terminology.

A good example is the term Product Management – I was asked for a definition – so my first place of reference was ‘Escaping the Build Trap’ by Melissa Perri – with an excellent description of the role of a good product manager. This helped a lot – and when I looked into the situation a bit more, I realised that there was more to it. In conversations, not only did we start mixing together the terms Product Manager and Product Owner, but there was something else that was more than the role.

The landing point was to split it out into a few different facets; Profession, Role, Skills and Process – there could be other facets – these were the helpful ones for the recent conversations.

The Profession of Product Management grew from marketing and brand management and has evolved as organisations place more focus on Customer experience and the technology supporting that experience. In some places your career could take you through a range of product management roles all the way up to CPO – Chief Product Officer.

The Role of a Product Manager is to be able to articulate the ‘why’ of a product or feature so that the various teams can build the ‘what’. There is a lot more to it than this – but this is also where it is useful to split out the role from the skills and process facets.

The skills of Product Management need to be performed by many roles. There is the skill of stakeholder engagement to understand needs, goals and drivers. Being good at this skill means that the skill of prioritisation gets a bit easier. Then there are other skills such as data-driven decision making – all of us could use some of these skills in our work activities and we certainly should develop enough of these to be able to understand the outcomes we are aiming for (not just getting the bit of work done).

Product Management in Processes was a bit of a surprise when I noticed it. If we think about large organisations that allocate a certain percentage of time to innovation, this is an example of it. The organisation has prioritised innovation – allocated effort (which is time and therefore budget) with the outcome being to identify and develop new opportunities. The decision about the amount of time to dedicate and the level of priority is a product management decision that has been adopted as part of the regular planning and scheduling process. I’m certain that there are other aspects of product management that we could embed into processes and I will be looking for them.

I have previously blogged about the gradients of misinterpretation – those are still there, in this example there are gradients between one ‘end’ of the definition of Product Management and the other ‘end’. The point of this post is that is can be useful to put a definition through a ‘prism’ and split out some of its aspects or facets into discreet chunks.

“Need to Know Framework” derived from the PRISM

Trying to work out what you need to know and which information is most relevant at a particular time is like trying to hit a moving target. Not impossible but many factors play a role in the result. We all know that things change, yet we can fortify ourselves by becoming aware of which factors can impact us either directly or indirectly. Even factors out of our control can be planned for and risks mitigated.

The idea of a “Need to Know Framework” is actually an acknowledgement of how things used to be. The traditionally small groups of people working and existing together, organically gave rise to a sharing of information and knowledge, each person knew what the other person was doing and a network of awareness of the whole developed naturally. In the modern workplace the scale actually prevents the easy flow of information between indirectly but still connected groups. The recent ideas of tribes, regularly scheduled meeting and intranets etc. all are modern devices to try and replace the paradox of increasing isolation in larger groups.

So the only way forward is to begin at the level of the individual and instil a sense of “the Whole”. It is only when we appreciate the perspectives and requirements of others in the group that the greater good of “the Whole” moves forward. Some of the greatest advances in human history have only occurred when a discipline is examined from another perspective.

The need to understand the interconnections and dependancies that impact our tasks, is crucial to the understanding of the environment or “ecosystem” that our body of work will exist in over time.

It is essential for us to examine and determine which information and facts we will require. The resulting maturity that will develop, if we attain this perspective will be essential in helping us to reach our goals. The byproduct of striving to this end will be an increase in “Transparency” and a Need to Know Framework where each piece of information, can easily be prioritised into impact and according to our specific needs.

So how do can we get to this point?

Well it is only when we realise that just focusing on the immediate and specific task at hand, although seemingly efficient is actually detrimental to the ultimate whole. When any one thing is focused upon solely the result is always that the whole suffers. This does not mean that concentration on a particular task is bad but that any task no matter how small must and should be considered as part of a larger system. It doesn’t matter if your API is perfection, well coded, efficient and a masterpiece if it can not interact with its larger ecosystem.

So how do you generate a Need to Know Framework” ?

The inspiration for this comes from newtonian physics, in particular Refraction of light through a Prism.

Using the PRISM we can utilise the colours as indicators of the Importance, Directness and Impact of Information.

Centrally at Level 1 (RED) would be the direct and immediate information required for you to do the task, and the task only with little or no appreciation of where your task fits into the larger landscape. This is the equivalent of just in time management.

Next at Level 2 (ORANGE) is the knowledge required to perform your task and deliver it.

Level 3 (YELLOW) is information which helps you locate and position the task at hand, within a slightly broader framework. Such as knowing how it will impact and interact with its immediate neighbours or dependences.

Level 4 (GREEN) is information which is not usually considered required but when obtained frames and allows the project or task to comfortably sit within the broader landscape. This type of information aids in allowing you to grasp the interconnection between your task or project and those not directly involved, the first cousins to your work.

Level 5 (BLUE)  this level of information frames you task or project in the broader environment, with awareness of interconnection and nuance between the up stream and down stream relationships.

Level 6 (INDIGO) this level like the colour is between BLUE and VIOLET, the interconnection and interdependencies of all the tasks and projects, yours included and the information required to distill the over arching “5 Year Plan” or Vision..

Level 7 (VIOLET) this is the highest level of separation from your work, and as such is not often seen as essential or even required. Yet, it is the guidance under which all your tasks and projects have been organised to function within. This is the “5 Year Plan” or Vision developed from the Level 6 (INDIGO) information when evaluated and seen in the light of the company in the Global Economic and Social Ecosystems.

TRANSPARENCY; the Emperors New Clothes and You can’t handle the Truth

The very term Transparency as used in the modern world of Management and IT is at best ridiculous and at worst dangerous and an unsettling endeavour.

Harsh words but think about it; few of us could actually deal with knowing every detail about everyone or everything. The human animal has not evolved to store and process billions of bits of data and analyse them without bias or errors. The terms “Option Paralysis” or “Information Overload” spring to mind.

Despite our modern life styles, which are information saturated, we actually only skim or glance over the actual information by taking other people’s narratives as easily digestible chunks. The fact that, very few of us even try to understand the complexities of our own environment natural or man made, socially and biologically is testament to millions of years of evolution which has resulted in our ability to filter and categorise.

This same ability to group similarities and make inferences from them is the very same reason we find the simple task of analysing data, without bias very difficult.

We often extrapolate from only a few data points and behave as if the presented data is “True” because it supports our previously held beliefs. We even find the weight of truth behind an unsubstantiated and sample of one (statistically irrelevant) as highly engaging and important :-Anecdotes.

So is it any wonder why, as a general rule we find true Transparency difficult. We actually don’t want transparency; like the Emperor, once he realised he was naked, we feel exposed; naked for all to mock and find fault. So is it really Transparency that we crave or is it actually the ability to access the information that we need or may need to complete our tasks well and in a timely manner, without any foreseeable obstacles or errors.

So instead of Transparency we actually require a “Need to Know Framework” that would allow us to recognise and highlight important information in concentric layers of Impact and Importance from you the Epicentre. This framework would be derived from the PRISM – a topic for another blog.

How much Transparency?

The picture is an analogy about transparency – I want to see the person step out from behind the pillar – but I really do not want to see into them (their skeleton – or even worse, through their clothing). I’m also quite confident that other people do not want to expose such an extreme level of transparency.

So what is the ‘right’ level of transparency and why to we seek it?

I’m sitting in my lounge room and I can see out the window – it is a frictionless way for me to observe the front yard (through the transparent glass). If there was no window, I would need to go out the front door and walk around the corner to see the front yard – it requires effort and I would need to justify doing it.

At the risk of abusing the window analogy, perhaps what we mean by being transparent about things in the workplace is that we reduce the effort to find out and we also eliminate the need to justify why we want to know. It can be very useful and pleasant to observe things – we can feel happy seeing that the environment is as it should be – and we can take action when things are not ‘right’. If my cat starts to growl looking out the window – there is probably another cat in the front yard and I can choose to chase it away or not. If neither of us could see it (due to the lack of a transparent window in the wall), we would never have known the other cat was there and we would have lost the choice to act.

We need to be careful about where we seek transparency – I do not want my whole house to be made out of glass – and we have curtains over windows when we want privacy.

In the workplace, it would be great if we could see everything without any effort and justification – but it can feel very threatening. When we feel threatened, we want to protect ourselves – so reducing effort in one way (frictionless observation – transparency) can increase effort in another way (trying to close the curtains or cover up our skeletons).

Be careful what level of transparency we ask for – it can be a good thing, and just like other good things (such as water and oxygen), too much of it can cause damage.

What the Culture? Chicken or the Egg

Since the late 90’s and over the last decades we have been bombarded with buzz words, “hipster” ways of working and living etc. Our workplaces have undergone numerous changes in both managerial and social spheres, all under the banner of increased efficiency and improving the work environment. Yet regardless of what the goal is we often hear the term “Culture”.

So what is culture?

Culture is a pivotal concept in anthropology, which includes a range of phenomena that are transmitted through human societies by social learning.

Evident in the social behaviour and norms of human societies, culture is “the way of life” for groups of people which has been passed down through generations, often tightly linked and specific to the groups environment, history and even genetics (sickle cell anaemia). Their shared ideas, customs, procedures and their shared world view or perceptions.

In our modern lives, the most invasive and under-defined term used would have to be culture.

So why is this a problem?

The issue is that when most people use the term culture, they seem to regard it as a lever to effect change. The idea you can simply, enact new procedures and change the “Culture” of a company is flawed at best and potentially dangerous.

So why and how do people truly change?

Like evolution, Culture is the product of a change based in advantage. The better suited a species is to its environment, the more likely it will have an evolutionary advantage. Similarly Culture is gradually developed and evolved over time with the underlying driving force being an advantage, better social cohesion, support, robustness etc.

So if you wish to enable true and lasting changes such as “Culture” there must be a definite advantage. In the workplace this could be more pay, job security, better and clearly defined processes and therefore roles, better management and a greater sense of self worth in the companies landscape both socially and economically.

The idea that “culture” can be changed from the top down is doomed to failure because if the advantages of the changes are not obvious, why would anyone adopt them.

“What’s in it for me,” is the driving force behind all change, even Altruism. Without an advantage why would anyone change the way they do anything.

Culture is not a lever or process but the goal to attain an improvement and lasting change for the better which is reflected in the mechanisms we perform.

Culture can be a Vexing Word

This post has been inspired by a conversation about culture with Tobbe and Steve.

I was pondering why I have trouble with the word ‘Culture’ and it’s related to the ways we misinterpret words and misuse them to influence people.
So I tweeted a thread earlier this week which captures some of the problems

Culture can be a vexing word

In this context ‘vexing’ means causing annoyance, frustration or worry (from the google dictionary)

The word ‘Culture’ is annoying when used as a convenient excuse For example ‘the culture is not right here’ or ‘we need to change the culture’

The word ‘Culture’ is frustrating when we try to define it
‘We need to change the culture’
…..’What do you mean by culture?’
‘You know – how we do things around here’
…..’What things?’
‘How we communicate, interact, collaborate…’
……..

…..’What is collaboration?’

And the word ‘Culture’ is worrying because it can lead to rabbit holes, wild goose chases and cans of worms It’s far too easy to focus on activities attempting to change the culture directly (and these are very hard to measure – see previous tweet about definition)

It’s very easy to vent about an issue and a lot trickier to propose ways to address these issues.
The simplest first idea is to stop spending large amounts of time trying to define culture – sometimes it’s like…discussion about culture eats everything else…(with apologies to Drucker – although according to Quote Investigator the quote might not be directly from Drucker).

The next simple idea is to catch ourselves when we think ‘the culture needs to change….’ or similar and apply something like the 5 Whys to it.

  • Why do we think the culture needs to change? – Because people keep doing the same things and won’t try new ideas
  • Which same thing are we concerned about and why? – The funding process
  • Why is the funding process a problem? – Because we have to fill out timesheets
  • Why do we fill out timesheets? – So that we can be paid
  • Are there any other reasons why we need to fill in timesheets? – I don’t know
  • Who might know? – HR, Finance, Managers
  • Why is filling in timesheets a problem? – Because the codes are confusing and it takes around 15 mins a week when I could be doing more valuable work

We can see that the list of whys and who might know is getting very long and there are a lot of interesting and branching threads to explore. The timesheet one can be fairly simple to follow and it often ultimately relates to how an organisation does its accounts as well as allowing us to get paid properly. Accounting standards are fairly universal and are not going to change very quickly – so we are much better off educating ourselves about the need of the organisation to meet taxation, corporate governance, audit etc. requirements and finding more effective ways to achieve these as well as communicating this need with our colleagues.

We might find that a very measurable thing (that an organisation is a going concern in accounting speak) can have a dramatic impact on culture when we focus on flowing our work around that need.

Agile Governance

Or…How it is Difficult to Understand a Thing if you don’t Already Know the Key Thing

Governance is a word that throws me off – wondering what it really means.

It’s supposed to mean having clarified roles, accountability and responsibilities.
It means understanding how decisions get made and who makes them.
It means making sure that policies are in place and that processes are monitored to ensure that they are working as intended.

It’s tricky to explain governance in agile when people don’t already have a good grasp of governance in traditional organisational constructs.

It’s similar to when I was a new video editor and our organisation bought a fancy piece of equipment called an ADO – Ampex Digital Optics (It flew a small picture around the screen and cost over $100k AUD in the 1980’s/90’s…now you can do the same thing with free software).
We did not purchase the training reference materials and only had the operating manual – which kept stating to do this, that, or the other with a thing called a ‘keyframe’.
I had no idea what this keyframe thing was – and the glossary was not helpful – so I stressed and tried a few things – and eventually called another video editor who was more experienced and asked him.
He explained that in any movement from point A to point B, the key frames would be the start and end point (so you basically put the small picture into the spot you wanted it to start at and press the ‘keyframe’ button and then move it to point B and hit ‘keyframe’ again – then the small picture would move from point A to point B whenever the effect was run).


Once I understood what a keyframe actually was, the whole machine was unlocked and I could use all of the features – but until I understood it, I could not even start to use this very expensive machine.

Back to governance and agile – when we understand how decisions get made – it’s quite easy to translate roles such as Product Owner into an organisation – the same decisions are being made – we are packaging them in a different way in agile teams.

When governance is not well understood, we end up circling around definitions for Product Owner etc – we are already causing confusion by introducing a completely different way of working. And on top of that, we need to break apart the decisions, accountabilities and responsibilities and place them into the daily planning, checking and doing aspects of agile delivery.

A way forward is to spend some time ensuring that the governance principles are better understood for the pre-agile ways of working and only after that, attempt to translate into the agile context. It feels like taking a step backwards – and it is much better than going around in circles and talking at cross-purposes.

If governance was never really there in the first place – this is one reason for the impression that governance is absent in agile.

PROCESSES LEAD TO CHAOS, DEFINED PROCESSES LEAD TO SUCCESS.

To help understand the idea behind the statement that processes lead to chaos and defined process lead to success, consider a trip to any location say Healesville. We could drive, catch the bus, walk, run or ride our bicycle, even fly or parachute in to Healesville, these are all modes of transport. Next we could go via Lillydale, Kinglake or Yarra Glen, these are the three most direct routes possible from our location, these are the routes of journey.

Can you imagine the chaos that would ensue trying to work out who will go, who will stay; who drives, who rides etc and lastly the route we wish to take. You can see the inefficiency of the process if we allow it to go undefined. If leave it undefined we have issues with Who, What, How and When. The when is not only dependent upon the time we choose to be in Healesville but also the mode of transport taken by the people going and the route taken. So by not defining the process, we can easily end up in a state of option paralysis, which results in nothing being done.

Now if we define the process by saying “We are going to drive to Healesville via Yarra Glen, to be there by 1:00pm next Saturday, for lunch (2hrs).” The organisation of the task becomes infinitely easier because many high level decisions have been removed as options and this has forced a focusing of intent. Now finding the answers to Who, What, How and When has been simplified, to much simpler and more logical questions, such as:

Who has a Drivers License?
Who wants to drive? Influenced by road familiarity and road and car conditions.
Who wants to go to Healesville? Influenced by total time and other commitments.
How big a vehicle do we need? Influenced by how many people.
How many vehicles do we need to take? Influenced by how many people.

Be defining the Mode of transport, Route and Time of the Event, departure times and the total time required for the round trip can be defined. If we drive we can say 1hr to get there and 1hr to get back plus 2hrs at the lunch roughly. These estimates also allow us to understand how much of our Saturday afternoon/evening will be taken up and if we will be traveling at night. These factors will influence who may wish to come.

So the better we define the processes we wish to take to get where we are going the higher our chances of success. You may also of noted that high level defined parameters does not remove all freedoms when planning and in fact with this high level guidance we are often liberated to achieve our goals.

Personal Philosophy 101: No Solutions, just Tools

Personal Philosophy 101: No Solutions, just Tools.

In a world driven by a culture with a need to compete, complete, deliver and rapidly produce. I put forward, the simple personal perspective that there are no solutions, only tools and choices.
The need we all feel to deliver a “solution” for our customers and ourselves is admirable but it also has a much darker side and consequences. The unspoken idea that we can give people and organisations a solution, can be very harmful and blind us to the true solutions. The cold hard truth is that we can not give anyone a solution to anything, we can only provide them with tools, which they can use to help find their own solutions.
The underlying premise is that only “self” can find the “true solution” because only self can know the factors needed to solve anything often with many conflicting needs and consequences. To complicate the process even further, often these factors specific to attaining your true-solution are partly or mostly unknown. Therefore, if the self doesn’t know the required factors to attain the true-solution required how can a third party give them a solution?
It is this philosophical viewpoint, which leads me to the personal view that regardless of saying we deliver solutions, we actually can only ever provide tools so the client (“self”) can determine their own solutions.
We can provide options, opinions, advice and other tools but we can not actually quantify completely their requirements and the level of “hardship or discomfort” the client would find acceptable. In actual fact, they themselves, often are unaware of some or most of these factors, when they engage you to solve their “issue”.
The “solutions” we provide often become band-aids because of this very fact. If we do not know the complete environment, how can we provide a solution? If the customer is not aware or educated about the options, constraints, and issues how can any “solution” they ask for be anything but a band-aid? Just like a band-aid, these solutions sit on the surface and never actually become part of the “self” or culturally absorbed. The true-solutions are derived from “self” only when awareness of the goal and the issue matrix surrounding the goal are realised.
This may seem an unbeneficial viewpoint, yet if you and your staff understand this, then this acceptance will liberate and empower them to focus on the why and what-ifs.
Consider the developer asked to provide a solution for a customer, the first step is to usually focus on the constraints of the solution, not the issue matrix for the customer. In this step we immediately become solution focused not customer focused. Then we focus upon the constraints of the individual technologies we force upon ourselves to be used, not the evaluation of the best technologies or processes for the particular case. Again solution focused and constrained.
If we see our job as to provide tools we more easily embrace the path of discovery through discussion, communication, advice, options, and opinions and avoid the pitfalls of assuming the responsibility of a flawed band-aid solution.
The old saying “The customer is always right” always annoyed me, even when I worked retail. The simple fact is that if the customer knew what they needed, they would not need you. Your role is to help them make a good well-informed decision, your job is to give them the tools to do so! It is then up to them to decide their appropriate course. Some customers only focus on cost and then complain, others focus on brands and then become frustrated (you can’t complain when you spent that much). A few customers realise they need help and trust you will do the right thing by them. They are the customers you want and need to try and develop through education and together we may move a little further towards a better outcome, a true relationship.

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

www.StateOfAgile.com

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).