Agile methodologies for software development
Agile methodologies for software development are concepts for software engineering project management. We use a lot of agile methodologies and techniques here at NetEngine. No individual framework must be adopted whole - there are advantages to each, and we have made some adaptations of the fundamental practices to suit our team. You may be interested in making similar changes once you see how we adapted them for our team and why it works so well.
Manifesto for Agile Software Development
First of all, I will mention the Agile Manifesto. Previous models of software development - eg.: “waterfall” - were bureaucratic, slow and contradictory. Then, in 2001, the “Manifesto for Agile Software Development” was published, which represented a great revolution with regard to previous methodologies. Its key values are:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Although there are several methodologies created or adapted for Agile Software Development (such as “Adaptive software development” and “Dynamic system development method”), the two most common and most used here in NetEngine are Scrum and XP.
Scrum
The basic cycle of Scrum is the one above, with the overall backlog and the Sprints backlogs, a Sprint cycle (2 ~ 4 weeks) and the daily cycle to get done as a product.
Scrum is easy to understand and you need very little to get started. To manage the entire process, you can use several implementations, like Kanban or a specific software. There is also software which offers its own adaptation of project management based on Scrum, but with extra features, such as Trigger - which is of course our choice.
Artefacts:
- Product Backlog: contains all the tasks up to the end of the project. New tasks can be added as new requirements appear.
- Sprint Backlog: contains only the tasks for that Sprint. Once begun, the ideal to strive for is to leave these tasks unchanged.
- Burn down: a chart publicly displayed which provides a quick visualization of the remaining work in the Sprint backlog. See the chart below:
Team:
- Product Owner: our customers.
- Developers: our software engineers. It is a self-organising team, who develop the software and create technical solutions.
- Scrum Master: our leader, who is accountable for removing impediments. He is not the team leader, he is like a soccer captain instead of a foreman.
Meetings:
- Daily: happen every day, always, at the same time. Each participant speaks typically about three things: on what worked in the previous day, what will work in current day and if there is any impediment preventing him from go ahead with a partucular task.
- Sprint planning: happens before each Sprint, in order to select which tasks (from Product Backlog) will be developed within that Sprint.
- Retrospective: happens after each Sprint, in order to raise what was good, what was bad and if anyone has any questions regarding this last Sprint.
Other tools and techniques:
In addition, other tools and techniques could (and should) be used together, for example, Planing Poker, Pomodoro, ZTD, etc.
XP
Another methodology quite interesting is the eXtreme Programming (XP). We are proud to say that we use daily all of its foundations (see list below) and that it works very well for us. XP methodologies consist of:
- Pair Programing: a technique in which two programmers work together at one computer. While one develops the code, the other reviews and discusses whether he agrees with the approach chosen. The two programmers switch roles frequently.
- Code Review: a technique whereby one developer writes code and then a second one checks the code developed before it goes to production.
- Refactoring: The code you developed yesterday is already considered legacy. Refactoring is a technique which ensures that your software is ready for quick changes, in other words, it ensures you will always have well-organised code.
- TDD: Test Driven Development a technique where automated tests are built into the code. There are two main reasons for it: when you write the test before implementation, it will guide the development and; TDD facilitates the evolution of the code, ensuring that nothing written before will crash. We have a post about this in more detail.
- Develop useful things:: avoid development of features unless they are essential to an application.
- Continuous integration / Small releases: deploy your implementation to production often. Instead of having a new version of the software per week, you deliver a new version of the software per day or maybe more quikly. This helps a lot to prevent the software from taking a wrong direction.
Conclusion
Depending on the type of company or team in which you work, some techniques may be difficult to apply. For example the daily meetings are the element of Scrum we really like. It works very well for our team, because everyone is well informed about the important events happening, and is exposed to ideas from any other projects going on in the company. On the other hand, we’re aware that for some projects, and commonly, for later phases of a project, the rigidity and expense of sprints isn’t always suitable.
This is the interesting part of agile methodologies, you can adapt them for your team and make them work the best way possible. Feel free to include your comment below telling us your way to use any of these tools.