No Blockers: How We Delivered Manulife Bank Mobile

This is a repost of my LinkedIn article.

A little over a year and half ago I started working at Manulife with a few mandates; help build a mobile team in Kitchener, build a high performing culture and deliver an all new, Manulife Bank Mobile experience built exclusively on native technologies. The existing Manulife Bank Mobile application had suffered from poor reviews in the App Store, it was difficult to add new features to, and was starting to show its age (both in design and performance).

Today I am proud to say that our mobile team at Manulife has released a fully native, version 2 of the Manulife Bank Mobile application in the Apple App Store (Android soon to follow). We were able to build all-new native applications on top of an all-new infrastructure in a little over ten months. These technologies and platforms were not only new to the team, they were new to the organization, being stood up by Manulife just ahead of us developing against them. The learning curve was steep, the hurdles were large and many, but we surmounted every challenge head on.

Manulife Bank Mobile in the Apple App Store

When I started with this group twenty months ago, Manulife was just starting the transformation as a technology-first organization. There were just two developers and two UI/UX designers that made up the Kitchener branch of the Mobile Team at Manulife. Only one of of each was tasked with working on the Manulife Bank application (then built on hybrid native and web technologies) with the help of a handful of offshore developers. Within a year we had grown to four UI/UX designers, a BSA, scrum masters and eight developers onsite in Kitchener and no offshore staff. (These numbers don’t include our very talented sister team in Montreal, tasked with other Manulife initiatives)

Here are some of the things that we’ve practiced on this team that contributed to our success:

  1. Work around, over or through your obstacles – I am often relentless when it comes to clearing obstacles in my path. Large organizations can have many obstacles, especially where dependencies exist—”we don’t have the resources”, “your project isn’t a priority”, “that isn’t our policy”, etc. When confronted with such obstacles I will first try to work effectively within the limitations but as soon as that becomes a hindrance to my project or its timelines, I will look at ways to avoid that dependency all together, and come up with alternate solutions. I try to instill this value in the team, often stating that, “They call it software because it’s not hard. If it was they’d call it hardware.” Meaning it’s not hard to write software and changing software doesn’t require an overhaul of a fabrication line in a manufacturing facility. If you are dependent on someone else for a solution and they can’t deliver, become part of that solution by embedding your own skill on that team. When all else fails, write a solution of your own.
  2. Organize yourselves – If your team doesn’t know what the end goal is, it’s hard for them to know how to get there and what needs to be done along the way. We’ve tried to keep one vision and one delivery goal in sight, taking incremental steps towards that goal in two week sprints. Working agile has been key, but even when agile breaks down, you have to trust that your team will keep driving on in a known direction. When you bestow that level of responsibility on people, they will strive not to let the team down.
  3. Test and/or Behaviour Driven Development – Our team doesn’t consider their work complete if it isn’t covered by a test of some variety. This is fairly standard practice in most hardened development shops, but in larger organizations testing can fall by the wayside as developers learn to lean heavily on QA departments to catch their mistakes. It’s not good enough to show that you’ve written a few tests, you need to show that your logic has 80% coverage or more. Test libraries should comprise a greater portion of a projects code base than the code itself. Prove to me that your code works on all edge cases by showing me the test results.
  4. Future Proofing – Look at your code from the perspective of the next developer or the end user. How much work will it take to add that new feature on top of what you’ve written today? How can you make a future developers work easier? “It’ll be good enough for now,” is code for, “This will be someone else’s problem later.” Build robust, small chunks of logic that can be decoupled easily. Smaller bits of decoupled codes is easier to move around.
  5. Reusability – Have you identified something that you are coding over and over again? How can you make that a reusable component within your codebase? How can you make that a reusable component in other codebases? How can you abstract away the most basic components and make it reusable anywhere? Often times spending a little extra effort to build a reusable bit of functionality saves a lot of repeated effort in the future.
  6. Automation – When I started on the team one poor developer would spend two whole days a week doing nothing but manually building and deploying applications and services. That’s 40% of a developer dedicated to something that a script should do. I had that developer spend two days to write a script that would do the work for him. He was happier and the team got 40% of a developer back. Shortly there after Jenkins became available to our group and we’ve been able to automate everything from code quality scans, test coverage, builds, versioning and so much more.
  7. Communication – It is all too easy for communication to breakdown when everyone has their head down, smashing away at a keyboard. We take time out of every to formally keep each other apprised our efforts, but beyond that there is regular collaboration between designers and developers, open channels between developers and Business Systems Analysts and Product Owners. Over communicate so that everyone is in the know.
  8. Spread your knowledge – We are constantly learning new things and the team can only get stronger as a whole if we teach each other what we’ve learned. Whether it is in the form of pair programming, coding kata’s, knowledge transfer, etc… we take the time to share what we each of us has learned. We haven’t done nearly as much of this as I’d like, but with a major release behind us I’d like to carve out a little bit more time for knowledge sharing.

I couldn’t be more proud of this team and all they’ve accomplished in the last year. What makes a team great is not the individual skill level of each member, but how they operate as a collective and push each other forward. I can’t wait to see what this young team will do next.

Do you want to work with a team like this? I am always on the lookout for great talent so send me a message on LinkedIn.