Agile is a set of principles and behaviours, which aids the governance of organisations, and the management of people developing software. It's a relatively new way of working, and is revolutionary compared to the way things have been done in the past.
Prior to the advent of Agile, software development was executed as a linear process (using Waterfall methodology). As such, development teams would spend a couple of months writing specifications, followed by a period of building the software to those specs, a month testing, and so on. The theory was that software could be specified to such a detailed level that the developers could go off and write it without having to interact with the people commissioning the solution.
More recently, people have realised software development is a lot more fluid than that. And in that spirit, Agile, broadly speaking, changes that methodology of how to go about developing software. It talks about valuing interactions between people more than processes, and valuing working software more than reams of documentation.
There are different specific frameworks within Agile (such as Scrum), and specific practices like extreme programming (XP), which use Agile principles and put them into structured ways of working.
Elastic environment
Agile came about partly in response to changing business drivers. So much is dependent on software today, and development needs to be agile, fast and flexible to respond to a rapidly changing business environment if it is to deliver any value to business at all. Agile gives a technical bedrock to base that nimbleness on.
There are several misconceptions about Agile in the local market, possibly because it is less well understood than its older counterpart. One of the bigger misconceptions is that it's chaotic. In actuality, Agile is extremely organised and predictable, but can change rapidly. It's like watching rugby - if you don't understand the game, it appears to be nothing more than a bunch of men chasing a ball and knocking each other over. Once the rules are understood, the strategy and how the pieces move and work together can be seen.
Agile is extremely organised and predictable, but can change rapidly.
Another big misconception is that Agile is less structured than waterfall. Because Agile assists teams in making changes quickly, people somehow associate this ability with a process that's not structured. True, Agile is very structured and each framework specifies the roles people have and the processes to be followed - for example, the types of meetings a company should have, how often, the artefacts to be produced, how to go from idea to specification of functionality to delivered functionality - and those processes are rigorously defined.
Crystal clear
An argument for the degree of structure in Agile is the visibility it provides. Agile, if done right, makes it easier for stakeholders to know where a project is right now, and how much more effort is going to be required to get to a particular stage. This is because requirements are broken into small, sensible pieces, and every stage of development is transparent - allowing for visibility into the 'piece' the team is working on, the priority level of that piece and what will be delivered once it is complete. The ultimate question is always 'when can users have this?' and Agile ensures every bit of functionality is completed in such a way that it can be delivered to users immediately.
People sometimes think Agile is slow, that it is too time-consuming. Getting a project started takes time, a lot of everyone's time, and involvement. Clients sometimes resent the commitment required, and hope to telepathically communicate their needs to development houses, and then show up months later when their project is ready. Agile is not slow, but it does require a significant upfront investment to ensure a quality product is delivered.
If that time is not invested upfront, it will be spent on support afterwards, and going back to fix what wasn't done properly initially. Additionally, stakeholders need to confirm, at each stage, that what is being delivered is what they need. Developers need to understand what a client's business does, and what their customers need. This will allow the delivery of software that effectively targets those needs and the business's requirements - and that process of learning and understanding the nuances of the business takes time and investment from both parties.
Perhaps the biggest misconception about Agile is that it's optional. It will become harder and harder to succeed as a company without some mechanism to rapidly respond to customers' needs. If business solutions are not what clients require, and if companies do not respond quickly to client demands, they will lose business.
Companies need to be able to turn around to customers and say: "I have heard you, here is the answer." If they don't display agility, they will become extinct.
It doesn't need to be called Agile, but it does need to be happening.
Share