Testing is not just for software, but for the business processes, organisation or service that you’re implementing?
I’ve seen many test routines that are too artificial, too removed from the reality of what the users will go through. Fortunately this factor has improved over time, especially with more focus on user stories.
Let’s consider one of the best examples of testing I’ve ever seen. Guitar amps are generally fragile. They’re usually robust enough for scrapes and minor bashes as you’re carrying them through doorways, but they don’t survive being dropped down stairs very well.
One amp manufacturer had a test routine of removing the glass valves (they’re replaceable consumables) and then throwing the test amp from the roof of the building to emulate the journey that some amps go through. On the ground, they inserted valves and powered it up to see if it would work.
How does that compare to your test routine? Is yours as accurate to the reality that it will be used in?
Here’s a clip of the actual test
I heard this quote the other day, but I didn’t catch who originally said it.
Art requires rigour, science requires creativity
The first point is that it’s contrary to the standard view. The second point is that both perspectives are valid and that there shouldn’t be that much of a difference.
It then made me think of typical transformation programme roles and the relation between creativity and rigour. Most roles have a balance between the two, with that balance changing according to the standard role and, at times, according to the demands on that role.
For instance, process analysts should generally follow a set of standards. Business Analysts have to be more creative, but still have methodologies to follow. Service Designers have less rigour methods, usually a composition of tools and techniques rather than the standardised methodologies of previous decades. At the more rigorous side, project managers have their methodologies and frameworks to follow. Programme managers see a wider scope and have more creativity in organising the interdependencies. Which then fits nicely with my normal comment that a Business Architect has more in common with a Programme Manager than a Project Manager; there are more skills in common, even though the professional methods involved are different. Which leads me to the Business Architect who has to know when to be standardised and when to be creative. There has to be the flexibility to modify the approach to suit the needs of the client, depending on the stage of transformation.
Following the theme of moulding different modelling languages, methodologies and toolsets together, I want to take a look at how to model OKRs in Archimate.
OKRs do not cascade
Just because the diagram depicts a hierarchy, doesn’t mean that the objectives cascade down the organisational hierarchy. Following the logic in OKRs don’t cascade, I’ve taken the approach of the depicting the hierarchy, rather than how that hierarchy is achieved. In the article, Felipe mentions that objectives should not be cascaded down the organisation. Instead, objectives and key results should be discussed and agreed at each level. The resulting picture is the same either way, but the content of the objectives and key results may be different depending on the route.
Depending on the level of the organisation, many of the components that achieve an Objective will not be Key Results, but instead will be lower level Objectives (e.g. of the next team down in the corporate hierarchy or downstream in case of a flatter hierarchy). The diagram allows both Key Results and Objectives to form part of an Objective.
Modelling Goals and Objectives
Key Results have been modelled as Outcomes. Objectives and Contributing Goals (lower-level Objectives) have been modelled as Goals. In doing so, I’ve allowed for a hierarchy of Objectives to fulfil the concept of Contributing Goals. Had I gone with a model of Objective = Outcome, we would have seen a model of hierarchical outcomes which would not have made as much sense, especially to those having to achieve those outcomes.
From the perspective of Business Architecture, I’m interested in the alignment of actions to the overall vision. I like to see a clean line connecting actions of the workforce to corporate objectives to vision. Many organisations suffer because the objectives are cascaded down rather than agreed at each level. Combining OKRs with a culture of joint-goal setting has a good chance of resolving that core issue.
Notes about the diagram
The content is fabricated; completely artificial. I haven’t populated every single branch, but enough to indicate what could be captured. For those areas that I did populate, I kept to the concept of 3 key results per Objective, of which any of the Key Results can be replaced with Contributing Goals. You can flex that as you wish.
I’ve created a tiny environment in which the OKRs operate, featuring an internal driver for change, an external driver, the assessments for both and the corporate vision and missions.
The interesting concept for me regarding business motivation is that the diagram is agnostic of the organisation structure in that it doesn’t indicate which team or who is responsible for achieving which objectives or key results. I’ve done that on purpose.
If we imagine a typical organisation of 400 people. Each of those named 400 individuals could have Key Results to deliver. Some of those Key Results would contribute to team Objectives. Some of those team Objectives would coalesce to fulfil higher level Objectives and so on. That’s the bottom-up picture.
The top-down picture is that the strategy needs to pervade the organisation and steer the choice of actions and the delivery of those actions. At the top level, the objectives may be independent of who is going to deliver them, but shortly thereafter the key results or contributing goals would have to be assigned. And it’s likely that they’ll be assigned to relevant directors (in the case of stretch targets and keeping the operation running) or delivery teams (in the case of changes). However each of the delivery teams should have a sponsor. It’s that sponsor that’s actually accountable in this case for the delivery of the key result, whereas in many organisations it would be the delivery team.
Overall, OKRs force a concept of personal responsibility or rather, a concept of personal accountability if we follow a RACI model. For the majority of a workforce, the individual is likely to be both accountable and responsible for their key results.
What I haven’t address is the non-aligned use of OKRs, e.g. allowing or encouraging the setting of key results that do not fit with corporate objectives.
Ask anyone who’s been involved in any significant implementation and they’ll have come across the waterfall approach. It typically leads to a contractual relationship between one team who are working on artefacts that are then handed over to a subsequent team. While the flaws of waterfall have been well-documented, this concept of contract versus collaboration extends to many areas of work.
Let’s use a brief story as an analogy for the concepts of contract and collaboration. It’s an incredibly simple story, but even with the simplicity, we can see the complications that can arise from a contractual relationship.
My wife and I walked into a coffee shop. I was left to order the drinks at the counter. So I’d asked what drink did she want.
“Mint tea please”
She orders a lot more hot drinks than I do, so she’s more familiar with the script that we all follow in coffee shops. And she definitely knows I do not order as many drinks, so she’s aware that I’m not that familiar with the standard scripts. In fact, I order hot drinks (maybe once a year) so rarely that it’s almost a new experience every time.
So I’m at the till and I’ve asked for mint tea. I hear in the barista’s response that it’s blended mint tea. So I’m then thinking:
- Is blended mint tea acceptable?
- Are there are other teas in this coffee shop which are more acceptable?
I decide it’s acceptable.
I’m then asked what size. How would I know? I was just told mint tea. And I know for a fact that my wife chooses different size drinks, but mostly takes the larger options in general.
So I ask for big.
Not good enough, it’s one of those shops. They have small, large and grande (or some phrase like that). So which is it; big = large or big = grande?
And what happened to medium? (but that’s another story)
I choose large.
Then I’m asked take away or stay in. Thought I’d already asked for the tea to go, but no worries, it’s a busy shop with background noise, so I say to take away because I know the context.
I’m then asked if I want one teabag or two. Woah, where did that one come from? It’s a cup of tea, a bag goes in in order to flavour the hot water. The longer you leave the bag in, the stronger the tea. Mint tea works the same way, doesn’t it? So what would be the advantage of two? Rather than ask what that benefit would be, I chose one since I hadn’t seen many cups with two bags before.
Seeing the way the interaction was heading, I waited for the “do you want extra water with that?” question. Fortunately that didn’t come.
On being given the takeaway cup, I notice it’s hot to touch, but it doesn’t take a genius to realise that. So I look for the holders and place one around the cup.
That coffee-shop interaction was a contractual one. It depicted a scenario where one person (my wife) stated her requirements, which were then interpreted and delivered by another person (me).
Although it’s a very simple scenario, it highlights how much needs to be known to be able to be fulfil the customer’s expectations.
There were numerous attributes that had to be chosen in order to complete the transaction and deliver the request:
- Feature/Product = Mint Tea
- Variety = Blended Mint Tea
- Size = Large
- Number of teabags = One
- In or out = Takeaway
- Temperature to hold = Need a holder
My wife only stated one of those. I, as the contracted partner, had to answer a variety of questions based on knowledge, size based on estimate, number of teabags based on memory, takeaway based on context and joint understanding, holder based on real-world experience.
That ratio isn’t uncommon with any set of requirements. No matter how well or how detailed you define your requirements, there will always be questions that need to be answered. If you’re not there to answer the questions, then it introduces a delay or it introduces a risk of diverging from your (unstated) requirements.
Now, imagine the same scene, but with my wife also involved. The barista would be able to ask her directly, or at worst, ask me to then ask her (e.g. if she’s had to sit at the table rather than stand at the counter). While the latter scenario introduces some back and forth, it’s still more timely and risk-reducing than me guessing and getting the order wrong.
That’s the situation that occurs in many organisations. An artefact is commissioned. It’s defined and passed onto another group. Who digest the documentation and then ask questions. And it takes time to progress through this rigmarole.
While I don’t think the people involved must be present in the same room all the time, they do have to be able to communicate in a way that doesn’t lead towards a waterfall approach.
So the default position could then become one of collaboration rather than contract, with those involved working together to define and review. Now while that concept is well-adopted in more agile organisations, those organisations that have remote development teams can struggle with some of the implementations.
However, it’s not just IT development. The concept of collaboration should be present for any change, any time that an organisation progresses, especially within the organisation itself. And that’s where a number of organisations fail.
Why require a signature?
What does the evidence say?
So where does that leave us?
- Complete the analysis in terms of understanding when the process can continue.
- Engage with service users to understand what they need out of the process, what their engagement should be
- As a team, choose a default option, either they progress by default or they pause by default
- Help the team define the rules that govern the exceptions
- Implement a training and induction programme for ensuring that everyone knows how to apply the rules
The Real Issue
I simplistically take the view that Service Design is the concepts and methods of Design Thinking applied to making services work better for their customers. It’s a definition that works in the circles I most commonly move in, i.e. directors, programme directors, etc. It allows me to set the stage in which service design and design thinking both play.
However on the same stage, we commonly find KPIs, OKRs, Business Architecture, etc. And the stage starts to look crowded very quickly. We also start to see people pulling in different directions, like someone has let a mouse loose in the chorus of an Italian opera.
Operas and plays have directors, often many directors each responsible for their own domain, but with one artistic director responsible for the overall vision.
Now imagine what would the stage look like if the director asked the question “How might we…..?”.
It’s the opening line of many a design thinking ideation round. And it serves many purposes, explained better by others elsewhere.
Taking the stage analogy further, I hear questions such as “How might we produce more colourful costumes?”, “How might we light the back of the stage better?”, “How might we fill this part of the stage?”.
All of them are good questions and relate to the specific problem that has been uncovered during the discovery phase.
What they’re not doing is thinking of the entirety of the show. They just resolve the problem that was uncovered for their part of the show.
How might we approach this differently?
What they’re not doing is asking “How might we aim to deliver a better show?”
Let’s look at that question more thoroughly.
It’s got the typical format of “How might we…?” introducing the concepts of inclusion, a shared problem, and an indication of possibilities and potential.
I didn’t stop at the simpler question of “How might we deliver a better show?”. That’s where service design typically fits.
If we step back from the stage and consider an organisation, even applying service design in this way would be a stretch. At this scale, we’d be trying to apply service design to the whole organisation, e.g. how might we deliver better services? Where typically each service would have its own change activity, often in the form of design sprints, etc. Instead, the simpler question of “how might we deliver a better show?” could be translated into a top-down design question for an organisation of “how might we deliver better products and services?”, “how might we become a better organisation?” or similar organisation-wide design questions.
However, the question I introduced earlier focusses on the aim, not necessarily the end result. It asks about how might we aim to deliver. In focussing on the aim, it allows us to explore the goals and how goals are set. It leads us to question what goals would be required in order to deliver a better show. In understanding the goals, we have to understand what good looks like, what counts as successful and not just in the eyes of the board, but in the eyes of customers. If we set the concept of goals smart enough, this could easily set the scene for continual improvement.
Alignment with Business Architecture
Back to the organisation, now that we’re asking about the aims, and we’ve looked at the goals, we can start to see how the goals for the enterprise could be set. This brings Service Design up to the area where it aligns with Business Architecture. While this may seem at odds with a top-down approach of setting KPIs, we have to ask the question of why wouldn’t we want to develop an organisation that is driven by achieving its goals that deliver value to customers?
Alternative Business Motivation
By combining Business Architecture with Service Design, there is the possibility of redefining the concept of Business Model Modelling. Typically that’s a top-down approach, modelling external influencers, assessments, goals, objectives/outcomes, etc. Taking the combined service design/business architecture approach would result in metrics that matter to customers as the metrics percolate up through the organisation, not cascade down as is more common.
Whereas the concept of One Metric That Matters may suit startups as they redefine/focus on a different metric per stage of development and growth, it would not be expected to change as often in a more mature organisation. Instead, we may see a single metric that is of most interest for a cycle of improvement. But here’s the clincher – that metric would be an aggregate of the metrics defined by exploring the problem space with customers, not one that’s defined by an executive board.
However we may see a situation where an executive board decides to steer the organisation away from its current model towards a different business model. In that case, we would consider a more top-down approach.
There are plenty of methods for conducting due diligence, whether for partners, customers, suppliers or mergers. They’re lengthy and they’re expensive. There are times for adopting principles of formal Business Architecture, such as capability matching in M&A situations. But no matter what the deliverables indicate, there’s a useful and quick check to perform as a balance.
I’d like to introduce the quickest method for evaluating a company.
- Check the state of the washrooms nearest the directors
- Check the state of the washrooms in the middle of the office, e.g. where developers work, where finance work, etc
- Compare the two and evaluate according to the 4 box model below
The Simplified View
The simple view consists of a 4-box model with two axis; vertical for the quality of the director/board/exec washrooms and horizontal for the quality of the employee washrooms. That leaves us with 4 quadrants to review:
High quality for director washrooms, high quality for employee washrooms. This the ideal situation. Comfortable for all to work in, with employees respecting their organisation space.
High quality for director washrooms, low quality for employee washrooms. This is a poor situation. It implies one of a few cultural attributes. Either:
- the directors think that they are worth more and merit more than the workforce,
- the directors do not work closely enough with the workforce (and so do not see the disparity) and/or
- the employees don’t care about the quality of the environment (probably resulting from not feeling respected)
Those fall into 2 different categories. The first two fall into whether there is a disparity in provision. The third falls into maintenance and behaviour in an environment.
Low quality for director washrooms, high quality for employee washrooms. I’ve never seen this exist. In all the organisations I’ve work for or consulted for, directors have washrooms of at least equal quality to that of the workforce.
Low quality for director washrooms, low quality for employee washrooms. At least their is parity in these organisations; everyone shares the same facilities. Typically I find these in public sector organisations where money is more importantly spent on providing the services to public rather than on office accommodation.
The More Complex View
The 4-box model gets us to the point of a very quick analysis. But thinking about it further, the relationships are slightly more complex. Hence the revised version:
The revision version uses the same axes as in the 4 box model, but hasn’t been restricted to just the 4 boxes. Instead we’ll take a closer look at the relationships between directors and employee washrooms.
Firstly, the box that related to low quality of director washrooms and high quality of employee washrooms has been extended to a triangle to cover half of the chart. This section, highlighted “Do not exist” relates to any point of the chart where directors have worse quality washrooms than employees.
On the left, we have a basic minimum standard. It’s not an absolute minimum, but one that covers a point at which employees are not being respected.
The top left is similar to that in the 4 box model, again highlighting where directors do not walk in the shoes of the employees.
That then leaves us with a blue area covering an acceptable region. This is the region in which behaviour of the directors matches that of the workforce, with no undue disparity and more a shared “we’re all in this together”. Even with the typical stretched finances of public sector organisations, we should be careful not to stray too far to the left that the lack of care in maintaining washrooms starts to be reflected in the quality of services provided by the workforce.
Despite being British (or perhaps because of being British and very British problems), I couldn’t bring myself to call this the “toilet principle”. It was too disparaging and cast the wrong tone for what I intended. Similarly, the lavatory principle didn’t work. The Bathroom Principle sounded good apart from the ambiguity of bathroom=lavatory or bathroom=room with a bath in. I settled on the Washroom Principle as it should be obvious to all (even those in the United Kingdom) which room I mean.