Software Development for the 21st Century
A lot of people read the manifesto as 'Do X not Y'. This was never the intention. The wording is 'Prefer X over Y'. Sometimes Y is better - but you need to justify why you are doing Y. All techniques of software design and development have their relevance and validity, but you should think about which technique you are using and why. Agile suggests a 'default' way of thinking. It can embrace any technique as long as it is justifiable.
A lot of traditional development models were process/tool based - "We can do this, so get used to it". It made sense when computers were expensive. But it is not justifiable any more. Our shared objective is to make something that satisfies a need. Normally a user need. Users are primarily the people using the software, but there are other people who are affected by it (stake-holders). A key idea is to recognise these people, interact with them and continuously improve what we are delivering and how we are working. We need to adopt this model within our development teams and our organisations.
This statement is really a reaction against old style requirement and specification work. The model used to be that a set of analysts look at an issue (often for a long time, at great expense). Then they produce some huge documents and run away. They were supposed to have thought of every possibility and documented it before any code was written. A tough challenge at any time. Once that has been achieved, their job is done. That worked a while ago. But now, this is not acceptable. Changes (as noted above) make software development cycles faster. Users are different and more aware. It is also simply illogical to try and think of everything in advance if you can do it a bit at a time with continuous interaction with users. So focus on the product. But do not forget the documentation. It is still essential, but projects are not document-led.
The development team and the customer are both on the same side. Strange, but true. Historically, a software provider would try to tie down a contract which defines exactly what they will deliver. A customer would try to explain what they wanted, but they were often unclear about it and at the mercy of the supplier. This creates an antagonistic situation. Proper software development should have a shared goal of developing the best solution given the available resources. Customer and developers should be working together to achieve this.
"Planning is essential but plans are useless" - I paraphrase Dwight D Eisenhower, who was talking about battles. The key idea is that we must plan - look into the future and see what may happen and what our options are. But circumstances change - following a plan, despite changes in the environment and things that we learn is a closed and inflexible process. We obviously have to plan Agile projects. We have to answer key questions like 'can it be done?', 'Are there any difficult bits?', 'What are our options?', 'What resource will it take?'. But that is all. We can make a high-level plan and then adapt flexibly to user input and changes in context. Much of what we do is "Just-in-time" planning.