Agile Office Design

Over the last eighteen months the Media Suite team has come close to doubling in size.

Because hiring the right people is the single most important thing to us, we realised pretty early on that in order to keep finding the best people we needed look to outside our geographical location. We have embraced remote-working, not just for the members of the team spread across New Zealand (and internationally), but for those based in Christchurch as well. I would say that on any given day around half of the team will choose to work from a location other than head-office.

At first, this remote-working culture alleviated pressure on our existing office space. We embraced, then embedded tools like, Zoom (group video conference), Slack (team chat) and ScreenHero (one on one screen sharing) in our daily work. The last year has convinced me that the right people, with the right tools, can work successfully from almost anywhere. The team are no longer coming to the office to work, they’re coming to the office to collaborate, to connect, to create and to communicate – and that has revealed some unexpected shortcomings in our current space.

How we are working is dramatically reshaping what we need. Despite our growth we do not need more fixed desks. We are hungry for more collaboration spaces, better video conferencing facilities, accessible breakout rooms and large social spaces – and the more nooks and crannies where you can take a Skype call, the better.


An opportunity recently arose to take over a slightly bigger space at the other end of our building. The same incredible views and lashings of natural light, but most importantly, an opportunity to transform our office space into something that functions for the team – something that reflects our values and culture and respects that individuals have different preferences and needs from their workspaces.

It goes without saying that our wish-list for our new space exceeds our budget (several times over). But it turns out we are pretty experienced at delivering ambitious projects with limited resources! And so, naturally enough, we have turned to some agile and lean principles to get our project underway.  

Our first step was identifying our functional requirements

  • Workstations for up to 25 people.
  • Workspaces that cater to different working styles (from fostering collaboration,  creativity and conversation to quiet, focus and concentration).
  • Ability to hold two large meetings or workshops at the same time without interrupting those who are working in the main office.
  • Multiple smaller break-out rooms (with great acoustics) for standups, briefings and small-group sessions.
  • A kitchen/ shared space you could have a party in.
  • A space where we can hold tech-community events of up to 40 people. 

And not forgetting the non-functional requirements

  • Protecting and enhancing the views (hills, ocean and mountains – booyah!) and natural light
  • Ensuring a warm and comfortable working environment
  • Acoustics
  • Aesthetics
  • An environment that reflects our distinct culture.
  • Avoiding work that requires a lengthy and expensive building consent (no moving of fire sprinklers or structural elements)

We then put together an ordered backlog and figured out our Minimum Viable Product. Our MVP includes exciting requirements like new walls, toilets, power, plumbing and internet. After consultation, it seems in order to ‘go live’ we also need fresh paint, new carpet, sit-to-stand desks throughout and a pretty sweet new kitchen.

Acoustic products to help dampen sound.


Other items ranking high in the backlog include

To help visualise the space and communicate the design ideas I built a 3D model of the layout in SketchUp. I found this pretty helpful when discussing ideas with the team and various suppliers. Being the geek I am I even bought the mobile app which lets me pull it out on my phone whenever the conversation turns to office design.

We’ve worked through our MVP and and some of the backlog to set a responsible budget based on preliminary estimates from various trades and suppliers. Our budget should be just sufficient to get us kudos at our launch party, but it’s definitely not going to cover everything we have on the wish list. It’s already pretty clear that our budget constraints will force us to think critically about our priorities.

We’ve chosen a builder on a personal recommendation and we’re contracting on a time and materials basis. That obviously requires a high level of trust and communication on both sides to work well, but it allows us to respond to opportunities, to save cost or make intelligent reprioritisations, as they are revealed in the demolition and build phases.

We’ve assigned someone at our end to manage the project and given her the authority to make decisions. She is having regular walkthroughs (standups) with the building team to answer any questions, provide guidance and keep the rest of us in the loop.

Once we’ve moved in and seen the new space in action I suspect we’ll have some new ideas – so we’re planning on making sure we have a little budget reserved for some post launch tweaks too.

I’m looking forward to seeing how some agile and lean thinking helps shape our agile space over the next few months. Perhaps there will be a follow up to this after launch but for now… the demolition begins.

Porting the ZX Spectrum Hobbit to OSX

Back in 1982, in the early days of the 8-bit computer era, The Hobbit, a somewhat remarkable game was released on the ZX Spectrum.

Although built in Australia (by Veronika Megler and Philip Mitchel for Beam Software), in the UK it is a cultural Icon.  Veronika went on to a distinguished career at IBM (where coincidentally I also spent several years), working with big data, and is now a big data solutions architect at Amazon Web Services.  For anyone interested in the game, beyond this short blog post, find it here

What made The Hobbit different than other text adventure games of the era was that the game was different every time you played. The characters within the game went about their routine much the same way as the player did, and were (largely) subject to the same rules as the player. Whilst this might seem like a “well, duh!” situation now, thirty years ago, with 48K to play with, it was actually a really big deal.  The other major difference was the quality of the parser; It will understand commands such as “say to Thorin ‘climb into the barrel’ then throw the barrel through the trap door and jump onto it”.

The opening location of the game will be familiar to anyone who was a (slightly nerdy) teenager in 1982…

As someone who had never done any development for the Mac (but plenty on the Mac), and had no experience of Swift, The Hobbit seemed like an interesting “Hello World” application to learn a bit more about OSX (and by extension iOS) development.


The Troll’s clearing – avoid at night-time…
The Troll’s clearing – avoid at night-time…

As a learning experience, it was great, as it had simple AI, language parsing, lots of vector illustrations for the “chrome” around the application (there is a lot of fun in drawing old-school computers!).

The chrome was all done using Indeoo iDraw, which was subsequently purchased by Autodesk (and is now called Autodesk graphic). It is basically Illustrator, but inexpensive and minus a few features. I got very sick of drawing keyboards, particularly as the ZX Spectrum has a LOT of text on the keyboard! It is pretty easy to create (almost) photo realistic illustrations of physical objects from scratch with iDraw.

In order to justify (to myself) the effort of building the game, I felt it needed to add something beyond that which could be gained by emulator play, so I added a dynamic map of the game which shows where any of the characters are at any given time, and what they are up to.  

Of course, that meant going back to iDraw and drawing lots of little character avatars…

The Classic 48K Spectrum (a great looking little machine)

I opted not to reverse-engineer the original application (which is Z80A Machine code), largely building the game world through emulator play and observation. The original game uses early text-compression to fit the whole thing into 48K, so arguably this approach was actually easier.


The original game was developed on a Dick Smith System 80, a Taiwanese-Australian clone of the Tandy TRS-80. Sadly, the game was never released on the “Trash-80” (as the decision was made to port to Spectrum in order to have graphics), so we can only speculate as to exactly how the game would have looked.  

Dick Smith System 80

Nevertheless, it gave me an excuse to draw a TRS-80 and monitor and provide a green-screen version of the game…


Playing the game in 1982

The original game gives the illusion of the story unfolding by writing the text to the screen a character at a time teletype-style and then scrolling up line-by line (with pauses when graphics are displayed).  Whether this illusion was deliberate or a limitation of the processing speed of the Spectrum is open to debate. It was a pain to emulate, involving (mostly) decoupling the output from the engine , and using a thread to slowly churn the output out the screen (unless the game is paused or you are restoring a saved game, in which case it needs to not output at all or load up instantly).


Apple don’t seem to be able to decide how they want to handle their coordinate systems, and some of Cocoa used bottom left as the origin and some uses top-left. It changes from OS to OS (so Yosemite made it more consistent and some of the graphics on the map started to render upside-down – one day I will fix it). Similar issues with Z-order; X-Code is far from world-class for non-storyboard applications (and given the option again, I would use storyboards).

Overall, it was a good introduction to Swift, although “Hello World” should probably not take several hundred hours – maybe using the Swift Playgrounds in XCode would have been a saner way to grips. Since finishing The Hobbit, I have had absolutely no requirement to use Swift…. Oh well, it was fun… I think.

Find out more here.