My friend and I started a side project in 2014. We are coworkers at a software development company that predominantly builds solutions for clients. We’ve learned a lot here over the years and it’s been a great place to work. The reason we started our side project was because we wanted to build things for ourselves, as opposed to building for clients.

There is nothing wrong with developing solutions for other people but we just had some problems we wanted solved and some ideas we’d like to explore. So we started spending some time outside of work talking about these ideas and we even created a wordpress site called Idealand where we documented our ideas and progressed each of the front runners through a few rounds of thinking which we called “the ringer”.

We picked one which we named “Youmiverse” and ran with that. Essentially Youmiverse was a crowdsourced creativity application encouraging users to compose stories together. After quite a bit of development our MVP came to life and we started showing it off. A friend quickly suggested we check out Joseph Gordon Levitt’s app “Hit Record”. We had a look and discovered that what Joseph had created was basically Youmiverse on steroids. After a little disappointment and feeling we’d been pipped to the post, a few weeks later we discussed some of the learnings we should take on board from this. Did this mean we should stop? Should we try and compete?  Perhaps pivot to something slightly different?  Cadyn asked me what I actually thought of Hit Record and I embarrassingly admitted “it looks cool but I haven’t actually signed up for it.  Not really my cup of tea”. He said the same thing to me. The realisation hit us like a bus, we’d somehow missed the point of our whole project and tried to build something we thought other people wanted but not something we wanted. Based on this, we decided to put Youmiverse on ice.

Next we built a mobile app game called Electric Finger Boogie which at the very least we found quite fun to play.  A few other MVPs followed ranging from web-based business collab tools to automated project quoting systems and even a meal-sharing mobile app. 

During the next year or so, while furiously knocking out one day mvp’s and trying to test hypotheses in my own time, I found myself running a large, fast-paced project at work. I was working with some incredibly talented product, engineering and business people. My role in the team was to bring them all together, and make sure that the solutions that Product designed were understood properly by the Engineering team and then to make sure that the software shipped by Engineering met the needs of the Business stakeholders.

Well I had to do that and also make sure everything was delivered on time which meant before the money ran out! We used the full Atlassian suite of tools like Jira, confluence and bitbucket as well as diagramming tools such as Lucid chart. And of course reams of excel spreadsheets listing features or bugs or roadmaps with columns of comments and version numbers with initials etc. I am a massive fan of excel but I hated those spreadsheets! So as the link between the departments I spent significant time talking to product and making sure I understood what it was that their super-detailed process flows described. Then I’d sit with the engineering team and have the product guys take them through the designs, asking questions and giving examples to make damn sure everyone was on the same page. We still often weren’t. We’d then smash out what we could in a two week sprint and I’d be running between teams removing blockers and ensuring questions were answered as quickly as possible.  At the end of the sprint I’d facilitate a session in which the engineers and product team would show the business stakeholders what we’d delivered so far and I would probe them to find out how well they felt it would solve their problems, or not. We’d get their feedback and start the process again. 

Finally, every couple of weeks the project sponsor would wander over to me and ask how we were doing in terms of the overall project timelines, given that we were allowing changes here and there and figuring some things out along the way. The project scope was a bit of a mystery but the budget certainly was not. I did not keep a detailed MS Project plan up to date with this project because it would have required more certainty on the scope than we had. We were building a platform for a business which did not really yet exist. In terms of scope we did not have a list of features from the outset and instead we had the single objective of making the business operational on this platform in a live environment before the money ran out.  So the questions were seldom along the lines of “Which features have we developed?” and more along the lines of “Do we know what we need to go live?” or “How close are we to launch?”. Of course we did write down those features that we knew we needed but we didn’t try and document all the features we thought we’d need up front. We accepted that we didn’t know certain things and that we could only find them out along the way. So without a project plan I didn’t have much to show the project sponsor, and more importantly I didn’t actually know how to answer those questions for myself. That’s a horrible situation to be in, especially for a control freak. How long is a piece of string? 

I started repurposing the Product team’s process flow diagrams and colouring in certain areas and blocks as we started each and knocked them off to represent the completion status of each of these. It created quite a powerful view when used as a progress update but It was tons of manual work to keep up to date and accurate. To try and remove part of my effort, I began working with the product team, asking them to draw their process flows with the Engineering team in mind and structuring these diagrams into an epic and user story structure. This was a bit of a shift in how they worked but when we got it right, it worked amazingly well. It also really helped them build out a product backlog of user stories when their design diagrams were made with user stories. Keeping the diagrams updated with the status colours was still very manual though.

One evening while manually updating a Lucid Chart diagram ahead of a progress update I remembered an idea I had logged in our Idealand pile, which I had named at the time “Diagram process updater”. I had documented it a couple of years before and effectively it was an idea for a web-based application which could plug into project management tools like Jira and link diagram components directly to development tasks. I realised I had somewhat proved out the viability for the Diagram Process Updater with my manual work in drawing product diagrams with epics and user stories and then updating them with status colours.

So, that weekend, Cadyn and I pumped the brakes on Electric Finger Boogie and started building the Diagram Process Updater. We soon changed the name to “Floodlight – Live diagrams for Jira” and after about a year of weekends and spare time and some blood, sweat and beers dedicated to Floodlight we launched our Jira plugin… And then there were crickets: “chirp-chirp, chirp-chirp”…

It’s become evident that while we believe in Floodlight’s potential and even have some real life customer feedback to validate that belief, our problem is that we are not simply trying to sell a product. It turns out that in order to get real value out of Floodlight, teams need to ever so slightly change the way they work.  Furthermore, this journey in building and marketing Floodlight has proven to us that the real value is not actually realised by using Floodlight which is just a tool, but rather by understanding the principles behind this new approach to teamwork, design and delivery.  Floodlight simply facilitates this approach quite well. Rules and tools are useful but principles are powerful!

This blog is a story about our side project which is also an attempt at creating some awareness of this new approach and our tool Floodlight. This is also an opportunity for us to learn and gather some feedback and ideas from people who know more than us. We have definitely not figured it all out but we do believe that this is a very simple approach that can improve delivery speed, quality and ultimately value. The plan is to structure this blog in the shape of a short story which explores some ideas around improving the way in which technology teams can deliver value by working with a shared perspective from beginning to end. We believe the empathy naturally generated by working more closely together allows teams to harness efficiencies which are otherwise lost in translation and evaporate along the journey from idea to delivery. This is the first chapter of the story. The rest is not written yet…

Please give the 2 min video a watch and if you use Jira, give Floodlight a whirl and tell us what you think