It is now 139 days since I arrived in Hong Kong. A huge amount has happened since my last post and I want highlight some events that have played a significant role in improving the productivity of the engineering team as well as the activities that have brought us nearer to delivering our platform.
Delivery of Feature Sets 1 and 2
I wanted to ensure that we could demonstrate the delivery of a feature set at the earliest opportunity. The purpose of this activity was not only to give the business and product teams a functioning application that they could experience but also for the engineering team to align their tasks towards a common and well defined goal. It would also give me clear indication of ability of the engineering team to build, deploy, test and deliver all of the components that comprise our platform and to identify and resolve any inefficiencies in our processes that would demand greater automation.
In order to deliver Feature Set 1 in time we had to better organise and focus our individual tasks. We also had to put in extra time in form of late nights and weekend work. For a young organisation that’s just the cost of doing business. While there are well understood risks associated with overworking, my personal opinion on this matter, one that has been informed by over two decades of working in high performing engineering teams, is that the benefits vastly out weigh the costs, not only for the organisation as a whole but, also for younger members of the team that are working with new technologies and honing their skills. Obviously periods of overwork must be followed with periods of reduced intensity and we have used the these periods for planning activities and defect fixing.
I don’t expect my team to do anything that I wouldn’t be prepared to do myself and right now I have very little to distract me from work, that means for me starting early, finishing late and putting in weekend work is the norm. I enjoy the bulk of activities in which I am engaged and that makes it very easy to put in the time. At this stage our delivery roadmap the backlog of tasks is large and growing as is only to be expected. On the upside we actually scoped and delivered a two week sprint finishing all the tasks in the sprint with everyone completing their allocated 21 story points. To be honest I don’t expect us to be in a position to realistically scope sprints with 21 story points and fully burn them down for at least several more iterations but, proving that we could do this was psychologically important and helps to build discipline.
Delivering and testing Feature Set 1 uncovered a raft of issues in all aspects of the product and platform development, just as we expected, and resolving these before delivering Feature Set 2 was an obvious priority for the team. The Feature Set 2 drop was a far more optimised affair and we are firmly moving in the right direction with respect to execution of our deliveries.
Having a functioning application, albeit one where some API’s are stubbed (more on stubbed APIs later), allowed us to expose it to our fledging user community. For all of us at YOU Technologies Group reaching this milestone at such an early stage was simply brilliant. I can’t thank our community members enough for giving us their valuable time and feedback and I hope you will stay with us throughout our journey.
The insights provided by our community and the simple act of delivering our application to a trusted group of supportive users, proved to be invaluable to us. Not only did we obtain information on the overall user experience at an early stage in the product development but we also uncovered and resolved an host of problems associated with delivering applications to real users rather than QA testers. It took a massive effort from everyone in the team to arrange and execute our community event but the rewards far out weighed the costs and ultimately it was a lot of fun. Kudos to Harry Fu, our man in Singapore, for driving community development. You can read more about our community event here.
Eliminating Dependencies Between Teams – NoOps
One of the assertions of the NoOps principle is to eliminate dependencies between application and operations teams. By doing so it allows both teams to focus on a their specific activities and increases their productivity. What we have found is that with the use of microservices and APIs we can also eliminate dependencies between different application teams.
Our Client Services team are coding iOS and Android applications to APIs provided by the Middleware team; the Middleware team are coding to APIs provided by the Back Office team and the Back Office team codes against APIs provided by third parties. While such an approach is nothing new what I have found interesting is how the discussions around the API design force the teams to clearly state their understanding of the system and how it will be implemented. Agreeing an API specification is essentially a contractual negotiation between technical teams that allows them to qualify their understanding and verify their assumptions. As soon as the API specification is agreed, stubbed APIs (API’s that mock the expected behaviour of the fully implemented system) can be provided quickly and allow both teams to continue with their work separately.
DevOps, SDLC and Full Stack Developers
Everyone in the engineering team can build and deploy our platform on their laptops. We have no dependency on shared environments for carrying out engineering work. What is more, anyone in the engineering team can look at the code created by other teams and attempt to learn it.
We purposely hired individuals that expressed an interest in becoming Full Stack Developers and we are making sure they have what they need to achieve this goal. One proposal that we are considering is for everyone in the engineering team to write one microservice in GO. The idea is that everyone (including myself) will gain a significant insight into the platform by having to implement a microservice in the Middleware. This will help to ensure that we all ‘speak the same language’ and communicate platform concepts with better precision and understanding.
The importance of Emojis
Most of people I know in IT now use Slack as their preferred chatbot. I’m delighted to say the team has started to update Slack Emojis with a range of images and memes. Here are a few of my favourites:
To be honest I still don’t fully understand the precise context in which the doge meme should be used, but it is the emoji I use most often…
Generally used to strongly agree or disagree with a decision or stated point of view.
I’d like to use the yaoming meme more often but there just hasn’t been much call for it :).
I’ll finish this post off by asking readers to share their favourite emojis and memes. In the next post I expect write more about security, behavioural driven development and the payments industry.