Lose a member, make a decision

Surprisingly, losing a member of our three person team in the first week wasn’t all bad. At a basic level we lost pure man hours; we also lost a unique skillset. On the other hand, this event forced us into decision in a number of key areas that would have a positive influence on our project—planning, scope, and task distribution.

Planning was now critical; we had to maximise our time and avoid bottlenecks wherever possible. The scope of the project was tightened up immediately and broken down into manageable chunks with desirable stretch goals to keep us pushing. We focussed on undertaking work in line with our current skillset, to avoid delays that may occur in non-key learning areas such as software familiarity.

The loss also meant that communication would now be simplified to a single channel between myself and Carl, ensuring that it would be as effective as possible with minimal delays, across a broader range of media.

Continuous planning is key to success

A huge amount of effort went into planning at the start of the project with the main aims of continuous clarity and uninterrupted workflows. This was carried out in the communal online documents of Trello and Google Sheets, along with Whatsapp and Appear.in for video conferencing. The entire project schedule was mapped out, including buffer weeks prior to deadlines and compensation for any holidays that were pre-planned.

Figure 1: The Fūdogotchi Trello board (https://trello.com/b/3IiurGQS).

Carl commented on several occasions how useful this was, effectively removing his need to think about anything other than the tasks in hand. I am very pleased with the way I started working in this area of the project, however it became clear as the weeks passed that continuous planning is necessary to work successfully as an agile team, to allow us to respond to unforeseen events and bottlenecks.

The general overall plan was in place, including detailed weekly tasks and the entire project being split up into a minimum viable product (MVP), with a couple of stretch goals to aim for. However this was all organised during the first few weeks and didn’t really change much; indeed as we worked into the stretch goals we included some (search for new seeds out in the wild with GPS and your adventurer’s map!) and abandoned others (find other grower’s using GPS & BLE!) with no emotions clouding our judgement; precisely how agile should work.

Week Task
1 Complete project plan and choose app idea
2 Complete all wireframes
3 Create pitch videos
4 BUFFER
5 AR development
6 GPS Development
7 Bluetooth Development
8 Review & Presentation
9 BUFFER
10 Reflection
Figure 2: Basic project timeline taken from our Google Sheet (https://docs.google.com/spreadsheets/d/1s7fmdlbeQ_hx4gCgwQJLERoqQVb1hlHVd8CvYafP5Ao/edit?usp=sharing).

Yet somehow I feel we could have had more granular control; with the advantages of direct communication and minimal organisation between just two team members, there was the possibility of daily plans and standups which perhaps we didn’t take full advantage of. We were in communication every single day through Whatsapp, Trello and our Google Sheet, but that is passive communication as opposed to active communication such as video and voice calls, which we did about 3 times per week. Like our weekly webinars, they were always the most useful of sessions.

Burnout isn’t paradise…

During the first half of the project I worked too much. I was conscious of providing Carl with enough direction to avoid him not being able to carry on with his tasks so I spent every spare minute meticulously planning, researching and designing to avoid any bottlenecks. The first hand-in at the halfway point of the project required me to learn video editing from scratch which was another huge effort. Following this my momentum suffered and my output dropped; coupled with two pre-planned holidays I struggled to maintain productivity, however an interesting balancing mechanism occurred.

Carl, who himself had struggled with the pace at the start of the project, found that he really began to accelerate as we hit the main development phase. It was during this time that he naturally took the lead in terms of moving the project forward, requesting specific material from me which really helped to guide me through to the project’s conclusion.

Play to your strengths

The initial mantra of “total learning”—spreading work out equally to ensure all team member were exposed to all areas of the app for maximum learning opportunities at the expense of the final outcome—was scrapped as soon as we became a two man team because it was deemed unfeasible. Our situation had changed; we were now in a fight against time to produce an end result worthy of our aim.

To this end we split the workload right down the middle, with Carl taking sole responsibility for all of the programming and code, whilst I took the lead as project manager and focussed on design, user-experience, and video editing. This approach requires post-project tutorials between Carl and I to demonstrate the techniques we used to achieve success.

The outcome is positive; we reached our goals and whilst I was unable to improve my coding abilities (and likewise Carl his design skills) there were still plenty of opportunities for both of us to learn new skills, whilst honing our existing ones.

Blender bonanza!

Video editing has been a core part of our project. Based on the fact that I was solely responsible for design, I made the decision to try and present every avenue of our project as professionally as possible.

I spent a lot of time planning the videos; reading cinematography forums, analysing similar videos for their pacing and editing, storyboarding the shots, sourcing appropriate stock footage and listening to free audio tracks to support the message. I felt as though I could do no more planning, but the fact is you can always do more.

Figure 3: Detailed analysis in our Goole Sheet of the famous “Harmonious Design” video with Jonathan Ive (https://www.youtube.com/watch?v=8MlrwjqlVBQ). I considered emotion, timing, rhythm, pacing, cuts, audio, syllables, speech, content and meaning in an effort to recreate a similar passion in our Investor video.

When it came to editing the videos I chose Blender because it is free, open source software (FOSS) so I knew it would be available to Carl when it came to sharing my techniques. It took about a week to become fluent in the program’s video editing mode thanks in no small part to an excellent YouTube channel by Mike Meyers.

Figure 4: Blender video editing tutorials courtesy of Mike Meyers a.k.a. Mikeycal on youtube (https://www.youtube.com/user/MikeycalDOTcom).

It has become apparent that video editing is a complete profession in it’s own right; if you want to produce anything professional you have to invest time into designing the tiny details.

Documentation drives deliverables

Continuing my philosophy of trying to work as professionally as possible in all areas of the project, I took on the challenge of documenting the entire app, leaving Carl with no questions as to how he should proceed in any given situation.

This worked well at the beginning of the process, especially regarding the documentation of the onboarding experience for first time users with our mascot, Dr. Greenfingers. I provided Carl with designs for each screen, showing the layout of UI components, how they were to be animated, and the instructions that Dr. Greenfingers would provide to the user.

Figure 5: Sprite sheet for the virtual plant watering control (http://docs.fudogotchi.com).

However I found myself quickly being overtaken by Carl’s progress, and began to rush screens out for different areas which inevitably led to holes and incomplete work in the process. Looking back, it is clear that I should have completed a full set of wireframes for Carl before moving on to the high fidelity rendered visuals to ensure all potential issues could be addressed early on. I was attempting to kill two birds with one stone, and though my ability at creating rendered visuals at speed is impressive, it is no excuse to bypass a tried and tested process.

Another challenge with documentation was the scope of the project; I was attempting to provide Carl with information for the stretch goals as well as the MVP, should he manage to reach that stage of coding. This itself is an imbalance; there is no sense in me accelerating off into the distance “just in case”; that is not how the agile manifesto works. There was also a sense of pride clouding my decision making because ultimately this is a project that I intend to deliver to the real world, perhaps as part of my final major project.

Figure 6: The agile manifesto (http://agilemanifesto.org/).

Life can only be understood backwards; but it must be lived forwards. ― Søren Kierkegaard