Managing Constraints

Posted on January 10, 2016 by kb2bkb

Tasks and activities are easy to manage – we see that a job needs to be done, schedule some time for it and then do it.

Queues are easy to see – waiting in line to pay for some goods when we go shopping – or waiting in line to see a popular tourist attraction. Waiting in queues like these is a good time to ponder about why the queue is there and how it could be better managed. Could the shop hire some more cashiers? Could the tourist venue allow more people through at once by setting out the attraction in a different way?

What about the queues that we cannot easily see such as those in our everyday work?

One thing that seems efficient is a regular set of decision-making meetings such as review and approval to proceed with an activity (like recruitment or a project). There could be a better way to manage these decisions – or are these regular meetings actually the most effective way to do it?

How many of us have rushed a presentation together to get it into the next cycle for a decision meeting? What might happen if the decision could be made as soon as we have brought together the information needed to make that decision? Would we have less of a sense of urgency and take longer to do simple things? Would it take less time because we know that the decision will be made as soon as we are ready for it?

The decision to proceed or not is a constraint – up until that time, we are not certain that the project or other action will go ahead. By holding a regular meeting for the decision-making, we are making efficient use of the decision-makers time – but we are introducing queues into the process. Imagine that there will be 5 project ideas presented at the next meeting – all 5 have different sets of data that they need to gather in order for the proceed or not decision to be made. This data-gathering will have different lead times and each project will actually be ready for the go/no-go decision well before the meeting – so the length of wait-time in the queue will be different for each of them. How many of us record these wait times? Those things that remain invisible cannot be managed – people will be waiting on the decision-meeting before they can do the next set of useful actions. We could have 5 teams waiting on one meeting with senior decision-makers – because that is the best way to use the time of those decision-makers.

Constraint management is hard to do because it is very hard to notice the constraints. We get used to it taking a certain time to do things and waiting for the next decision point – because that’s how it’s done and it appears to be efficient.

There are a lot of other constraints out there waiting to be noticed – the clues are there when our colleagues roll their eyes or complain about something. We can empathise with them and move on – or we can empathise and then dig a bit deeper.

Is this a part of a pattern?
Do other people also complain about it?
How can we measure the things that people are complaining about?
If we could measure them, what would we expect the measurements to be in order to validate or invalidate those complaints?
If we are not already capturing the data, why?

Next time you are planning work – notice if you are planning activities, tasks or constraint management. Planning some time each week for observation sounds like a good idea – only by looking at something for a while and reflecting will we find ways to improve.

Reliance on Others

Posted on January 3, 2016 by kb2bkb

The agile concept of self-organising teams can be mistaken as allowing the people within a team to do whatever they want to do – because eventually they will self-organise into an effective group. If I was told to be part of a self-organising team, my first reaction might be a feeling of freedom.

I could do whatever I thought was the right thing, such as, come into work at 3am and leave around lunchtime or write all my documents in Latin (because that would be fun and precise – although I would need to seriously brush up on my high-school Latin – I can only remember ‘canis in mensa stat’).

I was trying to think of a list of things that I could do by myself and ran out of them very quickly – we rely on other people at work to get our jobs done. With the two (silly) examples above, my sense of freedom would place a burden on others – not many people would be happy to attend my 3am meetings and very few would be able to read my Latin documents.

Another misinterpretation of self-organising might be ‘without constraints’ – which sounds wonderful, and could end up with similar issues. Constraint can mean prevention or it can be a thing that helps to shape our thoughts and actions in useful ways.

Back to the concept of self-organising teams. Teams cannot work in complete isolation, even in a small company there are other people involved. Imagine running a sandwich shop. Our Customers are likely to buy sandwiches during lunchtime – so we have a constraint of peak sales likely between midday and 1:30pm. We can only afford a certain amount of counter space, staff and supplies – and each fresh sandwich takes a minimum time to prepare, wrap and conclude the sales transaction. We can think of the shop as having inputs of fresh sandwich ingredients and outputs of sandwiches to happy Customers. The way that the shop runs needs to consider the inputs and outputs and then come up with the best way to get flow happening.

Now we are very far away from the concept of freedom and without constraints – we are tied to the shop for the long hours of work to service Customers for 90 minutes a day (and a few sales before and after that if we are smart). And yet, many people think of freedom as running their own business – how can we resolve this seeming paradox?

Perhaps freedom comes from the serving of others and is enabled by our reliance on others and we need to consider this in our teamwork. An effective self-organising team cannot be a bunch of people doing random stuff and magically becoming organised. The group needs to consider the inputs to the team and the outputs expected from the team – as well as the inputs and outputs for all of the work within the team. By observing these inputs and outputs and the way the work flows, we can improve over time.

In the sandwich shop example, we can place the ingredients in consistent places and monitor them as they empty during the busy periods. We need to discuss our observations about the effectiveness of that layout and any processes for topping up the ingredients.

Only by working together to share observations and ideas for improvement will we see any changes.

There was a great lunch place near my office that changed hands a few years ago and changed from quick service into very slow service almost overnight. I persisted for a while, but it did not get any better and I always wondered why the old owners did a much better job and these ones were inefficient. Now that I am writing this post, I think that the people in the lunch place were too polite with each other and tried to share the work – there would be 3 people making my sandwich, when before there was only one – or 2 at the most if they were not busy. The new owners divided the work up so that one person would prepare the bread and another 2 prepare the other ingredients – but not like a production line and they would be working over each other and slowing each other down. I imagine that this would have been frustrating for them and perhaps they did not discuss these little frustrations and observations, so the opportunities for small improvements were missed. I stopped buying my lunch from that place and there is a completely different lunch place there now.

Perhaps it would be useful to rename the idea of self-organising teams because it causes a lot of confusion. I would like to see teams that practice continuous improvement aiming towards great flow and the creation of value. Teams that are observant of the flow of the work from start to delivery as well as within the team and considerate of the impacts to others within and outside of the team.

Considerate-Observant Teams – the freedom to create value… and recognition of our reliance on others in order to be free.

More Than Two Options

Posted on October 2, 2015 by kb2bkb

Innovation – the catch-cry of our current times. To create new things, we obviously need to have ideas and the more ideas we have, the more likely we will find great ones.

One of the things stopping us from having more ideas could be the morphology of our human bodies.

If we look at how our bodies are set out, we have two sides, two hands, eyes etc. – perhaps this is constraining us and making it more difficult to imagine many more ideas.

As a thought experiment – what if our bodies were shaped like an octopus – with eight tentacles instead of two hands? I wonder if our natural constraint would then become eight. We could call this way of thinking ‘octopus mode’ so that we are making a deliberate effort to generate many ideas.

Imagine the way our conversations might change

From….. ‘I think we should do X, but on the other hand, we could do Y’

To….. ‘We could do A, or on tentacle 2 we could try B, or on tentacle 3 we could explore C, and then on tentacle 4 we should really do D’……and so on

Taking the thought experiment a bit further, in octopus mode, I might be writing this post and wondering about our constraint of eight, imagining what it would be like to be a centipede.

OK – it’s getting a bit silly now. The main point of this post was to highlight awareness of a physical constraint that we deal with every day and might be influencing our ability to think of many more ideas.

In summary

Next time you are thinking about options or generating ideas, try octopus mode and come up with at least eight
It does not matter if some of the ideas are a bit odd, these ones could lead to the innovation we want to find
Now that I’ve done two points, of course I am going to write eight, just to see what happens
One way might be to draw up eight boxes on a sheet of paper and keep generating ideas until all the boxes are completed
It could be considered a waste of time if the ideas or options that we are looking at are obvious and limited by other constraints (for example, choosing a product to buy when there are only three types available), so suggest not using octopus mode for these ones
Problem-solving is a great place to use this mode – we often want to jump straight to solution. Looking at the problem in eight different ways will open up new options
It’s really very difficult to think of eight things – but at least this point creates number seven in the list and I only need one more
Once eight gets easy, perhaps try for centipede mode – one hundred ideas or ways of looking at a situation/problem

Thanks again to Tobbe Gyllebring and Steve for the conversations that have inspired this post – of course, any inaccuracies are all mine.

Customer Experience and IT Operations

Posted on September 19, 2015 by kb2bkb

IT Operations – the engine room of our organisations and seen as an unglamorous workplace area.

When we picture a software development lifecycle, we often picture it like this…

A business sponsor has an idea or identifies a Customer need, they ask the software development teams to build it and then it gets implemented into the production environment so that the business area can serve better experiences to our Customers.

In this picture, the operations teams are seen as being far away from the Customers and treated as a ‘back of house’ function.

But there is another way to look at this picture.

In this one, the only way that our Customers can receive any value is from the operational (production) version of our systems. The operations teams are much closer to our Customers as it is their role to ensure that the production version of the systems are resilient and stable.

If we use this second way of looking at the software delivery process, the needs of our Customers are pulling the delivery of value into the operational environment. In order for that value to get there, the teams from operations, development and the business sponsor areas all need to work together. This goes to the heart of what DevOps means to me.

For those of you who have spent some time doing operational roles, the following will be obvious – for others, if you get a chance to spend some time in the operations department, please do – it will provide many insights.

I once worked with a team where the developers and the operations people were co-located and we changed our development processes to consider the impacts to the operations team right from the start of design. We called it Minimal Operation Intervention and below are some examples of this principle.

When we designed a batch process, instead of expecting the operations team to find out what was wrong and restart it manually, we would design in the ability for the batch process to detect common fault conditions and rollback/restart without operator intervention.
There can be a temptation to save money and time during development by making some processes manual – this goes directly against the principle of minimal operational intervention. In my view, if our operations team members spend most of their time in the operations room just monitoring our systems and nothing else – that is good design built in.
I’ve also heard of a case where development teams were doing the right thing by building alarms into their new features – but they never updated or retired pre-existing alarms. The operations team were left with a confusing array. We need to consider the experiences that we want our operators to have at the same time as we focus on the Customer experiences and value that we are delivering.

In summary, our operational/production environment is the only one that we can deliver value from – all other activities in the development process need to focus on making the production environment resilient and a seamless experience for our Customers, Users and Operators.

Thank you again to Torbjörn Gyllebring and Steve for the conversations inspiring this post – any quality or factual defects are all my own however.

Misconceptions and Insights about Collaboration

Posted on August 18, 2015 by kb2bkb

A Few Thoughts about Collaboration

The definition of collaboration in any given context is variable. It can be as simple as two people working on a task or as complicated as international diplomatic relations and anything in between.

Some people might think that collaboration means agreement, but some of the best outcomes have happened when people with very different views work together.

One of the problems with trying to solve problems is our inherent biases. We have only lived our own lives and therefore make decisions and contributions based on our experiences. It is easy to make assumptions without realising it, so when we are collaborating, it is important to check our assumptions with each other and make sure that what we are working on is an agreed view of the work.

Collaboration is not a static point but a dynamic interaction between the task at hand and the participants including their experiences and the interpretations they bring to the “table”.

A Couple of Misconceptions

1: Everyone is created equal

Almost everyone doesn’t like to hear this one but we are not created equally, if we were, it would be so boring, and we would all be the same carbon copies of each other, same job, same life and same house. Some of us find doing certain things easier than others, this does not mean they are better than someone else but have a predisposition towards that particular thing. This is actually the strength of any collaboration, we are not a monoculture or genetically engineered workers but individuals with different perspectives and abilities. This is the core of collaboration and teamwork.

2: Everyone must carry their own weight and do their share.

Collaboration/ Teamwork is rarely a balanced interaction (50/50 etc.) but most realistically an imbalanced one. The beginnings are like a “seed”, an idea of a purpose and/or direction, however the “seed” does not contain all the materials and experience to develop into the eventual “plant”. The contribution of the seed if measured by biological bulk is minute and of little significance; yet without the direction and/or purpose there is no “plant”.

Perhaps we should consider this when we think about the share of workload in teams and remember that a small effort that provides a large weight of outcome can be just as good as a large effort.

When we discuss collaboration and teamwork we often begin to weigh the obvious, visible efforts that people are putting in and lose sight of the reality. Without the idea, thought and then the effort, the experience is a barren one. The ego and self often confuse and stifle the collaboration from becoming. We should check our Ego’s at the door and be open to ideas and possibilities regardless of where they may come from.

In summary – the differences in backgrounds, ideas and effort can undermine any team and result in very poor outcomes, however, it is these very same differences that can make any collaborative effort a great one and open opportunities for innovation, increased effectiveness and workplace enjoyment. How can we turn our thinking towards the positive outcomes from differences and ensure that we leverage these as much as possible?

Allow people to come up with their own contributions whenever possible and then share them – this will prevent premature convergence and make differing assumptions easier to detect.
When we feel that others are not pulling their weight, check that we are not just observing effort and instead look for contribution towards the outcome.
Recognise that different people are good or great at different things and try to avoid creating teams of very similar people or skillsets.
Use the different perspectives and backgrounds of other people to help us see things that we are overlooking – another good reason to have people with diverse experiences in teams.

Thank you to Torbjörn Gyllebring and Steve again for the discussions that inspired this post and Steve for contributing some paragraphs and editing. Any faults with this post, however, are my own.

Torbjörn Gyllebring’s post is about Estimates and Theory Building

Linear, Non-Linear, Predictable and Unpredictable

Posted on July 25, 2015 by kb2bkb

Firstly, a thank you to Torbjörn and Steve for the conversations and feedback leading to these thoughts. Torbjörn has also written a post on this theme for those who have not yet seen it.

We can have a tendency to use linear and predictable as synonyms, but there are non-linear concepts that are also predictable and one of them is called hysteresis.

The easiest example of hysteresis is a thermostat for a heater. If we use one temperature setting to turn it on and off, then it will click on and off endlessly. If we set the on temperature just a little under the desired one and the off temperature just a little over it, then it works much better. When we walk into the room and measure the temperature only, then we cannot know if the heater is currently on or not without knowing the historical temperature and thus whether the room is currently cooling down or heating up.

So this is an example of a predictable process that is non-linear – we can use mathematical modelling to generate that predictability. I wonder if there are other processes that are non-linear, but still have some predictability in our work places.

One example might be change initiatives. We start at one level of understanding, do some training, coaching, communications and other ways of influencing change. After a period of time we move up to a new level of understanding. Then as other things happen and new people join the group, we lose some of that understanding – but it is likely that we are still above the original level.

I’m still looking for other examples – but hypothetically, a whole bunch of non-linear processes over-lapping and intersecting with each other would likely look like a very complex system.

Of course, mathematically, we would then be able to demonstrate these parts of the system and their predictability – but that is not really the point. We are all observers of our world and how we experience it as individuals is different for each of us. Therefore, the natures of systems that we interact with will differ according to our experiences of them and what seems predictable to one person can appear quite random to another one.

Back to the title of this post – along the gradient of predictability, we move from linear with obvious cause and effect to non-linear, such as hysteresis with less obvious correlation, then towards a lot less certainty where the relationships are dispositional and then to randomness. Most of the time whatever we are observing is likely to have a mixture of these attributes both inherently and from the ways that we experience it. Taking the example of a thermostat, I wonder how many other things also appear quite simple and are really elegantly complicated and on the flip side, how many things appear complex and are likely non-linear, but still predictable?

Meetings and Assumptions

Posted on April 6, 2015 by kb2bkb

Have you ever been in a meeting that went a bit like this?

Somehow the meeting went off-topic, or a conversation suddenly took over the entire session. What went wrong? Perhaps our conversations were assumption-based rather than fact-based.

Assumptions are very valuable things, they help us to move forward. An obvious example is the assumption that the footpath in front of us is solid, if we doubted this all the time, we would have a lot of trouble walking around, let alone running or jogging.

The less helpful types of assumptions are ones that we make about our own or others definitions of words or level of understanding about a topic. I can remember having 30 minutes of strong debate about an issue a long time ago, only to discover that we were actually arguing for the same thing – just using different terminology.

When planning meetings and workshops, list out the topics that might cause debate or miscommunication and then ask what assumptions we might be making about those topics. Whenever possible, spend some time validating or invalidating those assumptions before the meeting so that we turn those assumption-based conversations into fact-based ones and use our time more effectively.

Questions as Boundaries

Posted on November 9, 2014 by kb2bkb

How do we know when we are asking a good or a poor question? One sign of a poor question is when people are spending a lot of effort for seemingly little gain.

‘What should we do?’ can be both.

If it’s been done before and there is a predictable, best practice way to do it, then the obvious answer is ‘The next logical step.’

However, if we are exploring complexity it can be a poor question, there are so many possible options that it can take a long time to decide what to do.

In order to explore something which has limited certainty, it is better to form a view or hypothesis and test it. This then creates a type of boundary around the thing we are trying to understand to help us make sense of it.

Questions like

Will ‘X’ happen if I do ‘Y’?
Is it feasible to achieve ‘X’ for ‘Y’ effort?
Will people buy our product?

For example, we often start a project by asking how much time and money it will take to make our idea a reality. This can drive a very large amount of effort to find out – when the project happens to be in the complex domain (as per the Cynefin Framework). If we change the question to ‘Is it feasible to make this idea a reality for $X and Y time-frame?’ it puts boundaries around the initial exploration stage and we can avoid large amounts of wasted and unfocussed effort. An example can be found in my previous post ‘Why do we Estimate?’

In summary, check which type of system the question relates to according to the Cynefin Framework. Then check if the question is helping to drive useful logical work or useful exploration and if not, then change the question.

Automation

Posted on May 13, 2014 by kb2bkb

There are companion posts from Marc Burgauer and Trent Hone about this topic – these 3 posts are our initial thoughts based on some Twitter interactions.

For the purpose of this post, the term ‘automation’ should be considered in the broadest possible sense.

If we think about software supporting and automating tasks such as ordering products and producing bills, then continuous delivery is like automating parts of the software delivery process. I thought that it might be a useful thought-activity to consider other forms of automation and see if that generates any insights – especially around how we decide what things are safe to automate and what things need to have human judgement applied.

One form of automation is refrigeration – imagine if it was manual. We would need to keep an eye on the temperature and add ice whenever it went over a certain amount.

In a broader sense, even pathways might be considered an automatic guide for where to step next and a convenient way to find places.

In the above two examples, we might make the decision about where to build a path once we see a worn track where many people have walked. We might decide to automate refrigeration because transporting and adding ice manually is very labour intensive.

On the safety side – a worn dirt track is not as safe as a textured concrete path because in the wet, it might be slippery. Also, hauling ice through the house risks injury and if we forget to add ice at the right time, our food will become contaminated and make us sick.

If we abstract these concepts, here are some good reasons to automate something

We have already done it many times and will continue to do it the same way
We know exactly what we need to do and it is hard to do it manually
Problems are happening due to lack of care

There is still a bit more pondering to do with these thoughts and I am looking forward to further inputs and insights from Marc Burgauer and Trent Hone – thank you to both.

LeanUX 14

Posted on April 27, 2014 by kb2bkb

I’ve spent the last week writing up my notes from the excellent LeanUX NYC Conference held on the 10th-12th April 2014. The great news is that all of the speakers were recorded and these will be progressively released on the LeanUX NYC site. Below are just a few things that I enjoyed learning about.

Interactivism – a model of planning where we ask what we would want to design right now that would work – instead of an ideal future state. We then identify the constraints impeding us from achieving that now and manage those constraints. From the opening keynote by Jabe Bloom.

Alistair Croll mentioned that innovation is the opposite of what the large company is designed to do and therefore innovators are seen as things like bad listeners and job killers etc…

The three things that lead to success are

Intention – manifested as a decision
Process – a means/routine
Practice – right practice, deliberate practice

This is from John Shook who spoke about Lean Change

Thomas Wendt mentioned that testing can reveal coping strategies – things that people do to cope with poor design – I really liked this insight.

In a complex adaptive system, messy resilience is better than neat stability. The idea of boundary conditions as membranes not walls. These two items from Alicia Juarrero.

Bill Beard talked about branding moments such as making a wrong password failure a bit more fun instead of the plain ‘invalid password’ response – but only to do these sorts of things if your product is not broken. A very important point.

A complex adaptive system is modulated – not driven. It is non-causal and is dispositional. Also, frameworks are scaffolding and are meant to be taken away. These are from Dave Snowden who provided an excellent closing to the first day.

Markus Andrezak pointed out that the constraints applied to a work environment meant for creation and creativity would be harmful to a production work environment and vice versa.

The above are a sampler of the take-aways that I am finding useful to ponder about – and I would encourage you to watch the videos when they are posted. The conference was intense and informative and a great way to meet people who are leading our thinking about improving the ways that we work.

Comfortable Ambiguity

Cynefin, Agile, Lean

Author Archives: kb2bkb