Agile Software Development

Lately I noticed several discussion threads both offline and online (the most notable online one is in the leandevelopment Yahoo! group) focusing on the value of software testing, both automated and manual. The main discussion point as far as I can see it is in whether the testing is actually a waste that is unfortunately needed to cope with the insufficient practices and should eventually be eliminated.

Knowledge Source

Software development is always not a mass production, but a new product development - software engineers are not manufacturing goods, but rather make a design for a compiler to manufacture something nobody previously built.

"Honesty is the best policy — when there is money in it."
- Mark Twain

XP requires constant communication between team members. More specifically, XP and Agile teams depend on honest communication between stakeholders, including developers, testers, managers, and customers.

We expect manufacturers and vendors to be honest to us about the products and services they offer and market to us. Our customers expect the same. Honesty is especially crucial during iterative development where a minor course correction early in the schedule can save significant time down the road.

Extreme Programming values are the primary guidelines to be used whenever it is not clear how to resolve the particular situation. Value of respect is special in that it is the only Extreme Programming value not present in the first edition of the Extreme Programming Explained. Kent Beck added it to the second edition basing on how the first book has been interpreted in many companies out there. Extreme Programming is no fixed mechanical process that anybody could be forced doing.

Extreme Programming values are the primary guidelines to be used whenever it is not clear how to resolve the particular situation. Value of courage is about acknowledging the fact that the best way to produce the best possible products is to be honest and transparent on all the possible levels from customer communication to the way you type code despite how uncomfortable the idea of high transparency might look like from the beginning. The courage is needed to admit the team and organization weaknesses.

Extreme Programming is best known for its efficient engineering practices such as Pair Programming or Test-First Programming. However, practices are only a surface of Extreme Programming. The pros and cons of the practices, their importance and order of applying depend on the organizational and team context. Values are the backbone of XP. It is the understanding of values that makes the practices reasonable. It is possible to implement the practices without caring about the values, however, you can take most of XP only if your organization values match the values of XP.

Extreme Programming values are the primary guidelines to be used whenever it is not clear how to resolve the particular situation. Value of feedback emphasizes the belief in that requirements always change and/or are not well understood in the beginning of the project. Therefore the only way to build software the customer really needs is to continuously adjust the development basing on his feedback. Same goes to the technical level.

Extreme Programming values are the primary guidelines to be used whenever it is not clear how to resolve the particular situation. Value of simplicity calls for looking for the simplest working solution first and improving it later only the need arises. This value is based on the assumption that requirements and many other things in software are changing so often and are so imprecise until done that it is rarely worth to implement things supposed to be helpful at some point in the future.

An exciting story on how a person in the deepest regret, having no faith in himself can find its predestination and joy in life by having a close look on what really motivates him, not on what he thinks motivates him.

Extreme Programming values are the primary guidelines to be used whenever it is not clear how to resolve the particular situation. Value of communication is to explicitly state that XP teams consider sharing the status of pretty much everything being important. Even though the useless meetings are not too welcome in any methodology, in general XP teams prefer the risk of over-communicating to under-communicating.

Agile methods significantly differ from the traditional waterfall-like methods. Agile teams don't need a half a year of requirement analysis and design before the coding phase, most of the tests are written by programmers and are automated, customers are asked to participate, try live software and provide feedback frequently. All these peculiarities as well as inability to commit to the concrete set of deliverables early sometimes make agile methods look fluid and unpredictable - something not valued by the business people.

However, agile methods have a reason for not committing to the end result in the beginning of the project.