Available technologies are changing, which leads to changes in the prices and availability of the products currently on the market, which changes the market, which changes consumer habits, which means you might need to change as well.
If you are still planning projects months ahead, then locking your employees into fully committing to those projects even when, because of bottlenecks, they have nothing to actually do, you might have trouble keeping up with our race towards singularity.
Agile custom software application development is an attempt to respond not only to these changes, but to whims of fate, investors or customers, unexpected personnel changes, and everything else that might disrupt your plans. Here’s how it attempts to achieve this, and how you can apply the same principles in your business, whether it has anything to do with software development or not.
Formulated in 2001, Agile has been developing ever since, giving birth to a range of individual frameworks like Scrum and Kanban. It is encapsulated in twelve principles which focus on flexibility; using working software, not completed tasks as a measure of success and rapid delivery of that software; employee communication and self-organization; constant input from customers, management and investors; and face-to-face communication when possible.
The best way to see what this looks like in practice is to take a quick look at one of the most popular frameworks of this type, Scrum. This approach involves segmenting the total workload into sprints, short periods of time, usually up to one month in length, during which the team holds short, daily meetings to discuss their progress, reallocate some of the tasks when needed and incorporate new external changes into the workload. The sprints are supposed to end in a delivery of a working software functionality, or the software itself.
You can try out free scrum tools to get a much more detailed description of this framework (and later apply it), but even this simplistic overview emphasizes some of the main benefits of this approach. Now let’s see how you can translate these ideas to project management in other industries, and what you stand to gain by doing so.
Waterfall model assumes the linear progression of task completion and is one of the main reasons for chokepoints in the workflow. A project is planned as a sequence of steps, in which beginning to work on step three is predicated on the completion of step two. While some processes in some industries do have to adhere to this task distribution (you can’t paint a car before you’ve actually made it) there is always room for flexibility (you won’t wait till you’ve done with the chassis to start making the seats).
However, because waterfall way of thinking is so ingrained, we often don’t even consider looking for ways to break out of it.
One of the Agile practices that would help you in this regard is the introduction of priority backlogs. These are basically lists of tasks (most of which can be simultaneously executed) which are essential for the completion of a particular product segment. Each sprint involves a segment of the backlog, possibly even changing the order of priorities if the need occurs. Daily discussions between team members can lead to these changes, as can outside input. This kind of flexibility ensures that the critical parts of your workload are not being ignored, and that all of your employees are working at their capacity.
Traditionally operated SMBs do have meetings, employee reviews, etc. but they are consistently formal and often inefficient. Agile promotes intensified, personalized communication on all levels, between employees themselves; employees and management; management and investors, and between the company and their customers.
In practice, this is mostly handled through daily meetings. A customer or an investor may want another feature added to your product. During the next daily meeting, the necessary tasks are added to the backlog, people who will actually be doing the work directly distribute it amongst themselves, ensuring no one is given a task they can’t complete because of time constraints or anything else; and feature implementation has already begun.
This kind of self-organization improves everything from morale to efficiency, and it helps your team members become more outspoken not only with each other but with management as well. When properly implemented, this means that a project will never be late again just because your employees hesitated to tell you that it simply cannot be completed by the agreed deadline.
Agile framework, while allowing for faster software delivery, better communication, waste reduction through constant task priority reassessment, etc. is not a magical cure for efficiency problems. Even some software development companies are having problems adopting this approach, and they are the ones it was initially conceived for.
The main reason for this is that people often try to apply it as a set of rules, instead of a mentality. If you want to avail yourself of some if its benefits, you cannot be dogmatic about it, and you can’t be scared to let go of just a bit of control. After all, adopting a flexible approach does require some flexibility on your part as well.