As you go about your work you’ll come up against walls. Some walls will be blank and boring blockers to progress. These need decoration; spraying with layers that confer meaning. So pick a corner and start doodling. With a new perspective, you’ll find a way around the blockers. Other walls will come with messages – by design or default – leading you in a certain direction. If this isn’t where you want to go, you’ll need to plot your own course by subverting or overwhelming the prevailing visuals.
This is your challenge, and your opportunity for innovation: to disrupt the established visual environment with new ways of looking at the world that, in turn, unlock new ways of thinking. If you think you could make your organisation more agile with some disruptive visual thinking, read on for my experience [on the Organisational Agility channel of ThoughtWorks Insights].
We’ll explore the development of the Fireballs in the Sky app, designed for citizen scientists to record sightings of meteorites (“fireballs”) in the night sky. We’ll introduce the maths for AR on a mobile device, using the various sensors, and we’ll throw in some celestial mechanics for good measure.
We’ll discuss the prototyping approach in Processing. We’ll describe the iOS implementation, including: libraries, performance tuning, and testing. We’ll then do the same for the Android implementation. Or maybe the other way around…
Simple game scenarios can produce the same outcomes as complex and large-scale business scenarios. Serious business games can therefore reduce risk and improve outcomes when launching and optimising services. Gamification also improves alignment and engagement across organisational functions.
This is a presentation on using games to understand and improve organisational design and service delivery, which I presented at the Curtin University Festival of Teaching and Learning.
(Don’t be concerned by what looks like a bomb-disposal robot in the background.)
The slides provide guidance on applying serious business games in your context.
Sometimes, the difference between incremental and iterative (software) product development is subtle. Often it is crucial to unlocking early value or quickly eliminating risk – an iterative approach will do this for you, while incremental will not.
Incremental vs Iterative
Let’s review the distinction. Incremental means building something piece by piece, like creating a picture by finishing a jigsaw puzzle. This is great for visibility of progress, especially if you make the pieces very small. However, the inherent risk is that an incremental build is not done until the last piece is in place. Splitting something into incremental pieces implies the finished whole is understood (by the jigsaw designer, at least). If something changes during the build, like a bump to the table, all of your work to date is at risk. Future work – to finish the whole – is also at risk of delivering less than optimal value, if our understanding of value changes during an incremental build. Much development work done under an agile banner is in fact incremental, and therefore more like a mini-waterfall approach than an essentially agile approach.
Iterative, on the other hand, means building something through successive refinements, starting from the crudest implementation that will do the job, and at each stage refining in such a way that you maintain a coherent whole. You might think of this like playing Pictionary. When you are asked to draw the Mona Lisa, you start with (perhaps) a rectangle with a circle inside. If your partner guesses at this point, great! If not, you might add the smile, the hair, the eyes. Hopefully, your partner has guessed by now. If not, embellish the frame, add the landscape, draw da Vinci painting it, show it hanging in the Louvre, etc. Your risk exposure (that time will expire before your partner guesses) is far lower with an iterative approach. With each iteration, you have captured some value. If your understanding of value changes (eg, your partner shouts something unhelpful like “stockade”), you still retain your captured value, and you can also adjust your future activities to accommodate your new understanding.
I think I capture all of this in the diagram above. If you’re having trouble articulating the difference between incremental and iterative (because both show similar signs of progress at times), or you’re concerned about the risk profile of your delivery, refer to this handy pocket guide.
Sounds pretty simple, doesn’t it? That’s an easy project to deliver, right?
Wrong.
Why would we do a like-for-like (L4L) project? The IT group may want to upgrade to a new system, because the old one is broken, or because they’ve found something better. Maybe we want to avoid re-training users. Or, maybe our L4L project is hiding in a larger project. It could be phase 1, in which functionality is replicated, while new value is delivered in phase 2. There’s no strong pull from users for this L4L project, so to avoid ‘disruption’, the project plans to hot swap a technology layer while otherwise preserving functionality, much like a magician yanking off a tablecloth without disturbing any of the tableware. However, someone is about to have their dinner spoiled.
A clarification. L4L exhibits some of the characteristics of refactoring. But refactoring deliberately tries to stay small, in time and cost. The success criteria are also easily established, for instance, as unit tests. I’m talking here about replacing one non-trivial IT system with another, especially if the target system is primarily bought rather than built.
The Key Problem
Too many constraints
Framing a project as L4L is not just demonstrably incorrect, it is lazy to the point of negligence. The L4L framing is incorrect because it can never be achieved. The current technology solution has constraints, and business processes have evolved under the current technology constraints. But the new solution will have new technological constraints. There is no chance the two sets of constraints will be equivalent (if they are equivalent, why would you bother changing systems?) Therefore, business processes will be forced to evolve under the new solution. If business processes are changing, this cannot be a L4L project, and the framing is incorrect.
It’s irrelevant whether we’re talking about L4L functionality or L4L business outcomes. As above, L4L functionality is a logical impossibility. If we’re talking L4L business outcomes, which users are going to support a disruptive change in functionality in order to be able to achieve exactly what they do today, and no more?
The L4L framing is lazy because it discourages critical thinking. Stakeholders will confuse the apparent simplicity of framing with simplicity of execution, meaning they will be less engaged in resolving the thorny problems that will inevitably crop up. This is especially important for project sponsors and other senior stakeholders. The business will not be engaged in a process that gives them no voice. This will be doubly so if, as above, the project is not actually like for like, and the deleterious changes in business process are being driven by IT.
The real negligent laziness, however, is in assuming that collectively we haven’t learnt any more about how to deliver business value since we implemented the current system. The current system is probably five to ten years old, and inevitably has shortcomings – why would we copy it? We might, at great effort, be able to figure out what the system is capable of, then build this, but this is far more than users actually use, and entirely different from what they want. This lazy framing leads to much more work than would be required if we simply went to the business/customers to understand what they really need at this time.
You’ll end up taking longer, costing more, and delivering poorer outcomes if you frame your project as like-for-like.
More Problems
Like for like framing is the key problem, but it spawns a host of other problems:
Inflexible execution means no ability to respond to change
Reporting misses the fact that there are two different things to report
These are substantial topics in their own right. I’d like to finish this post sometime, so I’ll try to pick up these threads in detail in future posts.
What Might Happen?
So, how might an L4L project play out?
Well, it’s hard to predict the future, but like Plutonium , L4L projects are unstable and tend to disintegrate. While a typical agile project is self-correcting, in that everyone sees the value, scope can be adjusted to meet time, and so on, a L4L project has no give.
When estimates are discovered to be optimistic – as complex workarounds will inevitably be required to deliver old results on new technology – the only option for a true L4L project is to run late. Or, we expose the L4L fallacy by making functional or non-functional compromises. Likely, it will be a combination of both.
Stakeholders who were reluctant from the start are now in an even worse position. They originally stood to gain nothing but disruption, but now they definitely lose out. They may begin political manoeuvring to make the project go away. Governance will probably start sniffing around if this late, costly project is not delivering value.
Again, at this point, there’s not much room to move in a L4L project. There may be nothing of value delivered. You stuck with either writing the project off, or toughing it out to an expensive and unsatisfactory conclusion. You may even tough it out only to write it off later. Of course, you can change the way you are doing things, but that basically means starting over. So, why not get it right from the start?
The Solution
The solution is, of course, to frame the project as delivering new value.
Project framing report card
Like-for-like
Delivering value
Technically can’t be achieved
Value drives right behaviours
Business disengaged – everyone wants to go last
Business engaged – everyone wants to be first
Analysis & design = reverse engineering
Break current constraints for better solution
Wasteful and high risk
Efficient and low risk
Even if you’re being forced to replace a system, make sure you go out to the stakeholders and ask them what they want to make their lives better, right now. This is the only way you really get their buy-in, the only way they’ll make do with less here and there because they’re getting more overall, the only way they’ll be engaged in resolving difficult delivery problems, the only way they’ll back you up instead of sell you out when things get tough. It’s also the only way you’ll avoid perpetuating those arbitrary constraints you inherit with a L4L project.
Next time you’re asked to start a L4L project, start by changing the framing.
Imagine you’re in the middle of a big software project. Maybe, you’re replacing an internal system, or something like that. You make an observation: when asked to prioritise, everyone wants to go last. They want to hang on to the status quo for as long as possible.
Instead of beating down your door to get their hands on desirable new features, they are all running for the exits in the hope that your project fails before it impacts them.
This is logical from an economic or financial perspective. If value is to be destroyed, then you should destroy the items of least value first, and of most value last, as you maximize value-in-use in this scenario. When your action would result in reduced future cash flows, the longer you wait before acting, the better.
Imagine your home was being gradually inundated; floodwater seeping in and rising toward the ceiling. Imagine that you were waiting for rescue and knew that you could take some things with you. You might pile up your possessions in the living room. Where would you put your most treasured possessions? At the top of the pile, of course, where they would be last to suffer water damage. Though you don’t know when help will arrive, when it does you will know you have saved only the most important stuff.
Maybe, though, the new solution is just as good as – if not better than – the old, but people fear change and disruption. If the level of disruption is high, and the new solution is no better, this is indeed value destruction. However, if the disruption is less than feared, and the new solution does offer benefits that haven’t been effectively sold, then this needs to be demonstrated to stakeholders so they come seeking change. This requires senior leaders to change the framing of the project to highlight the value created, not the value destroyed. It also requires the delivery team to support the new framing by delivering a high profile change that adds value.
Just as value-creating projects maximize value delivered by creating the items of largest value first, value-destroying projects minimize value destroyed by destroying the items of largest value last. So, if your prioritisation looks backwards, ask seriously if your project is destroying value.
Visualisation is a topic I love talking about – especially demonstrating why it’s good for business – and presenting with Ray Grasso was a lot of fun.
Here’s the full video of the presentation.
If you want to pick and choose:
I start with the historical perspective and current state
5.40, Ray starts the IMO story
28.55, I start the call centre story
41.53, Ray starts the NOPSEMA story
54.39, We take questions
I’ve been talking to people about the event, and they always say something like:
“I’m such a visual person. I love it when people explain things to me visually.”
No-one ever says:
“Don’t show me a picture.”
Words are important, of course, as are other means of communicating. We all have multiple ways of processing information. However, visual processing is almost always a key component. Consider my friend the lawyer, who remembered cases because her lecturer pinned them on a map and illustrated them with holiday snap shots. I’m sure you have a similar example.
So we “see” that data visualisation is good for humans. And what’s good for humans is good for business. Key business outcomes include engaging communications, operational clarity, and unexpected insights.
Enough words. Browse the slides below or watch the presentation above.
So, you want your mobile or tablet to know where in the world you’re pointing it for a virtual reality or augmented reality application?
To draw 3D geometry on the screen in OpenGL, you can use the rotation matrixes returned by the respective APIs (iOS/Android). The APIs will also give you roll, pitch and yaw angles for the device.
What’s not easy to do through the APIs is to get three angles that tell you in general where the device is pointing – that is, the direction in which the rear camera is pointing. You might want this information to capture the location of something in the real world, or to draw a virtual or augmented view of a world on the screen of the phone. The Fireballs in the Sky app (iOS, Android) does both, allowing you to capture the start and end point of a “fireball” (meteor/ite) by pointing your phone at the sky, while drawing a HUD and stars on the phone screen during the capture process, so you’re confident you’ve got the right part of the sky.
Azimuth and elevation
Roll, pitch and yaw tell you how the device sees itself – they are rotations around lines that go through the device (device axes). But in this case we want to know how the device sees the world – we need rotations around lines fixed in the real world (world axes). To know where the device is pointing, we actually want azimuth, elevation and tilt, as shown.
The azimuth, elevation pair of angles gives you enough information to define a direction, and hence capture objects in the real world (assuming the distance to the object does not need to be specified). However, if you want to draw something on the screen of your device, you need to know whether the device is held in landscape orientation, portrait orientation, or somewhere in-between; thus a third angle – tilt – is required.
Azimuth is defined as the compass angle of the direction the device is pointing. Elevation is the angle above horizontal of the direction the device is pointing. Tilt is the angle the device is rotated around the direction in which it is pointing (the direction defined by azimuth and elevation angles).
We can get azimuth, elevation and tilt with the following approach:
Define a world reference frame
Obtain the device’s rotation matrix with respect to this frame
Calculate the azimuth, elevation and tilt angles from the rotation matrix
It will really help to be familiar with the mathematical concept of a vector (three numbers defining a point or direction in 3D space), and be able to convert between radians and degrees, from here on in. Sample code may be published in future.
Define a World Reference Frame
World reference frame
We’re somewhere in the world, defined by latitude, longitude and altitude. We’ll define a reference frame with its origin at this point. For convenience, we’d like Z to point straight up into the sky, and X to point to true north. Therefore, Y points west (for a right-handed frame), as shown here. We define unit vectorsi, j, k in the principal directions (or axes) X, Y, Z, and we’ll use them later.
What we want eventually is an rotation matrix that is made up of the components of the device axes a, b, c, (also unit vectors) with reference to the world frame we defined. This matrix will allow us to convert a direction in the device frame into a direction in the world frame, and vice versa. This gives us all the information we need to derive azimuth, elevation and tilt angles.
We’ll describe the device axes as:
a is “screen right”, the direction from the centre to the right of the screen with the device in portrait
b is “screen top”, the direction from the centre to the top of the screen with the device in portrait
c is “screen normal”, the direction straight out of the screen (at right angles to the screen, towards the viewer’s eye)
We can write each device axis as a vector sum of the components in each of the principal world frame directions, or we can use the shorthand of a list of numbers:
To get a matrix of this form in iOS, just use reference CMAttitudeReferenceFrameXTrueNorthZVertical and get the rotation matrix. However, the returned matrix will be the transpose of the matrix above, so you will need to transpose the result of the API call.
In Android, you will need to correct for magnetic declination and a default frame that uses Y as magnetic north, and therefore X as east. Both corrections are rotations about the Z axis. The matrix will similarly be transposed.
Calculate View Angles
Device elevation angle
We can calculate the view angles with some vector maths. The easiest angle is elevation, so let’s start there. We find the angle that the screen normal (c) makes with the vertical (k) using the dot product cosine relationship.
Elevation is in the range [-90, 90]. Note also from the definitions above that such dot products can be extracted directly from the rotation matrix, as we can write:
\[\vect{c} \cdot \vect{k} = c_k \]
Device azimuth angle
Next, we calculate azimuth, for which we need the horizontal projection (cH) of the screen normal (c). We use Pythagoras’ theorem to calculate cH:
\[1 = c_H^2 + c_V^2\]
\[c_H = \sqrt{1 – c_k^2}\]
We then define a vector cP in the direction of c, such that the horizontal projection of this vector is always equal to 1, so we can use this horizontal projection to calculate angles with the horizontal vectors i & j.
\[\vect{c}_P = \frac{\vect{c}}{c_H}\]
Horizontal projection of device screen normal
We then calculate the angle the horizontal projection of the screen normal (cP) makes with the north axis (i). We get the magnitude of this angle from this dot product with i, and we get the direction (E or W of north) from the dot product with the west axis (j).
Note that because we’ve only used screen normal direction up until now, we don’t care how the phone is tilted between portrait and landscape.
Device tilt angle
Last, we calculate tilt. For this calculation we also need to ensure the projection of the screen right vector aP onto the vertical axis (k) is always equal to 1. As above, we divide a by cH.
\[\vect{a}_P = \frac{\vect{a}}{c_H}\]
We take the angle between aP and the world frame vertical axis k.
Note that as the elevation gets closer to +/-90, both the azimuth value and the tilt value will become less accurate because the horizontal projection of the screen normal approaches zero, and the vertical projection of the screen right direction approaches zero. How to handle elevation +/-90 is left as an exercise to the reader.
Sample Code
Sample code may be available in future. However, these calculations have been verified in iOS and Android.
Sometimes, in a professional setting, we can see a need for change, we can even provide evidence, but we can’t get other people to see it like we do. There’s one time, however, in a social setting, when most people will agree on the need for change: at the climax of a movie when the hero faces a difficult choice between growing or taking the easy way out. Can we use techniques from movie-making to be more effective change-makers?
The Story Spline
The Story Spline summarises the classical narrative structure. Most stories have a hero. The story starts by introducing us to that hero, their passions and fears, and their world, which may at first be unremarkable. However, at some point (typically 12 minutes into a feature film), their world is changed dramatically. Then, they encounter more and more insurmountable hurdles to return to normality. Finally, they are faced by their fears and a choice: turn their back on everything they’ve learned and return to their comfortable world (boo), or take a risk and make themselves and the world a better place (yay). The story doesn’t end there; hard work remains to be done and there may be more surprises. However, when the choice is made, we know whether it’s right or wrong.
The Story Spline format parallels what we use in agile software development for user stories, elevator pitches, etc. It looks like this:
ONCE UPON A TIME … (“Exposition”)
AND EVERY DAY …
UNTIL ONE DAY … (“Inciting Incident”)
AND BECAUSE OF THAT (or AND THEN) … (“Progressive Complications”)
AND BECAUSE OF THAT (or AND THEN) …
…
UNTIL FINALLY … (“Crisis/Climax”)
AND SINCE THAT DAY … (“Resolution”)
THE MORAL OF THE STORY IS … (“Theme”)
You could try filling this out for your favourite film.
Putting it to Use
But how do we use this to affect change in a professional setting? Here, I use consulting language, but you could be doing this internally.
Cast the client as the hero
Establish the “theme”. Write THE MORAL OF THE STORY IS …
Decide what CHOICE you want the client to make
Note that this is the “crisis” moment (UNTIL FINALLY)
It’s the present moment for you and your client
So everything prior to this is in the past
Prepare “resolution” actions (may be simple, or may be an approach to discover)
Decide on your “inciting incident”
This splits the past up into the distant past and the recent past
For an explicit change initiative, this is probably the start of the initiative
Frame the distant past in opposition to the right choice
Write the ONCE UPON A TIME … AND EVERY DAY … with that framing
Write the “progressive complications” that have delayed the choice until now
Write the UNTIL FINALLY …
This is NOT phrased as you need to make a choice X
This is phrased as we are at a crisis, and the choices remain implied
Now put this Story Spline on index cards. That keeps each point short, and aids in presentation. Put some blu-tack on the back and make sure they’re in order!
When you meet with the client, tell them you’re going to review the state of the engagement before seeking to make a decision about future direction. Now, start telling the story (and tell it like a story, don’t be shy! throw the phrase “classical narrative structure” in there if you want to establish your serious credentials), sticking the index cards on the wall (or laying them on a table) as you go. This will help prompt you and keep you on track, and serve as a physical reminder of what’s been agreed so far. It’s important to seek the client’s agreement on each card as you stick it up. If they don’t agree, put it to one side (if it’s a disposable progressive complication), or engage in a dialogue about what that card should say. Presuming you reach agreement, and it doesn’t fundamentally break the story, continue in this fashion.
When you get to the crisis, the client should be prepared to recognise the “right” choice, so try to let them reach that choice themselves, and be prepared to support it. Offer ideas and be prepared with actions to implement them. The more it feels like the client’s choice, the better.
If you get the outcome you want, reassure them with THE MORAL OF THE STORY. You may not get that outcome. No guarantees. If you can’t agree on the back-story, you may want to take a recess and come back to it to improve your chances of getting the “right” outcome.
An Example
I have used this technique when consulting – see discussion of effectiveness below, but I’ll use a made-up example here:
Storytelling for change example
THE MORAL OF THE STORY IS that sometimes you have to be prepared to cut your losses and go back to the drawing board.
Note that it takes a bit of work to condense a complex situation into a few lines (I could probably have done this example better!), and each card would carry a lot of context for you and the client, which might not be discernible to the outside observer.
Effectiveness
While I’ve only used this once, it very quickly enabled everyone to get on the same page. The novelty of the approach got people’s attention, and the meeting was clearly focussed on resolving the decision at the climax. However, if I’d failed to get agreement on the back-story, we could have been in trouble. Let me know your experiences and thoughts.
Stop testing on humans! Auto manufacturers have greatly reduced the harm once caused by inadvertently crash-testing production cars with real people. Now, simulation ensures every new car endures thousands of virtual crashes before even a dummy sets foot inside. Can we do the same for software product delivery?
Simulation can deliver faster feedback than real-world trials, for less cost. Simulation supports agility, improves quality and shortens development cycles. Designers and manufacturers of physical products found this out a long time ago. By contrast, in Agile software development, we aim to ship small increments of real software to real people and use their feedback to guide product development. But what if that’s not possible? (And can we still benefit from simulation even when it is?)
The goal of trials remains the same: get a good product to market as quickly as possible (or pivot or kill a bad product as quickly as possible). However, if you have to wait for access to human subjects or real software, or if it’s too costly to scale to the breadth and depth of real-world trials required to optimise design and minimise risk, consider simulation.
Learn why simulation was chosen for the design of call centre services (and compare this with crash testing cars), how a simulator was developed, and what benefits the approach brought. You’ll leave equipped to decide whether simulation is appropriate for your next innovation project, and with some resources to get you started.
Discover:
How and when to use simulation to improve agility
The anatomy of a simulator
A lean, risk-based approach to developing and validating a simulator
Techniques for effectively visualising and communicating simulations
