Background
A full remote engineer is very good. You can work anywhere, so while traveling abroad, you can work at any time.
Supporting this wonderful freedom is the trust of our customers.
The full-remote job is judged only by products because they can not see the process of your job.
Delivering value to customers, being trusted by them, and establishing good relationships are necessary to survive as a full remote engineer.
What do I need to do to gain trust?
How can we deliver value, be trusted, and have a good relationship with customers?
I think there are many elements, but I think the following three things are important.
- Shows your result every week
- High quality
- Responds quickly to feedback
Agile development methods can respond to the above three in the following way.
- Start development from top priority story
- Test-driven development
- Refactoring Regularly
In order to explain each in detail, I would like to explain how to proceed with agile development with the following orders.
Order: The owner of the used bookstore requests you to develop a web application that can manage inventory and also allow customers to check the inventory . The owner can register the purchased book, and he wants to know the number of stocks immediately. His Customers can visit the site to find out what books are in stock, how much they are for sale, and search by title. I think that it is best if you can see other products that sell well and suggest products recommended from the browsing history.
Shows your result every week → Develop from top priority stories
You listened to this owner's request and decided to develop all the features. You will tell the owner that it will take 3 months for development, and you will start working immediately.
The owner cannot see how you work. So if you don't get the work done for a month or two, he will be anxious, and say, "How is it going?"
You would answer, "I have done detailed design, set up DB, wrote Model and Controller. I also tested them properly. Next, I will write the View and complete it. I can do it in one month." You will show him the source code.
But He doesn't really know if it's really nearing completion, because he can't see the work that is moving. It can not be said that there is a trusting relationship between you and him.
What do you do with Agile? Determine the top priority story and develop from there .
The story is, in a nutshell, the "feature that works end-to-end" .
The top story is the most important value story (feature) in the list of stories.
In this example, “I can register books and view inventory in a list” is the core value. You can not do anything without this.
In Agile we start to create products with only this feature .
Because the functions are limited to one, you can do it in a week.
Show the owner a product that will move in a week. The owner can confirm that the book can be registered, so he must be glad to know the progress, rather than looking at the source code.
In the next week, We will implement the next important story and let him see the product that is moving next week . The owner can see the product being added features each week, so he can leave work to you with great peace of mind.
high-quality → test-driven development
The owner is happy now to confirm that the book can be registered, but he noticed that registering a blank book title would cause a bug. There are many other bugs, such as being able to put text in the price, or being double registered if he clicks twice. You use the whole week to write tests and fix bugs, but nothing features have been added since a week ago. You will lose the owner's trust.
No matter how quickly you deliver a product that moves, products of low quality will lose the trust of customers .
What do you do with Agile? Agile development is basically done with test-driven development .
Test-driven development is a method that proceeds from development by writing from test and implementing it so that the test passes.
The important thing is to do a minimal implementation for passing the tests you are writing.
Test-driven development can ensure the quality of the written test, and can also avoid excessive-quality (too much implementation).
Because test-driven development is deep, I would like you to study other materials by all means.
Respond quickly to feedback → Refactoring
Whenever you see a product that moves once a week, be sure to get feedback.
When I try to touch moving things, there are more and more requests that did not appear when discussing on the desk .
For example, "Because there are more than 100 books in a month, it is better to register as easy as possible" or "If the link to the Amazon is also attached, the price of our house may seem more reasonable".
All these feedbacks are stories. Put in the story list, we will develop from the highest priority story.
The more feedback there is, that is, more corrections .
Refactoring is essential for the agile handling of feature additions and modifications.
When is the best time of refactoring? It is always.
To be precise, while doing test-driven development, we always take time to refactor when we pass the test .
It is this as a flow.
Test-> Implementation-> Refactoring
Repeat this to create a product, and the product will be resistant to change.
When the owner sees the request he has given immediately added, his confidence in you will grow. So be sure to always have a codebase that can quickly change to customer's needs.
Finally
The word agile development is the buzzword, but I think that there are few people who are studying to what kind of method and how to proceed specifically.
I think you can see how Agile is better at delivering value through this example.
There are a lot of things that have not been reported this time, so please search for the word Agile Development or Scrum Development and get the information.
Well then, have a good engineer life.
PS. I'm searching remote job. I specialize in iOS app (swift), Web app (React, Vue), API development (Python, Typescript, Java). My strength is in delivering value with agility.
Contact: mugiroki07[@]gmail.com
Top comments (3)
I like your straightforward example of how Agile can help people gain trust with their clients. It's very down-to-earth without any mumbo jumbo.
I especially like the idea of showing your work often, take a lot of feedback from your client and refactor along the way. It reminds me of some current makers like Marc Köhlbrugge from Betalist who show stuff every day to get more feedback from customers. Never thought it could be a thing with more traditional clients, but now that you've written it, it seems obvious (and really smart).
Thanks @yuno_miyako 👏
@yuno_miyako , thank you for this article; I think you offered sensitive insights that can really improve the client<>developer relationship.
Over a ~20 year career of successful web projects with clients (both enterprise and small businesses) I have seen the most important aspect for success is visibility into progress. As you note:
And you're very correct, that in our eagerness to provide weekly visible progress, we must not stumble in the show-and-tell delivery:
As a PM/front-end UX/designer, I have seen too many times that the programmer I partnered with did not due enough testing on their own (with their own well-developed process), so it jeopardized the weekly demo day. The burden of testing was only on me, and there was not enough time to resolve before the demo time. The best developers have a test-driven process as they go, or as I used to say, an "inline testing flow" -- as opposed to after-the-fact.
Might I add a comment about what you wrote here:
It's worth noting (and I'm sure you know this): this reminds me of "feature creep", which happens when the client gets very excited about seeing progress (their dream is coming true!) and they ask for more and more mini-features to enhance the vision.
What this conveys to me is that the Project's Feature Scope was not actually thoroughly outlined, in the beginning; if something was not in the Scope, then its time + cost wasn't quoted, and thus we have feature creep and missed budgets. It's so tempting to keep saying "yes" to each request (after all, the product is getting better!) but, the client is almost always not prepared for the price increase (or you have to swallow the extra costs).
So what we do is then document any good ideas that emerge from the dev process, and ask to defer them until the first scoped project is completed... then the "AAs" (which mean "author's alterations" can be started when the client has the budget to complete them. It's always better for you to ship a v1 than to get bogged down in continual feature additions under the first Scope.
Hope that helps!
Paul
I will show this article to my coworkers