Author Archives: kb2bkb

Efficient Expediency?

Posted on by

Steve, Tobbe and I were discussing actions and the differences between working in efficient ways and working in expedient ways.

Efficient is a non-judgemental word and rather clinical – are we working in ways that reduce or eliminate the waste of resources, effort, time and money?

Expediency has a moral element – doing things in ways that are convenient regardless of whether they are morally the right things to do.

I did not notice my attitude to visual management changing – it struck me only recently. When I first started to work with cards on the wall, I thought it was about accountability. I would feel awful if I pointed to a card that I said I would finish yesterday and I still had not completed it today. Now I feel fine using cards on the wall to see how the work is flowing. It gives me ways to capture data and articulate where the workflow is being impacted. The focus is not on me and my accountability (there are plenty of other ways to look after that in the workplace) – the focus is on how we can make the system of work flow better.

Getting back to the words – expedient and efficient. Kanban-style visual management is a very efficient way to visualise the work in order to improve it, it allows us to see queues of work that are otherwise invisible. I have also heard horror stories of it being used to victimise people – it is an expedient tool in that respect. Someone could stand at the board, point at a card and interrogate the team about who is working on it, why it has not moved and yelling could happen. Unfortunately expediency also often includes efficiency.

Because I had not noticed the change in my attitude, I am careful to explain the difference when speaking to others who are new to visual management – it is likely that they may be feeling the accountability side just as I did at first.

 

Action and Activity

Posted on by

Action – doing something that will result in a valuable outcome

Activity – doing something – regardless of the result

We tend to think that if we are not doing something then we are not being productive – we need to be cautious of doing things because we think that more is better. There are many examples where more is not better – even drinking water. We need to stay hydrated and we think that drinking more water is better for us – but over a certain amount, it can cause toxic and dangerous effects on our bodies.

Since the discussion with Tobbe and Steve recently, I’ve been reflecting about times in my life when I’ve mistaken activity for action – there’s more than I’d care to admit at this point.

We should check what we are doing and ask ourselves – is it activity for the sake of activity or are we taking action and making progress – whatever the endeavour? To answer this we need to understand purpose.

One of my favourite things to check is the purpose of reports that are being generated. I’ve seen situations where there are 100’s and 1000’s of reports – and no one really knows how they are being used. The activity version of a report, likely came from an initial need to make a decision – let us imagine that we needed 3 types of data to make that decision – so we ask for a report every week with those 3 types of data. And then – due to the ephemeral role of data in decision making – we quickly discover that we need another 2 elements of data. Very quickly, we can have a report being generated every week with lots of data elements. A lovely amount of activity – but what if we are not making those decisions any more? And there are better ways to gather data when we need to make a decision – reports can be very . inefficient.

Whatever we are doing, ask about the purpose of it. Is it activity for the sake of doing something? (And therefore can we stop doing it?). Or is it action? (And we should continue).

The Factory Analogy for Software

Posted on by

This is a reflection piece working on similar themes to a post by Tobbe ‘The Software Factory — an idea wrong enough to be useful’

When we think about automation, it is easy to imagine factories. The standardisation of work that was brought in with ideas such as The Principles of Scientific Management by Frederick Winslow Taylor allowed us to automate jobs that were previously performed by craftspeople. So it is pretty easy to think of software development as like a factory because we are automating functions – but the ‘goods’ we are producing are transactions – not physical items.

I like Tobbe’s idea of the flexible factory line where we have teams and architecture that support delivering software in more flexible ways. Most of us do not think about factories like that. I had a part-time job packing biscuits in a health food factory working my way through university. So when I think about factories, I am thinking about highly repetitive (and boring) tasks that are getting automated.

Where we trip ourselves up is using factories as an analogy and mis-applying the metrics that are useful for high-volume repetitive tasks to tasks that are less repetitive. Even though I was manually assembling the boxes for the biscuits, I would pride myself on finding more efficient ways to do this – and shaving a few seconds off this part of the process (which I did at the start of each shift) was useful as well as rewarding. This is where tools such as control charts, six sigma and paying attention to changes in trends is very useful. The production version of a piece of software is similar to a factory in this way – I really want to know if my many transactions per minute start to take even a tiny bit longer to execute – this could indicate a problem that is easy to fix and avoid a big outage. I once looked after a system that lost sync between the 2 databases and it took 24 hours to re-sync (with degraded performance for the end users over that entire day). We made sure that when we found out what had caused the issue, we watched the early warning signs with a lot more rigour and I’m happy to say that it did not happen again.

Installing new code is like changing the setup of a factory. In my health food factory example, it might be automating the biscuit packing job that I did. I imagine that if we automated the whole process, then the factory might be offline for a few days – losing a few days of production and therefore sales. Taking an agile approach, perhaps we just automate parts of the process in one go, such as starting with the box assembly. I’m not sure how big a machine to assemble cardboard boxes would be, or how much it would cost – but we could get in the experts who have done it before and they could tell us. We might use project metrics such as on time, scope and budget to ensure that we are not causing too much disruption to the factory production and sales. We can also go back to the production metrics to see if we are making a difference to cycle or lead times, once we have installed the new parts. There might be a way to install some of the packing automation without disrupting production and we would need to design the factory in a different way to the one that I was working with if we needed to have continuous production while upgrading the machinery. This example is like the release management process when we deploy new software into the production environment – we should be using metrics that allow this process to become more efficient and project-based metrics would be appropriate – especially if we add the quality check about the impact the change has to the production environment.

Software development is like deciding what we need to automate and then designing the machines to perform that automation. If no-one had built a box assembler before, then we would need to observe the manual process, the steps surrounding it and then design the machine. We would need to take into account how it would be maintained – this is a bit like the architecture role in software design – in the factory, we would not be making large machines out of gold – it is too soft, very expensive and would be hard to maintain – but it would be nice and shiny. In software design – how do we make sure that it integrates well into the existing software and requires minimal operational intervention? We do not want to be having to re-index the database every day – just like we would not want to have to service machines every day.

What if we decide to produce a different type of item. In the health food factory we also had lines that produced pies and cakes – which were separate to the machinery that produced biscuits. What if the company decided to manufacture something different, it could be a small difference such as a new type of biscuit or a large difference might be to manufacture coffee mugs. Whether there are sales out there for a new biscuit or coffee mugs is very similar to identifying if there are needs for new software features and we can use the same human centred design or user experience toolsets for physical and virtual things. Once we’ve identified the need we then need to decide if we should start a separate production line or modify an existing one. It is hard to imagine being able to manufacture pottery mugs and biscuits on the same factory line (and health regulations would likely not allow it) – but I have seen people try and add new functions to a piece of software that was never designed to do that new function. An example is where we were asked to add a fraud-handling function to an application which would have incurred a huge cost (in time and money) when we already had a separate system that could do what was required with much less cost.

How we measure the effectiveness of new items in a factory or features in software is very different to how we measure the efficiency of the production environment for both. We look at how sales are progressing, the level of interest shown by Customers etc. At this point the analogy is breaking and becoming less useful – the key point of this post is that using a factory as an analogy for software development can be useful in the ways described. We need to remember that an analogy is only saying that elements of software development and operation are like a factory – and we need to be careful that we do not equate building software with assembling items on a factory production line – especially if we then try to apply factory production metrics to software development.

Splitting, Refraction and Facets

Posted on by

 

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.

How much Transparency?

Posted on by

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.

Culture can be a Vexing Word

Posted on by

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

Posted on by

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.

Agile is like using a Chef’s Knife…

Posted on by

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

 

Effective Efficiency

Posted on by

Efficiency is not a good goal, effectiveness is a better goal.

What do we mean by being efficient? In simple terms it means doing a good job, a job that has the intended outcome with the minimal amount of effort. At an organisational level this is usually interpreted as saving costs and that can lead to what I would call some ‘cheap and nasty’ outcomes.

So we have started to rebel against the cost-cutting aspects of efficiency and are now very focused on effective outcomes…almost to the point that using the word ‘efficient’ is not really acceptable.

We can be both effective and efficient, and we should be. It’s a good idea to monitor for opportunities to reduce waste, while being selective about which types of waste make sense to keep or reduce.

The one place that it makes sense to be less efficient is when we are tackling complexity. This requires a probing, exploratory approach which can actually be more effective when it is not super-efficient…because we are looking for things which we are uncertain about.

The thing that holds the thing that the Stakeholders were holding

Posted on by

So we all know about stakeholders…those people that care about what we are doing and should have a say in what happens.

Are there also people that care about the thing that the stakeholders care about that we would not call stakeholders?

What does the ‘stake’ mean when we refer to the stakeholder? According to Wikipedia, the term originally referred to the person who temporarily held the stakes from a wager until the outcome was determined. Business has since co-opted the term to mean people interested or impacted by the outcome of a project.

Tobbe and I were having burgers for lunch today…they were so tall that they had skewers in them to keep them together. So the chef held the skewer (stake) and we held the skewer when we ate the lunch, but the person serving us never touched the skewer…just the plate that supported the burger with the skewer in it.

That got us thinking about what supports the interests of the stakeholders, and yet, is not a stakeholder of a project or outcome?

It may be what we call governance. The scaffolding in an organisation that ensures that business interests are looked after…ensuring that our burgers arrive safely and without toppling over onto the floor.