Tell me if this approach sounds familiar to you:
A client approaches you or your company for a piece of software to be developed. You have a meeting with the client and maybe even have him fill out a questionnaire to help with understanding his scope and needs. You both agree on a deadline.
Based on the above, you brief your team to start work on the project. The team gathers the necessary data and starts planning the necessary functions and timelines. The work commences.
As time goes by your team hits roadblocks, one or two sections do not gel well with each other, or a piece of code was developed with a bug in it that now needs to be found before you can proceed. The client is informed of the delay and still opts to continue with a delayed start date.
As work continues, the setbacks have caused a domino effect and resulted in the development of the remaining functions and requirements to keep getting pushed back. The client gets frustrated. The development team rush and cut a few corners to help get the project done faster.
This causes further bottle necks in the quality testing department. The quality team themselves must rush which causes them to miss several key errors and changes. In the end when the software is finally delivered to the disgruntled client, it is of poor quality and does not solve the need for the requirement they laid out in the first place. Your development team is burnt out and dissatisfied which may end in many members opting to leave for better work environments.
These are the drawbacks of the traditional Waterfall Method of software development. In the current status quo of the development cycle, the process goes a little something like this:
It is a linear, one way flow type of process which does not leave much room for flexibility. It is also a very cold, process driven system that does not consider the human element behind development. This type of approach is still the defacto system that is in place at most development firms across the globe. It is a process that a development company automatically assumes and settles into. It follows a common path of logic within our minds.
But as software and apps are more prevalent in daily lives, and user-bases continue to grow, this approach to development, continuous updates and improvement will be very difficult to sustain.
Here at Gapstars we embraced Agile software development. A set of values and principles that help develop software faster, with greater adaptability and customer collaboration. Agile Development has been in existence for over 16 years. This approach not only helped Gapstars become more flexible, but it also considers the people who work on the development projects and what would be the best way to communicate quickly to get changes and improvements through the pipeline faster and out to customers. Best of all, customer requirements can still be accepted no matter how far down the development pipeline a project is.
At the turn of the millennium, after the world realised the apocalypse was going to be delayed, a bunch of prominent developers from some of the top software firms met at a lodge and laid out a new manifesto. They decided to call it Agile. What each of them had noticed was that as the access to the internet, and computer infrastructure grew, so did their user-bases and so did what people wanted to do with their computers. To add further concern, was the rise of the smartphone/pda which put computing in the pocket. This meant that the conventional approach to software development was going to be out dated very soon and a new methodology was needed asap.
They also came to notice that the many companies do not put their employees first, and they are the driving force behind innovation, productivity and quality of software.
The 12 Principles of the Manifesto are as follows, the wording has not been changed and is an excerpt from the original Agile Manifesto website that was setup back in 2001 http://agilemanifesto.org/principles.html:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals.
- Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development.
- The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
As can be seen, the principles do not talk about structured processes or even ways to tackle problems, they are a set of value and beliefs within an organisation, and puts a great deal of emphasis on the human element and the ability to communicate and work together. The goals for each project are incremental, thereby lending themselves to flexibility, and above all, client requirements can be taken in at any stage of the process.
Great you must be thinking, but how can I go about implementing Agile development at my company or even within my team?
Well, change must come from within, start by explaining the merits of the approach to all stakeholders and show them the benefits of the new approach compared to the current one. Also, put emphasis on the human aspect and how it considers team well-being and harmony.
Once everyone comes on board, have a discussion as to why you might need Agile and how it can best help you achieve your goals. There are several methodologies and techniques that can be adapted, combined and customised. With collaboration, you can decide on a workflow process to follow. To know more about team management approaches, look up SCRUM and Kanban. These are 2 of the most common approaches to agile adoption.
Was our introduction into Agile Development insightful? Are you considering it? Have you or are you currently working in an agile environment? Let us know in the comments below.