Software Development for the 21st Century
The Agile manifesto was written it 2001. It was a reaction against old practices - but it was written before ubiquitous computing - mobile phones, televisions, game boxes, wearable computers and house-hold appliances attached to the internet. It was written before Internet distribution of software and 'app stores'. I do not dispute the values, but maybe the principles need revising. A lot has changed in the 21st Century.
If you cannot understand it, it isn't Agile. This applies to your communications, your models, your designs, your documentation and your code. Big complex documents with versions are unacceptable. As an individual you can do that if you want to, but the team, stake-holders and project need simple and clear communications which make sense to everyone. Designs may have much detail, but there is always a version that everyone can understand. Code should be clean enough to pick up and read without documentation.
Do not commit to any detail until you have to. Create design frameworks which are easily modified in the light of user reactions and new developments. Use any tool that makes change easy.
User-driven design is often good. But users are not the only creators/consumers of a piece of software - it is increasingly a machine talking to another machine. Concentrate on what the actual usage is - highest usage first. That does not mean ignoring users, but focus on what the system is actually used for.
Do not confuse a solution with a front-end. Drive things from the front-end and the user needs, but remember there may be a lot of mechanism behind the scenes to deliver a simple experience to users. You need to explore the full depth of the software stack early in the project. Show that you can deal with all levels of the solution, and that the problems are solvable at all levels. You do not have to build the full depth immediately, but you need to do enough to show that it can be done.
Build the least you can get away with. Then expand. An Agile project never ends, but it just does enough. Keep your software, your code, your user interface as simple as possible and only extend it when you need to.
Never write proprietary products or one-off code. Use standards as much as possible. Use and re-use open-source libraries and systems when you can - they have often been tested more than you could ever do it. Design your systems with as many re-usable components as possible and share them with the community whenever you can.
Never specify or design something before you need to. You cannot anticipate everything, so don't try. Planning is essential but plans are useless. Look ahead, work out the big picture, identify any potential problems and resolve them. But do not fill in the details of any design or code until the last possible moment. Things may change between now and then. Remain flexible in what you deliver until the last possible moment.
This is a core idea in Agile. You cannot design and specify everything, then build it. So do not try. Design and build in short cycles, try it out with stake-holders, get feedback, change. Do not expect to get it right first time. Mistakes happen, misconceptions arise. Get systems in front of people fast, listen to how they respond and adapt accordingly.
An Agile team is a team. There is no hierarchy. For Agile to work everyone must understand what is going on and be in agreement with it. You cannot work in silos. You cannot allow someone to control. To do that would be to lose the advantages of Agile. People on the team do not (mostly) have roles, but let us say they have 'primary specialities'. They can work across other areas and the team should build those skills. In a good Agile team there is is no-one whose role is not covered by someone else. Clear communication is essential - everyone must understand what everyone else is doing and how it contributes to the project objectives.
Never try to micro-manage - or even manage - an Agile project. Management is a team activity. Each person on the team is trusted to do what they do and to inform the rest of the team if problems or issues arise. If there is someone on the team that you cannot trust to do this, then they should not be on the team.
Waterfall has a design/specify, build, test, deploy structure. Agile does not. Those stages make not much sense. In particular, there is no end to the project. It will get smaller and require fewer staff over time, but it is never over. Planning for this and ensuring the correct resource is available throughout the project is essential.
Agile is not really a methodology. It is a different way of thinking about software development. When you are truly Agile, you can use any methodology you like. Detailed program proof is acceptable in Agile, for example. But the point is that you consider each methodology individually and assess its appropriateness to what you are doing. So program proof is useful in (some aspects of) aircraft design or financial services. The point is that you do not just use a methodology because you can, or because the business has always done that. You must justify it.