MadAppGang’s software development process: True agility, simplicity, and rapid delivery

When cooperating with a software development company, you should know what types of specialists you’re hiring, how they build their processes, and your level of involvement. Different approaches to development lead to different outcomes in terms of timeframes, expenses, team communication, and the end product’s quality and ability to scale. 

In this post, we’ll shed some light on how MadAppGang builds and maintains an effective software development process, and why we believe in Agile and lean product development principles.

Agile is an umbrella term for a number of tools and practices used in software development and task management. The essence of Agile is its flexibility in the face of change; by dividing the process into small chunks (iterations) that each have a clear goal and end result, it’s possible to adjust the product to any new circumstances that arise. 

It’s safe to say that for effective change management, the software development process should be based on Agile principles.

Besides its flexibility and adaptability to change, the Agile methodology prioritises business needs, direct communication, and the delivery of a functioning result. Agile software development includes a lot of particular tools and methodologies but they all should be used according to Agile’s key principles.

Agile practices visualised as a subway map. The team-based iterative and incremental approach, and version control (change management), are Agile fundamentals. Image source: Agile Alliance

The previously dominant approach, Waterfall, takes a single pre-defined direction for long-term development and moves any adjustments to the final stage, which sometimes means redoing everything from scratch.

Waterfall’s major issues include:

• Unpredicted expansion of non-development activities. Without an iterative approach, teams spend more time gathering requirements, doing (and often redoing) designs, and so on.
• Design disconnected from actual product implementation. When design is planned too far in advance and created on a separate stage before development, it might turn out to be useless because things tend to change throughout development. 
• Ineffective testing. When testing is carried out at the very end of the development cycle, it’s much harder to identify all the issues and risks than when testing each increment at a time.

To date, the Agile software development process has become the new norm and is on the rise. Hewlett Packard’s 2017 survey of IT project management professionals showed that only 2 per cent of respondents were using Waterfall. Of those surveyed, 16 had fully adopted Agile methods and 51 were leaning towards Agile. Multi-divisional companies with a lot of internal bureaucracy are probably those that still practice Waterfall.

Despite some misconceptions, Agile can be successfully applied to any industry. Even in heavily regulated environments such as healthcare, Agile software development can be used to create high-quality and compliant solutions at a rapid pace.

At MadAppGang, we believe in the power of Agile but we also know that it can be handled in various ways. Here, we’ll explain how things work at our company and what we value in the software development process.

The first step of the software development process is shaping a product’s concept. At this stage, which we term presale, our solution architect discusses the client’s idea to better understand what’s involved in building that product. Clients may have technical expertise and know exactly what they want, or they may have a very vague understanding of their product’s needs. From our experience, over half of our clients aren’t specific and need our developers with relevant expertise to expand and elaborate on their initial idea. Either way, we ask a lot of questions to synchronise our vision with that of the client’s and understand which technologies are required and what regulations or limitations might be at work.

After an initial interview with the client, we take a timeout to estimate how to optimise their needs. We always think about time and cost-cutting measures that won’t compromise quality but will help deliver a minimal viable product (MVP) in the most efficient way. For example, we might suggest that a client incorporates no-code and low-code solutions to expedite the development process and avoid unnecessarily reinventing the wheel when it comes to commodity functionality.

Sometimes, we do the opposite and suggest expanding the budget, for example, if a client doesn’t want to set up a cloud server right away but we see that it’s inevitable. We always follow the client’s expectations and use product-centered arguments when discussing the idea — it’s in our best interest for the resulting software to work according to business needs and operate as intended.

We collect project requirements during the discussion stage, where we also strategise future product development. Those initial requirements should include answers to the following questions:

• What should the project help users do? For example, it should be a visual editor that allows users to combine several photos into a collage.
• What features should it support? For example, it might need a collage builder, an uploading feature, sharing options, or other functions.
• What might it need in the future? For example, integrations with third-party image libraries.

To deliver a working MVP, it’s best to minimise the initial requirements as much as possible. All collected requirements and planned features go to a product backlog that is constantly reviewed. Thanks to a collaborative and flexible team environment, and effective task prioritisation, we once developed an MVP in a record six weeks. 

At this stage, some companies integrate Business Process Modelling Notation (BPMN) into their software development process. Used to document a project’s specifications, BPMN tools can serve as a comprehensive standard but they often lack flexibility. There’s no point in communicating all specifications at the initial stage of development — as practiced in the past — but it is crucial to adjust processes according to evolving requirements and the current state of the product as it evolves from one iteration to the next.

Once we agree on the project scope and goals, we explain how our processes are handled and start development. We provide a rough estimate of the time it will take to develop the product, but we never use a fixed time and cost framework. We use Time and Materials contracts whereby costs are calculated based on the hours each team member works. 

Even though some companies still operate on a fixed-price basis, it’s not beneficial to either the client or the development team. A 2012 McKinsey study showed that more than half of all enterprise software projects are saddled with excess costs because of incomplete requirements that can be misinterpreted or because a lot of effort has been concentrated on what eventually become unnecessary features.

We provide our clients with a dedicated team, ensure the client’s involvement in the process at all stages, and encourage direct communication with developers. This helps both sides keep track of progress and make timely adjustments when needed. To manage processes, we use ClickUp, Jira, and other Agile software development process tools and techniques.

For most projects, we use the Scrum framework and divide development into sprints. One sprint usually takes two weeks, but if the project is very dynamic, a sprint can be executed in a week. For more dynamic projects, we usually adopt the Kanban system. 

Unlike Scrum, the Kanban software development process doesn’t fix roles (e.g. product owner, Scrum master, development team) and doesn’t set a specific timeframe for each iteration. Instead, it focuses on delivering each iteration as fast as possible according to the backlog and lets the team introduce and adapt to changes at any given moment.

Example of project visualisation in a Kanban board. Source: Kanbanize

The advantages of the Scrum software development process lie in its transparency and simplicity: each sprint, the Scrum team delivers incremental value to a product and reviews the results with the project’s stakeholders.

Each sprint includes several steps from sprint planning according to requirements, design, and development, to testing and delivery. Design in the software development process should be created in sync with engineering. First, our designer creates a design system, a set of elements that can be used and rearranged in the future product. Then, complete interfaces are built in accordance with each iteration and the features that are in active development.

Sometimes, a client has their own designs, and we can use these as a starting point. But inevitably, we do need to make changes to these designs so they work in tandem with the development. As a general rule, we recommend that both design and development are entrusted to a single provider. This way, you won’t have surface-level user interfaces (UIs) that are disconnected from the product’s real purpose. 

The same principle applies to testing: it should be done in parallel with development, and the features created in a sprint should be tested during that same sprint. Testing intensity depends on the project. Sometimes, we adopt test-driven development (TDD) which involves writing tests first and then starting development. It slows the process and makes it more expensive, but if the software needs to comply with a lot of stringent regulations and handles sensitive data, TDD is our approach of choice.

Sprint reviews

Each sprint’s final step is a review meeting when we show the working prototype and discuss what went well and what could be improved. Usually, the client takes part in sprint reviews to track progress and make adjustments if needed. Based on the sprint’s results, the client (or a stakeholder) prioritises the features to be built and decides upon any strategic actions that might change the course of development. 

Successfully built features and problematic issues alike are discussed in sprint reviews. We discuss what tasks are incomplete, what may have been incorrectly evaluated, and so on alongside what ran according to plan. It’s important to keep the channels of communication open so that the end product doesn’t suffer as a result of misunderstandings or unreported challenges.

Note: If a client wants to be even more involved and be in touch with the team every day and take part in daily standups we welcome this level of involvement. However, it happens quite rarely.

Continuous delivery

An important advantage to the Scrum software development process is continuous integration (CI) and continuous delivery (CD). Both CI and CD are adopted by most noteworthy companies. For instance, the software development process at Amazon involves CI and CD tools that help minimise risks when it comes to rapid changes. Amazon engineers claim that continuous delivery pipelines allow them to increase the speed of development. Another company that uses CI and CD in its software development process is Netflix. They use a number of tools designed for CI and CD that help automate tasks and deliver value quickly.

Speaking of the software development process, Facebook engineers talked about the progressive approach. Moving the web app to a new system in 2016, they started with 0.1 per cent of users and gradually expanded. This is an example of CD where product changes aren’t enacted in one big update but released progressively. With continuous delivery, Facebook increased the frequency of releases from four weeks to just one, which allowed them to rapidly bring small enhancements to life.

Still, Facebook’s software development process has its problems. Kent Beck, the creator of extreme programming and a TDD evangelist who worked at Facebook, admitted he was fired because he initiated a discussion around the quality of decisions. He believed that Facebook concentrated too much effort on developers’ impact instead of prioritising good product decisions.

It’s important to understand that whatever progressive methodologies a company uses, it doesn’t mean there are no miscommunications or overtime issues and missed deadlines. To achieve the most sustainable result, a software provider should maintain a healthy working environment on top of Agile practices. When there are no manipulated expectations and the communication is honest and open, both inside the development team and with the client, it’s easier to focus on the most valuable things and deliver the best end result.

At MadAppGang, we follow lean software development principles, which means building a skeleton first and then adding the layers. It aligns with Agile principles well. After all, it doesn’t make sense to build long-term strategies or start everything all at once. What lean development philosophy teaches us is that with small increments, simplified processes, and the right tools, you can build a product that’s adaptable to rapid changes and works from day one.

When you choose MadAppGang for web development you get:

• The Agile methodology and attitude to development. We build solutions that drive real value for our clients’ businesses, so we keep the process as simple as possible and expedite delivery by focusing on business needs, being adaptable, and using the right tools.
• Rich technical expertise. Our seasoned developers know their stuff, and they’re always on hand to impart their wisdom and technical skills to team members.
• Knowledge sharing environment. When engineers have a concern or face unexpected challenges, they escalate the issue and draw upon the team’s shared knowledge bank. We believe in a work culture where everyone contributes to the team’s expertise and is always open to learning.
• Comprehensible and readable code. Our developers document their code so it can easily be reused. We can also provide in-depth code documentation if needed.

Ready to discuss your product idea? Reach out to us and we’ll take it from there.