Software Development for the 21st Century
These principles are not as important as the basic values. They are still important to consider, but it is not a requirement to follow them all. There are other principles you might add which are equally valid. Many of these principles are directed at people who are 'waterfall thinkers' to get them to change their perspective.
This is a direct reaction against the the waterfall model - design, specify, develop. For this to work the analyst has to understand and exhaustively specify everything a user might want and every case that can possibly happen. That was always almost impossible - though you can make it work for systems with no users. With a broader audience and more flexible delivery this is an impossible task to do 'up front'. You will derive requirements before you start - and might specify a solution - but this will be partial at best. Get used to it. It becomes even more important when you realise we are often offering users something they have never had before. They cannot tell you what they need because they do not know what is possible. Early and continuous delivery is a way to evolve the requirements as the project progresses.
Requirements do change. When you show the users/customer some software it may well cause them to think about the problem more clearly. There is a well-known approach of 'progressive refinement' in which you build something basic, show it to customers and improve it. There is a strong psychological model behind this - people find it easier to criticise something concrete than describe what they want in the abstract. 'I want X' is a lot weaker than 'I do not like X because..'
Having said that, you cannot keep changing the project for every change the customer wants. Defining a scope is important - stating what is out of scope is probably more important than stating what is in scope. You should not be limited by that though - if the client asks for something which was not in scope then be prepared to have the conversation about it and how it changes the scope. With resource-limited projects something has to go out if something new goes in. That is Agile.
Competitive advantage. I am not convinced that this is the only (or even) the most important reason to change scope.
This is important. Agile reacts against the idea that you can completely capture requirements and produce specifications in advance of development. It is essential to involve users and other stake-holders throughout the project. Because you do not plan the whole project in advance, mistakes and changes are inevitable. By delivering frequently, you continuously check what you do with all interested parties. This keeps the project on track and ensures 'errors' are quickly corrected. Furthermore, users are not always right. They do not always know what they want, or what is possible. It is much more effective to show them something working and get them to tell you why it is wrong, then to ask them what they want. Embracing change is Agile.
Undoubtedly. Developers like to develop. They will add things because they can, or because there is a new technology that they want to explore. Nothing wrong with that, but it should be seen as outside the core project. A strong team includes people who know how to develop solutions working alongside people with the actual need. Anything which is not actually needed by the users is not essential to the project. That does not mean it cannot be added later.
An Agile team is a thing in itself. It must be allowed to develop and evolve over the course of a project. That is why there are no roles in Agile (with minimal exceptions - product owner and scrum master, for example). A team develops a shared goal that they all want to achieve. They will all do what is needed to achieve that goal. Every team member should understand what every other team member is doing, and how it impacts upon their work and the project as a whole. This is a difficult position for waterfall people to grasp. Each person does a job (or a variety of jobs) and takes responsibility for them. Saying 'Well, I wrote the document' is not an excuse. Everyone is trusted and given responsibility for their work. Some people cannot do that - so they must leave the team. There is no hierarchy in Agile - success or failure is shared. But each person takes responsibility for certain things and either delivers them or leaves the team
It is not always possible to pick the team, but it is essential to ensure that every team member is integrated and shares the common goals. The team is a live and evolving entity.
Humans communicate much more quickly and effectively face to face. That is basic psychology. But this does not mean that this is the only way to communicate in the project. A conversation is just a conversation. A conversation that leads to decisions which then turn into actions is Agile. In anything but the smallest teams, these conversations need to be recorded. Not in detail, but decisions made need to be written down and shared with anyone who might be impacted by those decisions. Conversations which do not lead to decisions need to be noted and flagged as areas for further conversation.
This relates to the idea of Agile documentation which I discuss elsewhere.
Producing hundreds of pages of specification documents is not an achievement. This is what waterfall projects tend to do. Even simple working systems are preferable because they can be tested with users, used to develop ideas and refine and improve the solution. This principle is a reaction against the waterfall model. A document is never a 'deliverable' or an achievement in Agile - it is a tool on the way to an achievement.
This is just not true. The manifesto got it wrong. That Agile processes promote sustainable development is definitely true. There is no concept of a product being 'finished'. Continuously reviewing and improving the product is part of Agile. The idea of maintaining a continuous pace indefinitely is wrong. Most projects have a natural end and most products have a limited life. The intention behind this statement is valid and simple. Do not just design/build it and run away. Your responsibility does not stop when the product is 'delivered'
Good design is core to any software development. That does not mean just a good interface design - we are talking about the whole software model. Designing with clear, flexible frameworks, leaving space for future improvements and developments are good design principles anyway, but within Agile it is central to maintain the flexibility to adapt to changing environments and needs.
Huge software with many features and every possible scenario handled is a characteristic of waterfall approaches. Despite this, these solutions fail to satisfy user needs. Build only what is absolutely essential to begin with. If more becomes necessary then you can add it (in consultation with users). Small, clean and extensible solutions are Agile. Think about the future and design the most generic systems you can, but do not build the details until you have to.
This a point where I disagree with the manifesto. A mature team should be self-organising and is closest to the users. So they will produce a better product. A new team will probably not deliver this. But people who are abstracted from the team are not going to produce the right architecures and designs either. A compromise is probably required.
Agile must be agile. It never becomes a fixed set of rules and rituals to follow. Agile evolves, and every Agile team evolves. You cannot define 'Agile' as a set of procedures, or say 'our organisation does Agile this way'. As soon as you do that, you are no longer Agile. The team must constantly examine itself. Agile teams must be trusted, and they can only do that of they are self-monitoring.