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.

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

 

Effective Efficiency

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

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.

ITSM and Cynefin – Lightning Blog

I attended the itSMF 20th Anniversary Conference in Melbourne this week and it was great to see the emphasis from many speakers about automation and using DevOps principles.

The Cynefin Framework is subjective and I was thinking about where many of us see the service management framework and ITIL on it. It is easy to imagine incident management in the chaotic domain and standard change management processes in the obvious domain (highly repeatable and therefore great candidates for automation).

So it was interesting to see the keynote from Lindsay Holmwood titled ‘Mixing Oil and Water: DevOps in an ITSM World’ where Lindsay busted the myth that DevOps and ITSM don’t mix. ITIL and the service management framework are great tools to identify the candidates for automation and for where to ‘build in’ governance to our continuous deployment pipelines.

If we want to get into the market with safe and small changes that take into account operability, security, regulatory requirements, and resilience, we really need to partner with our service management colleagues.

Assumption Pillows – Lightning Blog

Expanding the thoughts behind a recent tweet of mine.

‘Pondering….less obvious reasons…generate ‘pillows’ of assumptions…and are ineffective cushions against the sharp rocks of risk below’

Assumptions are like pillows – they are very comfortable and we are not aware of them for much of the time. The trouble is that our assumptions and the assumptions of other people that we are working with are likely to be different. When we don’t inspect our assumptions, we can overlook risks – so that is why our assumptions are like pillows.

It can feel like a waste of effort to inspect our assumptions – there are ways of working them into a workshop facilitation plan – that’s the easiest one to address.

Another way is to be aware of the feeling that something is not quite right in a conversation. Once I was negotiating a contract and almost starting to argue with the other party about a particular point – both of us thought that the other one was being a bit unreasonable. After a short break, we took a moment to clarify what we were discussing and it turned out that we both agreed the point, but had been discussing quite different things before the short break.

The main risk that assumptions cause in projects is delay. If we find ways to highlight assumptions earlier we can save wasted effort in circular discussions, rework or duplication.

It’s better to see the sharp rocks of risk than to cover them with assumption pillows.

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.

Comfort and Privacy

How could something as simple as a stand-up be a potential invasion of privacy?

What if someone feels a bit unwell on the day and standing up in the same place for 15 minutes or more is very hard for them to do? What are their options?

They could stay silent – after all, we want to be seen as part of the team and not a ‘party pooper’ by asking to sit down.

They could make an excuse – ‘apologies – I need to dash to another meeting’ – or something like that.

They could tell people what is wrong (which could range from a mild illness to something more severe).

We need to consider this when we lead teams. We should not expect people to share private information – there is no need for us to know some of these things, and in a normal workplace, it’s not a problem.

Many Agile ways of working and workshop facilitation methods, fail to fully consider  diversity and inclusion. When we do consider diversity, we will offer ways for people to opt out of activities in ways that allow everyone to ‘save face’ and maintain their private information.

My ask of the Lean and Agile communities is to take a moment, pause and consider the above – let’s ensure that our ways of working are fully inclusive and not causing discomfort to anyone.

The Productivity of Inactivity

Inactive – that message we get when we look at profiles on Slack, Skype and other apps – ‘so and so has been inactive for x hours/days’. In most cases it’s a bit misleading – our friends have most likely been very active in other ways, and perhaps on other apps.

Are any of us really inactive? Even when we are asleep, our blood is circulating and our cells repairing – just like the fact that there are no true closed systems, there is also no true inactivity.

Let’s define inactivity. For the purpose of this post, inactivity is that quiet time – when we sit and contemplate – or go for a walk to ‘think’. These times are often productive – we can pull together a few thoughts that have been floating around in our minds, and create new ideas. Knowledge work requires this kind of effort – for both analysis and synthesis – for example identifying possible root causes of issues or finding a new use for an old tool respectively. Yet, how many of us make the time to do inactivity? Do we put a blank card on our Kanban walls? Do we sneak it in while we are digesting our lunch?

More likely that we check our emails, feeds, or messages on the aforementioned apps, filling up our inactivity with busyness. With our minds so full, it is very tricky to find new connections. We need to start making more time for inactivity – put up a blank card on the Kanban wall (time-box it). Put a blank post-it note into the Lean Coffee set – a few minutes of silence for everyone to contemplate, muse and relax. Block out some time in your calendar – let’s see if making time for inactivity can make us more productive.