Software Development: The Process We Use

At Software Planet, we take great pride in our customer-centric development process. This is why from start to finish, a striking sense of partnership is present in all we do. Still, we recognise that for those with limited exposure to Agile development, an inescapable learning curve may also be perceived; so for this article, we would like to walk you step-by-step through our tried-and-trusted methods.

Getting Started

1. Planning and estimating

The first step in our development process is the planning and estimating phase, where multiple things are done. First, we create user stories, which are short narratives designed to express the customer’s requirements in a clear and understandable way. This could be something like, “as a potential customer, I would like to be able to register for a free trial.” Afterwards, we define our acceptance criteria — alternatively known as “the definition of done” — which aim to provide all the necessary conditions that must first be met in order for a story to be considered complete (i.e. highlight required fields, verify email format, remember password, display error alerts, register via facebook). Then, it is time to create our estimates. At SPG, this is done by first determining the relative complexity of each user story and endowing them with what we call complexity points or unit points. Because we know how long our developers will take to complete a single unit point, we can calculate the time and cost associated with every individual requirement. Finally, we make use of system metaphors to establish a shared understanding of complex systems. In practice, this means devising a relatable allegory that is able to explain, in very simple terms, how the system is meant to behave. This avoids any technical jargon and allows everyone — both customers and developers — to find themselves on the same page. Throughout the planning and estimating phase, the essential role of the customer is to painstakingly specify their priorities and requirements.

2. T&M Contracts

Next, we draw up a highly flexible Time and Materials (T&M) contract. Under this model, because our customers only pay for our expertise and the work they wish to complete, they are given the power to direct and scale development in any way of their choosing. For example, should they wish to change requirements, with a T&M contract, they would be more than welcome to do so. Nonetheless, our customers often worry that the model will somehow end up costing them a lot more of their hard-earned cash in the long run, yet this is certainly not the case. Far from a blank cheque, a T&M contract simply enables us to re-adjust the focus of development without having to waste precious time on the contractual permissibility of every given action. This, of course, stands in stark contrast to the much more rigid fixed price arrangement, in which you pay for a product to be finished with both predefined and detailed requirements, as well as for a set amount of money.

Building Software

1. Sprint planning

Because we use the Scrum methodology, we work in one to two-week iterations known as Sprints. During this time, developers plan, implement and deliver requirements. In this way, essentially, the entire project is broken down into manageable, miniature projects. When development proper begins, the first thing we must do is define our Sprint goal. This spells out the main objective that all developers should be striving towards meeting for the entire duration of the current iteration. In order to define it, we invite our customers to a Sprint planning meeting, where our team are able to discuss the project’s iterative scope via an online communication tool such as Skype or Google Hangouts.

2. Iterative work

As explained above, we work in one to two-week iterations known as Sprints. Each Sprint should lead to a potentially shippable product — with fully working functionality — which in turn provides our customers with the freedom to decide whenever they are ready for their first official release. By extension, of course, this also means we commit ourselves to ensuring our code is appropriately — and continually — tested. And while our Sprints may be very short in nature, we work under a policy of complete transparency. Thus, every day, you can expect to receive a formal progress report detailing information on what already has been accomplished, which problems may have arisen, as well as what is being planned for the following workday. This empowers our clients to react quickly if needed, saving them time and money. Even better, we keep no intermediaries at all between you and our development teams. Any questions or concerns you have may be directly addressed to our software engineers themselves, whenever you please. In fact, at any time, SPG are happy to invite you to a face-to-face meeting on our premises; or, if you would prefer, we could also come for a workshop at your company.

3. Demo meetings

We are strong believers in the value of continuous feedback. This is why at the end of every iteration, we summon everyone together for a show of demonstrable updates. These so-called demo meetings are a time to gauge overall progress, evaluate performance, compare original goals with what has actually been delivered and above all, receive critical feedback that will help us moving forward.

4. Retrospective

While our demo meetings are primarily geared towards our customers, our Sprint retrospectives, for their part, are a great opportunity for developers too to evaluate their achievements. In these periodical reviews, we ask open-ended questions that seek to reveal the root cause of our problems, and thus, size up every aspect of development, from budget, to timeline, to goals.

5. Staging environment

As they say, one can never be too cautious, so to certify that no problems will arise after deployment, we may also make use of a testing stage. This staging environment, as it is known, attempts to closely mirror our customer’s own in-house settings, enabling us to address any issues in load-balancing, scalability and security. At all times, our customers are given access to this staging environment, so they are free to check progress as often as they wish.

6. Graphic design

Notably, here at SPG, we have found that the best way to work with a graphic design team — be that internally or externally — is for designers to prepare all UI and UX work an entire Sprint ahead of development. This makes planning an essential part of synchronisation for both designers and developers.

7. QA

And finally, in our Quality Assurance testing stage, we do everything in our power to safeguard — and guarantee — the business value of your project. Contrary to design work, which is carried out a Sprint in advance, we conduct all QA activities a Sprint late in development. In this way, our QA team work hand in hand with developers to scrutinise every aspect of a product’s development, determine if users’ needs are being adequately perceived and give their stamp of approval as soon as your project is appropriately deemed ready for prime time enjoyment.

Fine-Tuning

1. Metrics

Sometimes, however, you may want to shake things up. This is where our unique software metrics, like the Happiness Graph and Sprint Burndown chart will come most in handy. Together, they provide our customers with a fully transparent and accurate portrayal of their projects — in areas ranging from overtime and costs to the actual wellbeing of our working relationships. As a result, you are given the power to reassess development and change course wherever the need may be.

2. Backlog grooming

Lastly, in true rinse and repeat fashion, we always make sure that any user stories that are yet to be developed are fully consistent with all those that have already been delivered. This means doing away with any stories which can no longer be considered relevant, creating new ones as a response to any recent information, reevaluating the priority of certain stories in the backlog and perhaps splitting others into two or more requirements. All these actions, of course, strive to give the following iteration the smoothest possible beginning. So that’s it in a nutshell! And yes, we do realise it is a pretty big nutshell, but to really sum it all up, just remember that SPG will always put you at the very centre of everything we do.