Is Agile Development Right for Your Project?

Agile development is a very popular development methodology. In the market, most companies claim to use agile development for their projects, but in reality, most people’s understanding of agile development is inconsistent, which leads to many absurd situations.

For example:

1. Having stand-up meetings every morning, retrospective meetings every evening, and iteration planning meetings every week/month. This is agile development.
2. As long as you deliver a Minimum Viable Product (MVP) as quickly as possible, it’s agile development.
3. Whether hardware or software, all projects can use agile development. If it doesn’t work, the team has problems.
4. Agile development only focuses on the final user requirements, not the technical requirements that arise in the process. Technical solution optimization and managing technical debt are not reflected in agile development. The R&D team needs to arrange additional time to do these things.

So, what exactly is agile development?

Be agile in development, not just do agile development.

The essence of agile development is to break down a complex problem into multiple smaller problems and then gradually optimize and solve them. Its core approach is iteration and incremental improvement.

Developers first quickly release a useful but imperfect version, then continuously iterate. Each iteration includes five steps: planning, design, development, testing, and evaluation, constantly improving the product and adding new features. Through frequent releases and tracking feedback from the previous iteration, the product eventually approaches a more complete form.

Key features should reach 90 points, other features 60 points is good enough, don’t pursue perfection.

When managing a complex project, the most important thing is to identify the key features and make them exceed user expectations as quickly as possible, while other features can have lower standards or even be omitted.

Generally speaking, even if we have sufficient resources (which is often not the case), our attention and time are limited. If we put all our energy into all features, the likely result is that all features can only reach 60 points or even lower. This often leads to products that cannot meet user needs or even market competition.

For example:

• WeChat’s initial target is to solve was users’ strong demand for instant messaging. Zhang Xiaolong was very smart to first release a simple and useful version, then continuously iterate and add new features based on user feedback.
• On January 21, 2011, WeChat’s first version only had text messages, picture messages and other functions. This version was not enough to make it popular because similar competing products at that time had similar functions, and products like the Fetion supported free SMS communication (text messages).
• In May 2011, after Zhang Xiaolong continued to optimize, he added real-time voice messaging functionality, allowing users to communicate like using a walkie-talkie. China happened to have a large number of people who were not good at typing, and they were loyal users of voice communication. There was no other product as easy to use at that time, which greatly sparked WeChat’s popularity.
• In July 2011, WeChat added location-based services “People Nearby”, “Drift Bottle” and “Shake”, allowing users to connect with nearby strangers. Daily user growth jumped to 100,000.
• In May 2012, WeChat launched the Moments feature, allowing users to share their lives. This transformed WeChat from an instant messaging software to a social network platform.
• In August 2013, WeChat added a large number of features such as Official Accounts, WeChat Pay, Sticker Store and Game Center. Official Accounts made WeChat a content platform, Game Center gave WeChat entertainment functionality, and the first game in the Game Center was “Aircraft Wars”. WeChat Pay was initially limited to in-game payments and later evolved into a universal payment tool.
• In January 2014, Tencent co-founder Zhang Zhidong wanted to change the traditional way of giving red envelopes to Tencent employees, so he commissioned an engineer from the WeChat team to develop the WeChat red envelope feature. This feature was opened to the public just before the Spring Festival and became an instant hit. That Spring Festival, more than 8 million Chinese people received over 40 million red envelopes. To send red envelopes, users began to link their bank accounts to WeChat mobile wallets, which enabled WeChat to compete with Alipay. Alibaba founder Jack Ma called this a “Pearl Harbor attack”.
• In January 2017, the Mini Program development guide and API were officially released.
• In December 2017, WeChat officially launched Mini Games, which belong to a category of Mini Programs. At the same time, a mini game “Jump Jump” was released as a demonstration, and this game reached 100 million daily active users.

Today, WeChat has 1 billion global users and is the APP with the highest daily active users globally. It is no longer just an instant messaging software, but a super app that has become synonymous with China’s mobile internet.

Core Advantages of Agile Development

The biggest benefit is accelerating the process of receiving user feedback and reducing costs. For an R&D company, the biggest cost is labor cost. Because the product is released online earlier, it means saving time and labor costs. In addition, because the product is online relatively earlier, you can quickly perceive real user needs, thus quickly adjusting the product direction and reducing risks.

What about hardware products?

Hardware projects have a longer production verification cycle. When hardware projects are released, it usually means that mass production verification has already been carried out. At this time, if problems are found with the product, the best time for improvement has often been missed.

During the hardware iteration cycle, each verification cycle often requires a longer cycle than software, such as PCB design, sampling, assembly, and testing, which takes weeks or even months. Each verification involves costs. In the case of changing key components, it also involves supply chain management, business negotiations and more actions.

So what to do? Here are some thoughts for reference:

1. Hardware-Software Separation Design

• Put variable functions in the software/firmware layer as much as possible, use programmable devices (FPGA, MCU) to improve flexibility
• Hardware design reserves expansion interfaces and redundant design

2. Modularization and Platformization

• Adopt modular design to reduce the iteration cost of a single module
• Build a hardware platform and iterate functions on the platform basis

3. Simulation First

• Extensive use of simulation tools to quickly verify design ideas in a virtual environment
• Conduct thermal simulation, signal integrity analysis to reduce the number of physical prototypes

4. Rapid Prototype Verification

• Use development boards and evaluation boards to quickly verify concepts
• Use 3D printing to make structural prototypes
• Small batch trial production to quickly verify key functions

5. Version Planning Strategy

• Alpha version: Internal verification, can have flying wires, manual soldering
• Beta version: Small batch trial production, verify core functions
• Release version: Final verification before mass production
• Each version has clear verification goals

6. Concurrent Engineering

• Hardware, software, structure, and testing develop in parallel
• Use Interface Control Document (ICD) for collaborative work
• Before hardware is completed, software or features are developed based on simulation environment

7. Risk-Driven Iteration

• Use risk burndown charts to focus on the progress of handling key project risks, rather than using waterfall model to manage project progress
• Prioritize verification of high-risk, high-uncertainty designs
• Purchase small samples of key components in advance for evaluation
• Conduct sufficient early verification of core functions

Does agile development really have no drawbacks?

The biggest drawback of agile development is actually related to its biggest advantage. That is the ambiguity brought by its flexibility.

1. Vague timeline estimation: Because each iteration is doing new requirements, people find it difficult to make accurate estimates for things they haven’t done before, and timeline estimates are often seen as commitments by managers, which often leads to contradictions and conflicts.
2. Documentation disaster: Because the product form changes after each iteration, and the agile mindset prioritizes development over documentation, as personnel flow and time passes, many requirements often cannot be explained by anyone why they were done that way, and people don’t even dare to change them casually.
3. Technical debt management: Rapid iteration means responding to changes quickly, which often requires the team to have strong learning ability and the ability to quickly master new technologies, which is usually a huge challenge. Agile development often leaves a lot of technical debt that needs to be managed.
4. Trust crisis: If the product direction itself has problems and agile development continues without positive feedback from users, it often leads to low team morale and even a trust crisis.

So, is agile development really right for your project?

Agile development is not a silver bullet; it’s not suitable for all projects. Judging whether agile development is suitable for your project requires evaluation from multiple dimensions.

Projects Suitable for Agile Development

If your project has the following characteristics, then agile development may be a good choice:

1. Projects with High Requirement Uncertainty

When you’re developing an innovative product from zero to one, or conducting product prototype verification, it’s often difficult to clarify all requirements at the beginning. In this situation, agile development can help you fail fast and find real user pain points. For example:

• Startups developing new products
• Pilot projects exploring new markets
• Proof of Concept (POC) projects

2. Projects Where User Feedback Significantly Impacts Product Direction

Consumer-facing (To C) internet products, such as social applications, e-commerce platforms, content platforms, etc., where real user feedback often greatly influences the product’s development direction. Through agile development, you can quickly collect user feedback and adjust product strategy in time.

3. Software-Led or Hardware-Software Separated Projects

Pure software projects, or projects with hardware-software separation design, have relatively low iteration costs and are more suitable for agile methods. For example:

• Web applications, mobile applications
• SaaS products
• Smart hardware using programmable devices (FPGA, MCU)

4. Teams with Rapid Learning and Adaptation Capabilities

Agile development requires team members to quickly learn new technologies, adapt to requirement changes, and have strong self-motivation and collaborative spirit. An ideal agile team should:

• Have complementary member skills
• Have good communication skills, be able and willing to collaborate cross-functionally
• Be willing to embrace change and continuously improve

Projects Not Suitable for Agile Development

Conversely, the following types of projects may not be entirely suitable for agile development:

1. Projects with Clear and Fixed Requirements

Government projects (To G) or large enterprise projects (To B) typically have very clear requirement documents and acceptance standards, with relatively fixed contract terms. These projects may be more suitable for traditional waterfall models or hybrid models.

2. Projects with Strict Regulations and Standards

In fields such as medical devices, aerospace, and financial systems, which are subject to strict regulations and standards, each change requires complete documentation and compliance verification, making rapid iteration extremely costly.

3. Projects Where Hardware is Dominant and Iteration Costs are Extremely High

If hardware design is the core of the project, and each iteration requires re-molding, sampling, and testing, with long cycles and high costs, fully adopting agile development may not be realistic.

4. Teams Lacking Agile Implementation Experience

If the team has never been exposed to agile development and the organizational culture doesn’t support rapid iteration and trial-and-error, hastily adopting agile may cause chaos.

5. Extremely Limited Budget and Time

When project time and budget are already very tight and cannot support even one complete iteration, agile development will actually increase management costs.

How to Evaluate Your Project

You can evaluate whether your project is suitable for agile development from the following dimensions:

Implementation Recommendations

Even if your project doesn’t fully meet the ideal conditions for agile development, you can still learn from agile thinking:

1. Adopt Hybrid Mode

You don’t have to fully adopt agile; you can use agile methods in certain project phases or modules. For example:

• Use agile in the early exploration phase, use waterfall after requirements are clear
• Software part agile, hardware part traditional, hardware modularization, modular parts can be agile
• Core features first verified agile, extended features developed according to plan

2. Start with Small-Scale Pilots

If the organization has never tried agile, it’s recommended to first select a small project with controllable risks for piloting, accumulate experience, and then promote it.

3. Emphasize Team Training and Culture Building

The success of agile development depends 70% on team culture and collaboration methods, and 30% on specific practice methods. Invest sufficient time and resources to:

• Train team members to understand the essence of agile
• Build an open, trusting team culture
• Give the team sufficient autonomy

4. Balance Agile with Documentation

Agile doesn’t mean no documentation, but prioritizes working software over comprehensive documentation. However, for key decisions, architecture design, interface definitions, etc., it’s still necessary to maintain necessary documentation. Consider:

• Use lightweight documentation formats (such as Markdown, Wiki)
• Update documentation at the end of each iteration (can be combined with AI-assisted generation)
• Make documentation a tool for team knowledge accumulation

Conclusion

Remember: Be agile in development, not dogmatically do agile development.

The essence of agile development is to respond quickly to changes and continuously deliver value. Don’t be bound by the forms of various agile methodologies, but understand the principles and values behind them.

Every project has its uniqueness, and no methodology can apply to all scenarios. What’s important is:

• Deeply understand your project characteristics and team capabilities
• Choose or adjust development methods according to actual situations
• Continuously reflect on and improve your work methods

Ultimately, regardless of what method is adopted, the goal is consistent: Efficiently deliver high-quality products that meet user needs.