Wednesday, January 13, 2016

Three must have Technical Competencies for Scrum Teams

Three must have Technical Competencies for Scrum Teams
One key element of working agile in any organization is technical competence. Why is that? Well in my opinion as an organization you can only be agile when you are able to make changes to the product in an easy, fast, and flexible way while maintaining desired quality.

In that sense your organizational agility is constrained by technical agility. In other words, when you are slow in making changes to your product, then it doesn’t matter how you structure your teams, your organization or what framework you adopt, you will be slow to respond to changes. Bas Vodde and Craig Larman from LeSS (Large Scale Scrum) wrote extensively about this in the context of the LeSS Framework and Technical Excellence. I fully agree with them in a Large Scale Scrum environment, but I am also the opinion that for a single Scrum team technical competence is essential in order to be good and get the benefits from Scrum (or any other Agile framework).

Luckily, there are a few well established agile engineering practices that can help the team to keep their work in a high quality and in a flexible state. The three practices that I think are essential for any agile team to master are the following:

- Continuous Integration
- Unit Tests
- Test Automation

Continuous Integration

Martin Fowler writes in one of his key articles the following:
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.
Based on the above definition and their experience Bas Vodde and Craig Larman define Continuous Integration as:

- a developer practice…
- to keep a working system
- by small changes
- growing the system
- by integrating at least daily
- on the mainline
- supported by a CI system
- with lots of automated tests

I do not want to go in detail about the items above, since the guys from LeSS have already done an excellent job doing so. But one thing I would like to point out. Discussions about CI all too often are about tools and automation. Though important, CI in essence is a developer practice. Owen Rogers, one of the original creators of CruiseControl.NET writes in one of his articles:
Continuous integration is a practice – it is about what people do, not about what tools they use. As a project starts to scale, it is easy to be deceived into thinking that the team is practicing continuous integration just because all of the tools are set up and running. If developers do not have the discipline to integrate their changes on a regular basis or to maintain the integration environment in a good working order they are not practicing continuous integration. Full stop. 
Unit Tests

Unit Tests are software programs written to exercise other software programs (called Code Under Test, or Production Code) with specific preconditions and verify the expected behaviors of the CUT. Unit tests are usually written in the same programming language as their code under test.

Each unit test should be small and test only limited piece of code functionality. Test cases are often grouped into Test Groups or Test Suites. There are many open source unit test frameworks (link). Unit tests should run very fast. Typically hundreds of unit test cases within a few seconds.

The purpose of unit testing is not for finding bugs. It’s 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 you code is covered by 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.

Test Automation

Agile developers emphasize the importance of automated tests. With short cycles, manual regression testing is nearly impossible. Does that mean there is no manual testing at all? No. Some manual testing is still recommended, though such testing differs from the traditional script-based manual testing. Elisabeth Hendrickson, the author of the mini-book Exploratory Testing in an Agile Context, dares to state that:
I do think that if you can write a manual script for a test, you can automate it.
Teams often claim “It is impossible to automate tests related to a lost network connection” or “You can’t automate tests related to hardware failure”. In most cases the answer usually is “No, it is not” or “Yes, you can.”

It may be difficult to automate a test in exactly the same way as it would be carried out manually. For example, it is nearly impossible to remove the network cable automatically in a connection-lost test case. Therefore, the automated test is usually done in a different way. Instead of the cable being physically detached, the automated test instructs the driver to respond as if the cable were removed.

Is automating all tests worth it? According to Hendrickson:
If it’s a test that’s important enough to script, and execute, it’s important enough to automate.
Why is this? Iterative and incremental development implies that code is not frozen at the end of the iteration but instead has the potential to be changed each iteration. Therefore, manual regression testing would mean rerunning most of the manual test – every iteration. Automating the tests therefore pays back quickly. Automating all tests might not be worthwhile or even possible. But many of them do.
Posted on Wednesday, January 13, 2016 by Henrico Dolfing