Once upon a time in the world of programming, years could pass between the identification of a business need and the launch of the software to meet it. In the interim period, it’s highly likely that the original business case would have evolved, meaning the software was already obsolete at launch. The greater the complexity of the project, the more out of date the software solution was likely to be when finally built. The rigid methods employed to develop the software allowed little flexibility of scope once the build was underway.
When the Space Shuttle program launched in the 80’s it used technologies from the 60’s – development had taken decades not years. Requirements and systems evolved while the software development process crawled along.
Early programming methods followed the methods originally developed for physical engineering projects such as bridges and dams. These projects tend to be approached with a rigorous planning phase that aims to reduce the time spent on the build itself, with functional specialists handing over to a new set of specialists, and the disciplines kept in separate teams.
Under this approach, the aim is for planning to stop at the point the build work begins. Architects hand over the plans to construction managers at the end of the design phase, and they aren’t supposed to revise the designs after that point. If the plan is revised during the build process, it’s usually seen as a badly-run project.
But other hardware engineering methods were being employed even before the IT revolution. In the 1950’s, iterative and incremental development methods were used to create the X-15 hypersonic jet. The ‘learn as you build’ approach was more appropriate to such innovative technology.
Toyota used this kind of methodology to innovate in car design and production, and teams started working in cross-disciplinary collaborative ways during the build. Eventually, the time it took to design a new car was halved using these more collaborative methods.
Sometime around the year 2000, this approach to software development emerged as a conscious discipline. The main characteristic was that nothing was set in stone at project outset: every element of it can change without the entire project collapsing.
The development team build their first response to a user need, it’s tested by those users, and if necessary, rebuilt to better accommodate what those users really want and need.
It’s a development approach that’s orientated around getting rapid feedback from users and incorporating that into the ongoing development process. Working versions of the product are regularly demonstrated to stakeholders, meaning they get input during the build.
Rapid response
In today’s highly competitive technology landscape, the Agile approach is particularly useful for getting products to market quickly. Often evolving off the back of other technologies or developments, new projects need to be launched quickly before competitors can get theirs out.
One way to approach Agile development is to use the Scrum development framework, which excels at laying a framework for communication, particularly across the different functional disciplines in any development team. In Scrum working, design and UX specialists collaborate with front and back end devs, and there’s also a formal role for the client to keep them involved. There’s a framework for regular meetings, and there are different types of meetings including daily standups and planning meetings at regular intervals.
Scrum offers a very flat team structure, which may be unfamiliar to team members from a more hierarchical working culture. But because it formalises communications and involves every member in progress meetings, a properly run Agile project usually gives enough structure that it creates its own internal working culture and gets people communicating across the disciplines.
You could argue that the rituals Scrum insist the team follow create a working culture that’s accessible to everyone. It’s a unique working environment that can help bring people together in the best way to finish a project.
That’s particularly valuable when teams are made up of people from very different working cultures and backgrounds. A modern day development project is likely to have people from a wide range of backgrounds, working in a range of disciplines.
Logical, detail-focused back end developers work alongside people-focused business analysts and language-focused content specialists, organised project managers and product owners that are entirely user-focused.
These different disciplines will have very different mindsets and ways of approaching a problem. Giving a fairly firm structure to their working lives is valuable because it helps unite people coming from very different directions.
There’s a skill shortage right across the technology sector at the moment, and although many in the industry are exposed to the discipline, there remains a shortage of people with experience of Agile working. Good scrum masters or UX managers are hard to find and there are few content designers with the experience necessary to work on Agile developments. But the ubiquity of Agile working means that it’s fairly easy for developers at least to fit into new working environments that are using familiar frameworks such as Scrum.
The backlash
Agile may have been adopted worldwide as a development framework but not everyone is enamoured with it. The ‘cultish’ nature of Agile working methods frustrates many, with some critics complaining that there’s too much focus on meaningless rituals such as those outlined by Scrum to the neglect of good development decision-making. There’s even been criticism of the language Agile employs.
One element of Agile that’s often overlooked by critics is that by laying a pathway for daily communication, it’s helping cross-cultural and cross-language teams come together in a shared working culture. In a world where development talent often has to be sourced from across the globe, Agile is a good way to create a working culture that achieves results.
For all the criticism Agile receives, it’s popular because it’s the best method for software development anyone has managed to come up with yet.