The A-Ruminations team discuss decisions, biology and all that it implies.
Category Archives: Governance
008 Spanner In The Works
The A-Ruminations team discuss the Utility of “Spanners In The Works” and analyse the advantages and pitfalls they bring.
OBSERVATIONS IN HOW THINGS GO 2
As a society based in the post Industrial revolution, where productivity and maximising profit rule the landscape and dictate our daily lives. We strive for “Efficiency” in our work lives and even our daily lives and many of us never really think about what we’re doing and the costs of our search for better, faster, more!
Efficiency vs Expediency.
Years ago I was developing a database, the demands placed upon the database were simplistic and basic. In essence it was a list, used to check the availability and validity of numbers. The idea was to wash a random bucket of numbers to see if they fit the criteria set by the customer. These numbers could have easily simply occupied a simplistic table format and been fine. The customer would have been happy and content yet, I found the basic minimal number of columns, data points inappropriate for the customers future needs.
Yes, I opted for Efficiency over Expediency. The reason was I have a scientific background and we never throw anything out, especially data. The data is only as good as your mindfulness and awareness while collecting it. Many a scientific study has suffered and been less important because basic and minor data was not collected during the experiment. In science I would never disregard any data which may be needed later. Anticipating future data needs and possible uses, is key to Efficiency.
So I was predisposed to put myself in the customers shoes and try and anticipate possible future data requirements. The upshot of this was that for very little extra effort, an extra few columns and a few extra lines of code; the customer could benefit from future data mining and analysis.
The effort required to develop the database was the same !
So why do we choose Expediency over actual Efficiency ?
The daily activity of trying to finish our work items steers us towards Rapid Solutions which seem Efficient; yet this very Expediency often costs many times more with rework, rebuilds and even the complete redevelopment when parameters shift as future needs become apparent.
The old saying “A stitch in time, saves nine” springs to mind. The mindfulness and mending of a small tear prevents the need for major reworking and effort.
So next time, ask yourself is this done for Expediency or actual Efficiency, and hopefully we can get a head of the curve and put our future efforts into better things than Rework.
The way I see this is that most of us try to do the best we can but a few remind me of the Ferreters of old who would let go any pregnant female rabbits so they would get work next year, to reduce the rabbit population.
Expediency has become our efficiency.
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.
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.