Agile development

The project developments based on the waterfall methodology starts with careful planning, followed by development, testing and then introducing the product. The initial project vision is translated into an implementation plan, then comes the technical specification and finally designing the platform. By the time the project gets to the next stage, everything is carefully planned, and it is beyond the first months and first couple of hundreds of hours in its lifecycle. In theory, now it just needs to be developed. What is wrong with this approach then? In a nutshell, it works on a small scale only.

Anyone who has taken part in a complex IT project before should know that even though the above sounds good, it doesn’t really work like that. No matter how thorough the planning and preparation is, the result is often very different from what the client had in mind and what they have negotiated for. This can then lead to a conflict between the client and the supplier.

Why is it so complicated to stick to the well-planned, clearly defined brief then and why is it tricky to deliver the product without any changes? The answer lies in the process: expectations towards the result change organically over time, as the project develops. A serious development can cover a timeframe spanning from a few months to half a year or a year. This is a considerably long time, especially within ecommerce. The rapid changes and the competitive nature of the market bring new requirements to the surface during the development and demands that appeared to be top priority at the beginning could end up being less important.

The problem with the classic waterfall-type projects: the requirements change along the way but it’s nearly impossible to deviate from the technical content that’s outlined in the signed contract.
This means that the carefully-planned functionality package that seemed necessary at the start will lose its relevance by the go-live date. The waterfall methodology doesn’t accommodate any deviation from the original plans as there is a conflict of interest between the client and the supplier: new demands require constant modifications and renegotiations. This is a heated setup in which both parties recognise the need to change, but the rigid financial and contractual boundaries and the number of days spent with intensive planning grounds them. This means that the result will differ greatly to what the business need was.

In the classic waterfall setup, the project requirements change swiftly along the way but the original specifics in the contract are binding, making it hard to action changes.

Here’s a great example: imagine sorting your shopping over the weekend (this is the project) with a shopping list that was created in advance (agreed scope for the project). No matter how detailed your shopping list is, chances are slim that you will only buy exactly what’s on it and nothing else. Browsing through the aisles, you might remember that you need sugar – something that you didn’t account for. The waterfall method wouldn’t allow this as it isn’t on the original list. As you get to the meat section you might realise that instead of chicken, you’d prefer fish. Once again, the model wouldn’t allow this as you are trying to change products of the same value, but you are contractually obliged to leave the shop with chicken, no matter what. Finally, the waterfall method doesn’t factor in the possibility of changes in market conditions or extreme circumstances: let’s say your partner gives you a call to get fabric softener instead of laundry detergent.

The developments laid out in the brief are very detailed and extensive already in the early stages with the waterfall method, but they can’t potentially be accurate or fully-established. This is specifically true when it comes to ecommerce as new innovations that change the market’s landscape are being introduced every week.

With the agile development approach, we accept the inevitable, the fact that it’s impossible to fully and accurately define a complex development project at the very beginning. What’s more, we think that it’s not practical or realistic to work towards it either. Instead, we allow the project and its technical content to distil during its own course. We incorporate change to the project. This also means that we lay the foundations for the business needs and we define the requirements, but we develop the content along the way, in close collaboration with you.

Sticking to the previous example, agile shopping means that you set up a list of minimum viable products (MVP), that you must buy and without which your trip was useless. You need milk, cheese and baked goods for sure, otherwise there’s no point of your shopping. On the same note, you have to accept and reiterate that your demands might become more defined, as during the process itself you’ll see things clearer then when you were only in the planning stages. You set up a budget for yourself and you make your choices based on this, as you’re browsing through the store. We apply this approach at pretty much all walks of life, whether we’re talking about shopping, building a house or taking our business to the next level. Why would it be any different for web development?

With our agile method we minimise the chances of delivering something that was considered important at the beginning but turned out to be irrelevant during the process and we aim to focus on catering for new demands that we didn’t even think of at the starting point.

As part of the release process, we develop in sprits that usually cover two-week cycles. The sprint is launched with a planning session together with the development team during which we talk through the objectives and we prioritise the order of product delivery. The sprints end with a demo, this is the stage in which the client can view and test the delivered products. This means that testing isn’t done at the very end, it is done continuously as the project progresses.

The client’s Product Owner is a key figure here as they decide the priorities for the next set of functionalities. They think and plan together with the Development Team. As we revisit the decisions and priorities set by client and as we bring the development packages to life, sprints constantly adjust and steer the project towards the right direction. The essence of the agile development method is that the content of the project is constantly readjusted so that we can enter the market as soon as possible in an MVP (minimum viable product) state.

It is important that sprints on their own deliver a fully-valuable product development. The client should be able to immediately own and use the products of each sprint. If we were to develop, let’s say, a credit calculator, at the end of the sprint it should be completely finished with all its components tested and it should be ready in demo version.

Another important thing is that no changes are made while the sprint is running. An agile release cycle is speedy but it requires the Development Team to work on one project only without any interruptions. The active sprint is a period, during which the objectives don’t change so the developers won’t be influenced and as a result their work will be more efficient.

The sprints have input requirements as well. A development can only be set up as a sprint if the business specifications have been clearly defined, meaning that it’s sprint-ready and it has the design wireframes and approved criteria. The releases at the end of the sprints are strictly controlled as we set a DoD (definition of done) requirement profile before the launch, defying when a project package can be considered final.

A sprint planning meeting is a key milestone in the process, set up by the scrum master. This is where the results of the previous sprint are presented and when planning begins for the next one. During these sessions the Project Owner meets the teams to evaluate the progress. As part of the sprint planning, the backlog elements are defined as well and specifications are reviewed and finalised together.

In other words, one of the many advantages of the agile approach is that planning ahead for the next sprint’s functionality developments is a lot easier than it is to do everything in one go, before the whole project launches. From a client perspective, it is also a lot easier to receive the releases of the previous sprint only, to learn more about them and to test them in tiers, than to do everything in one go at the very end. The software is not launched with its full functionality, the clients and the customers scan tart using these gradually.

What does this mean when it comes to developing a webshop? In practice we realise 2 phases in accordance to agile methodology:

• In the first phase, we introduce the essential building blocks: quick releases and basic software that can be handed over to the client with ease. This could be the OANDER Hodor frontend template, ready-made Magento modules that can be installed quickly or the pre-made Oander Connect middleware platform that functions as an interface kit for integrational purposes. We aim for the client to implement these, to get to know them and to enter the market with them as soon as possible. After this, we move onto the prototype stage. The software elements are being added gradually with the help of sprints, as the start kit is already complex and it’s easier and more efficient for the client to learn more about the platform, to take over and to test step by step.
• This is then followed by a support and another development process, during which we tweak the components of the prototype further based on one-of-a-kind requests. For example, we create a unique design for the frontend template, we introduce new modules or implement further requirements. With sprints and their quick implementations, you can decide on which function package should be developed next. You don’t need to see the whole scope of the projects, you just need to focus on the next step and decide what’s most important for that step. Having access to a functioning software allows you to make clearer and better ideas for further developments, and these can deviate from the perspectives that you might have had in mind in the very beginning.
• As part of an agile development, you as a customer will purchase a finished product (Magento base platform, template, modules) and its introduction so that you can enter the market as soon as possible. After this, while maintaining constant client and product support, we develop the product further with quick release cycles that strengthen your market position.

• The agile development method only works well if the company culture of the client incorporates a planning, analysing and feedback-based commercial practice, or at least is open to a lean approach.
• The client should be an active collaborator of the planning and the development of the project, instead of passively observing. The method only works if the client is open to sprint-based mutual planning, if they are willing to support with creating the business or technical specifications and can cooperate in a development that is based on quick and meaningful interactions.
• The third pillar of an agile development is involving a Product Owner from the client’s side, who can manage the workflow in accordance to development priority strategy and who’s got a great understanding and overview of technical details. The Product Owner collaborates with the Design and the Development Team, decides on the content of sprints and manages backlog.