The USA’s Department of Defense has a Defense Industrial Base (DIB) Cybersecurity (CS) Program to safeguard information. Under the DIB CS Program, DoD and DIB participants share cyber threat information.
In October, the group released a detailed guide on one of our favourite topics, Agile software development.
Agile software development is an approach where ‘requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their end users’. In general, this means developers working closer with customers, and not having deadlines so much as tailoring a solution. It is supposed to improve the agility of software development to the needs of the users.
Some companies treat this as a mantra; such as Facebook’s ‘Move Fast and Break Things’, and in general means avoiding a set plan of phases to follow, and instead working in an iterative model where decisions and plans are constantly evolving.
To quote;
Agile is a buzzword of software development, and so all DoD software development projects are, almost by default, now declared to be “agile.” The purpose of this document is to provide guidance to DoD program executives and acquisition professionals on how to detect software projects that are really using agile development versus those that are simply waterfall or spiral development in agile clothing (“agile-scrum-fall”).
DIB Guide: Detecting Agile BS – https://media.defense.gov/2018/Oct/09/2002049591/-1/-1/0/DIB_DETECTING_AGILE_BS_2018.10.05.PDF
Whilst often first seemingly a great approach to development, it is often quickly hated by management for a lack of being able to plan budgets. If not, it is soon hated by developers for the lack of planning, or (possibly due to the lack of deadlines), having rigid processes in place. This almost always involve daily status meetings (called a ‘Scrum’), work on shorter sets of work deadlines called ‘sprints’, and fortnightly retrospectives where staff are able to blame each other before enjoying their weekends.
That said, when the Agile approach is accepted by all parties, it works incredibly efficiently, and allows developers to really understand what their users and customers need, and a real feeling of how the project should be developed. This should come without the need for constant planning of ‘user stories’, and detailed pre-emptive plans of user interfaces and designs.
Where developers are allowed to work directly with the users of the software, and have continuous feedback, and be able to do the work they should be able to, it’s a fantastic way to develop a quality project that fits the exact needs.
We’ve worked with quite a few ‘Agile’ teams, and though there are differences, many do end up the same. As always, open-minded and good management, and a quality team provide far more benefit to the end product than sticking to any particular process.
Image thanks to Jeff.lasovski – Own work