Agile development is the trending buzzword in the software development world, and for good reason. It is arguably the major revolution in the software development process over the past decade, says Clinton Bosch, architect at BSG Africa.
Scrum gatherings are a regular occurrence and are fairly well attended, but seldom by the actual developers. There is a distinct emphasis on the management pillar of the Agile methodology aimed at Scrum masters and managers and not quite as much emphasis on the technical pillar.
More than just Sprints and stand-ups
At BSG we have found (particularly during interviews) that developers often say that they know or practice “Agile” software development methodology, but when we dig a little deeper and ask what that means to them as a developer, it becomes evident that their understanding of Agile is often limited to the management pillar.
This management pillar (as understood by most developers) in a nutshell defines the overall processes. Work is completed in sprints and “iterative, collaborative development” is the name of the game.
There are a number of ceremonies or meetings that are prescribed to take place within a sprint by Scrum, such as daily stand-ups, backlog grooming, team estimations and planning sessions, as well as the all-important sprint review to present what has been done to the stakeholders.
Finally, the retrospective is held to reflect on the “gone-wells” and “gone-not-so-wells” in the last sprint in an effort to learn and improve. Scrum suggests the frequency and duration of all these sessions.
This iterative approach with short feedback cycles is great from a stakeholder’s perspective because it sets expectations and allows constant re-evaluation and refinement of the product through the prioritised backlog during the development process.
However, this is merely the first step in the evolution towards agility, but it doesn’t really make a significant positive difference in the lives of the developers other than a team cultural change.
Within the Agile process, the entire team essentially owns the estimation of stories on the backlog. This is a vast improvement on the old days of Waterfall where the senior developer of the team was given a technical spec and asked to provide time estimates. He then had to try to hold the team accountable for delivering to those timelines.
This process is made interesting by the use of tools such as estimation poker which engages all members of the team regardless of seniority. That all being said, so far we have only described half of the agile picture.
What is the real impact of Agile on software developers?
The most significant impact on the software developer is the “technical” pillar of Agile which involves the implementation of XP (Extreme Programming) techniques.
This second evolutionary step is much harder to implement as it requires a significant skills shift in the team and potential resistance by more senior team members. Core to this is the practice of TDD (Test Driven Development) and BDD (Behaviour Driven Development) and in our experience, this has often been overlooked when people talk about what “Agile” is.
These two techniques are used in parallel and have two very distinct purposes. TDD ensures that the software is being written correctly whilst BDD ensures that the correct software/functionality is being written.
TDD is the design practice of writing your tests before even beginning to write the functionality. This may sound backwards but it has multiple benefits (listed below).
There are a number of different kinds of tests that can be written such as integration tests, smoke tests, end-to-end tests and so on.
However, the majority of tests within the testing suite should be unit tests. Often developers think that writing unit tests is advantageous because of the part they play in regression testing. While this certainly is a huge advantage, we would argue that it is a nice side effect of writing unit tests rather than the initial objective.
Advantages of employing test-driven development
* It causes the developer to more carefully think about functionality by identifying all the race conditions and possible errors that need to be catered for when writing the functionality, before writing it. Effectively you are trying to break the code before writing it.
* It also forces developers to design code cleanly in a layered architecture. Spaghetti code is impossible to test, due to the fact that you are unable to mock out dependencies to the unit of work under test using any of a host of mocking frameworks available.
For example, a developer cannot write a quick SQL query in the middle of his method because he would not be able to write his unit test. He can only mock out the database dependency in the unit test once he has written a proper repository layer.
* Often, it is in fact faster to develop a piece of functionality using tests. If you consider writing some functionality in an enterprise client-server application, this takes a fairly long time to compile and get your environment into the state where you are able to actually test your specific change. It is far quicker to write a few test cases to test all scenarios.
* As mentioned above, the test then remains to highlight regression issues in the future.
* These tests are also much easier to maintain going forward compared to tests written around poorly designed code without using TDD.
TDD can also be used in an extension of the controversial practice of pair-programming called ping-pong-pair-programming. Here, one developer writes a failing unit test and then “challenges” another developer to write the functionality to get the test to pass. The cycle can be repeated any number of times while thinking of race conditions that could cause the test cases to fail.
BDD is a technique developed by Dan North, to be used in conjunction with TDD, to effectively address the problem of ensuring that the functionality written meets the users” needs. It requires acceptance scenarios to be written for each piece of functionality in the format of Given, When, Then.
These plain text scenarios can then be used in the writing of automated acceptance tests using frameworks like Jbehave. Unlike unit tests which test small units of work in a single layer isolated from all dependencies, acceptance tests transect all the layers of the application to test the entire use case.
Whilst many argue that these techniques result in a much slower development cycle, studies have shown that although the initial development is slower than “old-school” development, it does not take long before the cost of TDD development breaks even when it comes to maintenance and bug-fixing.
The cost of bug-fixing is significantly higher than normal software development and, if development is slowed down a little to allow the development team to write software properly using the above mentioned techniques, in my experience, the result in the long run is definitely superior and well worth it.
Our intention with this brief summary of Agile development, is not to describe the details of these techniques – there are many excellent books on the market for that – but rather to highlight that whilst part of the methodology is well understood and equally well documented, if the technical aspects are not also implemented, your approach is nothing more than lip service.
There is clearly more to Agile development than sprints and stand-ups and there is a fairly big mind-shift that needs to be made by a development team before they can brand themselves “AGILE”.