Engineering practices – Just how important is it to get them right?

Most discussion taking place in the Agile community today seems to be centred around management practices (estimation, distributed teams, scaling etc.). Scrum – the most used of Agile frameworks only talks about the team organisation & ceremonies but remains silent on engineering practices.

Does this means that teams can become Agile by ignoring the basic building blocks? Not quite, on the contrary the moment team adopts (or forced into following) Agile practices, warning lights starts to come on if the necessary continuous integration set-up isn’t in place, if ignored the problem then becomes so serious that team giving up on Agile – thinking it was just another cunning plan by management to pile more pressure on them to deliver, or worse – start blaming the process.

Hence, if you are thinking of adopting agile on your new project, your first port of call must be to get the engineering practices (source control, automated builds & set-up for automated tests) in place. This is your Sprint Zero, now write some useful code (even a if it’s just minor piece of functionality) and once you are confident that any further change you now make to your software will be ready and tested before next morning or earlier focus on other aspects of the process.


On the other hand, if you have an existing project where you plan to go agile – Create what I would call ‘engineering practices’ roadmap (i.e. rightly sequenced stories) and get product owners support and agreement on the upfront investment needed.


The work doesn’t stop here, in both new and existing projects, teams will have to continue building automated test cases as functionality gets added – so that any new function that you put in does not increases the duration it takes the code to build and test.

We will dwell into details around specific engineering practices in the coming weeks, but at the minimum following set-up is needed (more the merrier)
1. Perhaps the most obvious one – a Stable Source Control Tool
2. Automated Build Tool (e.g. Maven)
3. Automated Test Creation & Execution set-up (e.g. JUnit)
4. Dashboard showing build & testing health-check (e.g. CruiseControl)


Additional tools include Behaviour Driven Test frameworks such as FIT, Code quality management and reporting tool such as Sonar. Such toolset, when available will provide the agility needed to deliver frequently, take these away and the team is likely to suffer.

To summaries, in its origins of XP, Agile practices focused on getting engineering practices right, and although evolving engineering tools made the approaches popular, mass adoption means that it is easy for teams to assume that success is guaranteed just by getting the softer aspects of the process right, but without the automating repetitive tasks in the process, teams can’t be Agile.