A few months ago I published my thoughts on how to improve development time when working on inherited code bases. As a digital agency, it’s not uncommon for us to do bug fixes and improvements on client’s existing projects.
My previous post was focused on developers. In this article, I’ll look at the other side of the coin‚Äîhow can a client help to improve the development time of their application? Because at the end of the day, we at reinteractive and our clients want the same thing: achieving a quality product delivered on time within the budget.
Let’s talk about some of main points that you as the client can do to really help developers, (please note from here onwards I will refer the client as you and we developers).
Describe requirements in detail
This may seem obvious, knowing what you want, but let’s try to expand it a bit more. When I say describe requirements, it doesn’t mean that you should have 100% of the details on how everything should look in the feature being built. But having a good basic idea on what you want is essential to get started.
Full details can further be worked out together in discussions with your development team. Once you have the requirements finalised, it’s important to breakdown these requirements into smaller steps/work items. At reinteractive a project manager / developer will go over this with you if not done already.
Let’s look at an example scenario. Assume you need to add a payment gateway to your web application.
So, your requirement will be Adding a payment gateway. This requirement then needs to be broken down into smaller steps, such as:
- Defining the payment gateway you want to integrate (e.g. Stripe)
- Creating a payment screen (in your app)
- Implementing the payment gateway integration code
- Update necessary details in your existing app (about the payment)
The greater the breakdown, the easier it is to work out the estimates to build each step. A complete breakdown will give a clear idea of how much work is involved in each step and the time it will take.
As an Agile software development agency, we totally understand that requirements can be changed/added later on as the project moves forward, and we welcome that too. However, having a base list of requirements will make it easy to adjust and minimise the overall impact on the project.
Tracking the progress of requirements
Once the requirements are finalised, it’s important to track them. This can be done in many different ways, from using a project management tool to keeping a track on a spreadsheet.
I highly recommended to use proper software to track the progress of the app requirements as they are being built. Purpose built software offers so much more than a spreadsheet and helps you to visualise the progress through the use of charts, etc.
At reinteractive, our clients get to use an Agile project management tool called Pivotal Tracker and we will help you to set it up with your requirements/steps inputted. Of course, if you already have another tool that you use, we are happy to use that instead.
The importance of tracking the requirements is so everyone is on the same page. Both the client and the developers will have an accurate knowledge of the current states of the project at any given time. Whether the project is on schedule, behind or ahead of the schedule - all parties are informed and up-to-date. Knowing this early enough will allow to adjust the schedule to match the deadlines and address any blockers. It allows for complete transparency and confidence, and you maintain control of your development, which is something all our clients love.
For an example, at an end of a given week, we might notice only 3 tasks have been done out of the 6 that were due to be completed at that point. Knowing that gives greater flexibility in addressing any issues in a timely manner. If a new detail was added to the requirements for example, another developer might have to be added for a period to keep it on schedule. Or we might decide to change something else around. The point being, you and your developers are on the same page and are able to respond accordingly.
Setting priorities for requirements
When you have all the tasks added and listed in Pivotal Tracker, it is very important to prioritise each step. The ‘must haves’ are at the top of the list and ‘the nice to haves’ at the bottom. This will make sure that your developers deliver the crucial requirements first. In a case where a project is running behind schedule, you will have the option of leaving the low priority issues behind, to be added after you have released your app.
In the above payment gateway integration example, let’s say you want a Pay now button to look a certain way; rounded, with an image. This is a style request, not a functionality issue. Since this is not directly affecting your core requirement, this maybe be moved down as a low priority issue.
The important thing to understand is setting/changing the priority should be done carefully as it will directly affect the project timeline. It is always a good idea to have the high priority items done first without leaving them till the last minute. Your target is to release your application and for this you need your high priority items developed and in place.
And as with any point mentioned in this article, we @ reinteractive are happy to help you out if you think you need a hand.
Fast communication between you and your development team
Communication plays a key role in any software project. It becomes even more critical when an agency like reinteractive is working on your software project. An outside company has a limited understanding of your core business and we may have more questions than an inhouse developer would have who has been working with your company and understands it fully.
It is important to establish an agreed upon a way of communicating with your developer and to understand that while we build your software, there is going to be a big requirement for swift communication. So, you have to be able to dedicate some time on your schedule for this. Typically, this would be done via a chat tool, which enables everything to be kept in writing. At reinteractive, we use Flockdock, and as the client, you are able to add additional stakeholders from your end to the conversation and we will have our developers and the PM on the chat.
The idea is to be able to clarify any questions from your developer in a timely manner. While your software project is being built, someone has to be available to answer questions, review what is done as it moves forward and provide feedback. That way developers are not wasting time, idle if they cannot move forward due to slows on obtaining any required information or feedback.
I understand that sometimes online chat is not the best option for you as the client. In that case, we will work out what is best/convenient for you. It may it be emails or standard phone calls, but the key point here is, someone from your end is available for any questions to be answered in a timely manner. Any verbal conversations should also be noted down in writing. That way there is no room for error.
In addition to having a written chat line of communication, at reinteractive we follow the Agile methodology when working on projects. As part of this, we have a standup meeting every morning with the client to share the project status and discuss. In this live meeting the developer will provide an update on the project status and present any issues they are facing and solutions and as the client you get to share your feedback too.
This communication plays a vital part of the project as this sets the expectations for each day and you as the client get to understand where the project stands each day.
Testing / Feedback
One of the main reasons software projects can fail is a lack of adequate feedback / testing on the features being built. If no testing is done along the way and it is left till the end, a lot of time can be wasted. You want to know the issues and correct them as you go along. Testing and giving feedback in a timely manner will help to avoid this situation.
At reinteractive, we deploy the features to a staging server as we develop them. You can actually look and test and verify a new feature. For an example, if we go back to the same feature of adding a payment gateway, we will be releasing the code for each of the steps it takes to add that payment gateway.
So, once we finish the payment screen we will deploy it to staging for you to have a look. This gives you the opportunity to test and give up any feedback and tell us if you want any changes made.
The idea of this approach is to not wait until the last minute to show the full feature to you. Showing / allowing you to test each step leading up to the full feature will make sure both you are getting exactly what you want in a feature. If it isn’t right, it is fixed right away, with no delays. The last thing you want is to wait a few weeks, only to discover it wasn’t what you wanted at all. Agile methods in development solves this.
But for this to work well and fast, we as developers need the client to test and come back with feedback at their earliest convenience, so there are no delays and the project moves forward. If a developer has to wait a few days for feedback, the whole thing slows down.
Handovers
Handovers are applicable if you already have an existing project done by another agency and you are changing the development over to reinteractive. It would very helpful if you can arrange one or two meetings with the existing developers and reinteractive developers. This is important because there could be some technical knowledge to be transferred.
Example: If your app is using a 3rd party service, credentials for that service needs to be transferred to the new developers. Typically, these kinds of details should be kept with you (the client), however, with my previous experience I’ve had many occasions where the previous developers had that information, not the client. We want to be able to access that information with no delays.
Also, these meetings are typically technical, so it would be faster to arrange a direct conference with the other developer rather than having discussion requesting information using the client as the middleman. You can be on that meeting as well. It just adds more time that you don’t want to be paying for.
So, these are my top key points which, if not in place, can block rapid progress of building your application, with developers will finding it hard to continue working. This leads to delayed timelines. And nobody wants delayed timelines, right? :)
