Understanding Agile Software Development
This article talks about the basics of agile software development methods. It does not dive into details of any specific method. There are Scrum, Extreme Programming and many other agile software development methods which a reader will find through the internet. There are wikipedia and official websites for explaining how each method works. However, I have found that lots of sites explain on how agile method works and not why development needs to be agile in the first place.
Downside of Traditional Approach
Let us first examine what was wrong with traditional approach. One of the popular conventional approach was called ‘Waterfall Method’. The development used to work like a waterfall. It was a one way development process where client feedback tends to be at the very end. The developers used to gather user requirements (user stories), start developing, finish the software and get back to client for feedback.
The problem with the conventional approach is that it is difficult for clients to complete perceive the software before it is fully developed. Converting requirements to a quality software is a complex work. The software resides at a conceptual level in client’s mind in the beginning. When developers takes the fleshed out software to the client, the differences between her requirements and the software start to emerge. At that point however, it becomes very difficult for the developer to go back to the initial stage and make any significant change.
Of course, I have oversimplified things and made the whole development process generic. The actual scenario may not be so simple. Nonetheless, this is the essence of the problem. The solution is, as you might have expected, better and more frequent collaboration between users and developers, making clients more involved from the very beginning and work with them as partners in the development process. There came agile development.
The Essence of Agile Software Development
Agile methodology suggests to develop a rough version of the entire software and then go to the product owner for feedback. The product owner matches her concept with the software and suggests improvement. The developer comes back with feedback, continues coding, makes adjustments and takes an improved version of the software to the owner and thus, continues the process. By the time the software finishes, it fully incorporates the requirements and expectation of the client. The result is better software and more client satisfaction.
Experts have come up with the different terms to structure the method. ‘Iterative’ and ‘incremental’ are two common terms used for agile development. That basically refers to developers going back and forth to clients and making the software better in the process. Each ‘draft of the complete software’ is called sprint. The first draft is the first sprint, the second draft is the second sprint and so on. Developing, frequently meeting, incorporating feedback and again developing is called a feedback loop.
Let us look at how my team Nascenia works.
After signing the contract we collect user stories and take the requirements in project management tools. After designing UI, we start developing the application (code). We test, push to Git, deploy to test server, take approval from the client. If you look carefully, we continue coming back to development as long as the application needs improvement. When work finishes, the application is delivered to the client. Sometimes a client decides to add additional features to the application. So we come back to development and work on the application again.
No matter which agile development style a firm follows, it is better to stick to a particular development style. It helps developers to grow a habit and create better software. Personally, I think the 15-minute meeting each morning is immensely helpful.
You can check out more of my articles here:Mushtahir Aziz Rahman, Business Executive, Nascenia