Damien is based in Lyon, France and has been working with NearForm since 2016. He recently completed a project with TELUS and is currently working with an enterprise client in the agriculture industry. Outside of work, Damien is busy chasing around his two young children. Before his days became focused on parenthood, he was a competitive ballroom dancer.
Hi Damien! Can you tell us a little about your background?
Before joining NearForm, I worked for a large company on a lot of different client projects in a range of sectors. I worked for Worldline, Europe’s first payment processor. I worked in R&D and Big Data and helped to build technical assets online. I developed a messenger application for Orange. I also worked with Daimler – so I have a diverse background.
So now you are a Delivery Architect at NearForm. What does a Delivery Architect do, in broad terms?
Delivery Architects are responsible for delivering projects for our clients. We convert what the client wants into what the team produces.
The Delivery Architect is a managerial-type role who oversees the project delivery and is a facilitator. Sometimes the Delivery Architect also takes on a more technical role. We are constantly switching between technical activities and feature activities. This means facilitating sprint planning, retrospectives and showcases, refining stories with technical guidance, reviewing code, solving issues with external dependencies, and ensuring collective thinking.
We are constantly reviewing the role. All NearForm Delivery Architects get together a few times a year, and our role is an ongoing discussion among us!
Is there typically one Delivery Architect per project?
Typically a project has a group of developers engaged with the client and a Delivery Architect helps with organisation and facilitation. However, smaller projects with just a few developers don’t need a Delivery Architect. Then, a senior developer usually leads the team.
How do you help developers?
We collect what they need (upfront development) to deliver their code. This often means removing roadblocks and resolving dependencies for them when necessary, by using problem solving and peer programming. It often means liasing with other teams to escalate their input whilst in other cases, the Delivery Architect undertakes spikes on external systems before teams use them.
Product owners often define story headlines. It is up to the Delivery Architect to refine them into details, filling the blanks, finding edge cases and turning the vision into an implementable piece of work that fits into the broader picture.
Are you checking in with developers every day?
Yes, at the scrum ceremonies the whole team gathers and shares knowledge. A unit of work is done in a two-week sprint. We have daily standups during the sprint. We always collaborate on Slack, email and any other channel we are using. We don’t wait until the end of the day to bring up issues.
And your team is based all over, geographically?
Yes, for example, when working with TELUS , who are based on the east coast of Canada, we overlapped only four hours each day with them. That can be challenging, of course, but once expectations are clear from the outset it is not an issue.
On other projects, we had talented people from Romania, Italy, Sweden, England, Ireland and France all working successfully together as a team.
Can you describe more about your projects?
NearForm provided TELUS with skilled developers to reinforce their team. We built a multichannel customer touchpoint, so customer orders could come in through any channel (web, in-store, or phone) and the orders were all captured in the same system.
Were you transforming a system they already had?
Actually, we transformed three systems into one application. The three channels were disparate systems, with a lot of legacy technology. Also, their automated processes often failed. They needed a single application for all orders. This was a greenfield project because we built an entirely new UI. It was automated as much as possible. Now, whenever interaction with an agent is needed, a customer service representative can log in, view the customer details, edit them, and then trigger automation again.
How successful was that?
We created something that was very well tested. Our design director, James Malone, designed the usability tests and real end users carried out the usability testing. After six months on this project, we helped TELUS bring to life a market-ready, user-friendly and robust system in an accelerated time frame - one that allows them increased efficiencies and improved customer service.
[caption id="attachment_300006096" align="aligncenter" width="1024"]
Damien at one of our recent workshops[/caption]
What platforms do you typically use – are they all in the cloud?
My projects are typically web applications with backends in the cloud, using AWS. Some other NearForm teams are using Azure.
How does NearForm bring the most value to customers?
Sometimes our knowledge of AWS and Azure exceeds that of our customers due to the nature of our work as consultants. In these cases, we onboard employees from within our client’s teams into the new software builds. We help improve their skills through our workshops on libraries and tools such as React and Redux.
We go in and build things, but we don’t stay forever. When we transfer the software to our clients it is workable and solves all their problems – that is success.
What are your hallmarks of success?
We transfer knowledge at the end of the project, so the client can maintain assets themselves. We go in and build things, but we don’t stay forever. When we transfer the software to our clients it is workable and solves all their problems – that is success.
A new software build should not be owned by just one individual – it must be reusable and fit well with the client culture. In other words, they need to own it.
And is the ownership transfer the job of the Delivery Architect?
Not necessarily. The best situation is for a few people from the client’s team to learn from the NearForm developers. This knowledge transfer also helps clients to buy into the software, and then they can continue to add new features after we leave.
What are the most important considerations to make a project successful?
A clear vision is important. And sharing that vision across the entire organisation. The whole client team needs to understand the big picture. After that, it may be common sense, but you need the proper teams to implement your vision. If it’s an iOS project then it requires iOS experts. You need the right skillset.
How do you make remote working effective?
It’s important to create a cosy workspace. You also need to create bonds, so people know something about you outside of work. Video calling is essential as it enables you to catch up, have a laugh and share little jokes. It’s critical that people enjoy working together.
What has remote working enabled in your life?
The biggest joy of remote working – and I was not expecting this – is meeting and working with people from different cultures and countries. My project teams are based everywhere, and so I’m meeting people from all over. This has been a huge benefit to me since I joined NearForm.
I also really love trail running. Being in Lyon, near the Alps, means I can put on a pair of running shoes and go out into nature, more often than if I was in an "office job".
*** Thank you Damien for giving us an insight to your role as Delivery Architect and your recent work with TELUS.
It’s also great to hear how a remote-native working model can really help deliver positive lifestyle changes.