Agile Software Development

Before we begin, let's take a look at the Agile Software Development Manifesto together.

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the left,
we value the items on the right more.

The highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. If everything went smoothly according to plan when you're doing business, everyone would be an entrepreneur.

That's not the case. Your research might be wrong, or the market might change. That's why the stance we need to adopt in this era is flexibility. Whether it's business, studying, or learning, if your strategy lacks the flexibility to adapt to change, it's bound to break.

When I make plans or strategies, compromise will always exist. However, compromise is based on certain assumptions and is only valid within those assumptions. If those assumptions break, everything will collapse.

The strength of flexibility comes from this. No matter how much the assumptions break, you can re-establish or change your strategy accordingly. Delving deeper into software, you must satisfy the customer by making the working software function again to meet their needs.

Business people and developers must work together daily throughout the project to develop software that responds to customer feedback. Build projects around motivated individuals, give them the environment and support they need, and trust them to get the job done.

Development Team #

What do you think is the most efficient and effective method of conveying information within a development team?

DMs? Some framework? Documentation? No, it's face-to-face conversation. You submit a PR, read the description, analyze the code, and leave a review. Even if you ask to focus on specific parts of the PR, it can't have a stronger effect than discussing it face-to-face while looking at the same screen.

Of course, it's difficult to have face-to-face conversations in all situations, which is why we use these development processes. But if possible, try to utilize face-to-face interaction as often as you can. It's the best way to disseminate contextual information.

And don't force yourselves to adapt to any specific productivity tool. In a development team, even a whiteboard is enough to develop and communicate any requirements. Continuous attention to technical excellence and good design enhances agility.

It must be simple. You should repeatedly make choices where your 20% effort yields 80% of the overall impact, following Pareto's principle. It's more important to consistently deliver 80-point code than to intermittently produce 100-point code. It needs to be simple, agile, and quickly adaptable.

The best architectures, requirements, and designs emerge from self-organizing teams. Even if something is good in another organization, if your team doesn't think it's good, it's better not to adopt it. Forcing its use will double the cost in terms of productivity and implementation.

It's okay to be simple. You might think that if it's simple or not modern, you'll fall behind and productivity will drop. This is natural because it's a human trait to judge something as worthless if its difficulty is low. But that's not true. At least, instead of worrying, try to find if there are more sticking points when keeping things simple; that will be the moment when new changes are needed.