Just finished reading the 10th State of Agile Report from VersionOne. I have written before about data from this report. See «Top six reasons for failure of Agile projects«.
This time one question caught my attention. Respondents were asked to state which agile techniques they use. They were able to give multiple answers. Because of a project I am currently involved in I was very curious about the answers regarding used Agile Engineering Practices.
The response was as follows:
– Unit Testing (63%)
– Continuous Integration (50%)
– Single Team (integrated dev and testing) (45%)
– Refactoring (37%)
– Test Driven Development (33%)
– Automated Acceptance Testing (28%)
– Continuous Deployment (27%)
– Collective Code Ownership (25%)
– Pair Programming (24%)
What can I say… This is a sad state of affairs. Or looking from the positive side. There is a lot of potential for many agile development teams to step up their game and improve. Scrum is the most used agile process method according to the survey, and Scrum itself says nothing about Engineering Practices. Scrum is not limited to be used for software development only. But as soon as you use Scrum in software development, solid Agile Engineering Practices are essential to do Scrum right. I have written before on this in my article «Three must have Technical Competencies for Scrum Teams«. Some additional thoughts…
Unit Testing
The purpose of unit testing is not for finding bugs. It is a specification for the expected behaviors of the code under test. The code under test is the implementation for those expected behaviors. So unit test and the code under test are used to check the correctness of each other and protect each other. Later when someone changed the code under test, and it changed the behavior that is expected by the original author, the test will fail. If your code is covered by a reasonable unit test, you can maintain the code without breaking the existing feature. That’s why Michael Feathers define legacy code in his book as code without unit tests. Without Unit Tests your refactoring efforts will be a major risk every time you do it.
Continuous Integration
Martin Fowler defines Continuous Integration (CI) in his key article as follows: «Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.» You see, without Unit Tests and Test Automation it is impossible to do CI right. And only when you do CI right you might be able to succeed at Continuous Deployment.
Single Team
It is hard to grasp that this is still not implemented by so many agile teams. In order to deliver high-quality software every iteration, your development and testing should be done by a single team. Not just that, your team should be a Feature Team.
Refactoring
Code should be written to solve the known problem at the time. Often, teams become wiser about the problem they are solving, and continuously refactoring and changing code ensures the code base is forever meeting the most current needs of the business in the most efficient way. In order to guarantee that changes do not break existing functionality, your regression tests should be automated. I.e. Unit tests are essential.
Test Driven Development
Test-driven development is a development style that drives the design by tests developed in short cycles of:
1. Write one test,
2. Implement just enough code to make it pass,
3. Refactor the code so it is clean.
Ward Cunningham argues that test-first coding is not testing. Test-first coding is not new. It is nearly as old as programming. It is an analysis technique. We decide what we are programming and what we are not programming, and we decide what answers we expect. Test-first is also a design technique.
Automated Acceptance Testing
Also known as Specification by Example. Specification by Example or Acceptance test-driven development (A-TDD) is a collaborative requirements discovery approach where examples and automatable tests are used for specifying requirements—creating executable specifications. These are created with the team, Product Owner, and other stakeholders in requirements workshops. I have written about a successful implementation of this technique within Actuarial Modeling.
Continuous Deployment
Continuous delivery is a series of practices designed to ensure that code can be rapidly and safely deployed to production by delivering every change to a production-like environment and ensuring business applications and services function as expected through rigorous automated testing. Since every change is delivered to a staging environment using complete automation, you can have confidence the application can be deployed to production with a push of a button when the business is ready. Continuous deployment is the next step of continuous delivery: Every change that passes the automated tests is deployed to production automatically. Continuous deployment should be the goal of most companies that are not constrained by regulatory or other requirements.
Collective Code Ownership
Collective Ownership encourages everyone to contribute new ideas to all segments of the project. Any developer can change any line of code to add functionality, fix bugs, improve designs or refactor. No one person becomes a bottle neck for changes. This is easy to do when you have all your code covered with unit tests and automated acceptance tests.
Pair Programming
Having 2 developers work on one piece of code, using one keyboard and one monitor. Pairing results in higher quality output because it greatly reduces wasted time and defects, and results in high collaboration. It is noting else as continuous code reviews. Hence, when implemented you do not need code reviews before merging your branches, hence continuous integration can be done faster.
Those who are familiar with Extreme Programming (XP) will notice that many of these techniques originate from it. Ron Jeffries in his (highly recommendable) book «The Nature of Software Development» goes even that far that he says that Scrum combined with Agile Engineering Practices is nothing else as XP. I see his point. It is about wording and labeling. The ideas and principles are the same.
I am a very strong believer that without successfully implementing Agile Engineering Practices it is impossible to be agile in software development.
