We meet with our clients. Face to face, by phone or online when distance plays a factor. In this part we first listen to the clients' problems and suggested solutions. We do not immediately provide our opinions. Following clients' explanations, comes the part when we ask some questions. This is not an interrogation, the idea is to make sure we understand what the client wants. Typically we like to hear user stories or cases description. Examining extreme cases prior to work is a proven way to predict behavior and polish specifications accordingly. Putting user stories on a piece of paper helps a lot.
Paper work and documents – here it is important for us to understand special contract issues, NDA and related documents. We discuss, share our thought and come to mutual agreement. until we pass this stage, we do not start working.
Important step of building a relationship is establishing time windows and schedules to development kick off. These mostly have dependencies in the shape of UI graphic designs, UX designs, texts, etc. Assessing when we can start working on the project is strongly related to the dependencies, not only to our schedule and available developing time we have.
In this stage we assign a contact person for the client. It all depends on the project type. It can be a senior developer, project manager or CTO. Clients need to know with whom they are contacting when needed and when it is possible.
We learn to understand the client, the client learns to understand us. A solid relationship.
Next come preparations. We actively make sure that we have all we need in order to start working. We do not assume that everything is there. If something is missing like a design, or some text, we let our clients know ASAP, before we start to code.
In this part, we do not need every piece of extra material needed, only what is important for the MVP, first few sprints, POC or whatever other terms accepted with the client. It is not practical to have it all in advance. Features and usability items prone to changes in time, sometimes even before they have been developed.
We keep everything we need in Dropbox. We share the libraries with the team members and clients. Everything is neatly ordered by folders.
We start coding in a reasonable speed. As much as we want to satisfy our clients, we do not rush into the code, we make sure that the infrastructure of the product will be solid and clean. As development progresses, it get more and more difficult to go back to early stages of code and make fundamental changes.
We are more agile than not. We do not follow blindly one convention or methodology regarding software development, trying to stay flexible. Part of it is the fact that we try not to restrict our communications with clients to a periodical meeting (even though it has it's perks) but prefer a more frequent communication method. Everybody's time is important. We respect that.
We send time report with an explanation of the work done and what is to be done in the following period of time. We use weeks as our time span of choice. More than a week and a client can lose tracks. more frequent the one week can be too much information for the client and a time consuming process for us.
In the end of the month, we repeat the same weekly report idea but we do it on a monthly time span. Why? Weeks gives you the tempo of progress, from monthly reports, the clients and ourselves can see a bigger picture.
we ask a lot of YES/NO questions. Too abstract questions do not always promote productivity. Philosophical debates on the product's use are good, but not to actual code writing.<br / We always add a possible solution to a question we ask, based on our experience and knowledge.
Inside the code, we take the liberty of prioritizing the task and build our way through the feature. We do not prioritize features of a project. We let our clients do it.
Features and functionality importance can change due to market trends, UX, costumer feedback and more. We let our client decide what is more important to them.
We constantly test the results of our work against the specifications. Not doing that for a while might cause us to divert from the original plan.