Background
A full remote engineer is very good. You can work anywhere, so while traveling abroad, you can work at any time.
Supporting t...
For further actions, you may consider blocking this person and/or reporting abuse
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