Engineering operations and SCRUM

So, now you have decided to take the plunge and start working with SCRUM. That's great...BUT, it isn't enough to get to you cross the finish line. There are some key engineering processes, in my mind, having lived through the horror stories of not having these in place, that need to compliment the SCRUM process which teams may or may not be aware of which are listed below.  In my experience, implementing these would get you on the right track to success.

Note: The list items below are not exhaustive (comments are welcome :-) ) but in my experience having proven this out in the field, its a solid start.


Key Practice #1:  Implement a proper Source code management system
Not having the right tool in place spells disaster for the team and for quality which in many organizations isn't such a negotiable quantity. I know this sounds trivial and its assumed most of the time.  There are many tools out in the market such as subversion(svn), CVS, Git, clearcase(which has a very high overhead), perforce(uses change sets, an interesting concept). Pick a tool that meets engineering goals of branching so you can have branching capabilities to run current and future releases. If you have a distributed team, pick a tool that supports that easily.


Key Practice #2: Implement Design and Breakdown into manageable parts
Letting the team go off and start coding in parallel is a recipe for potential disaster and will impact your project. Implement the ability to create simple designs so that the teams can understand dependencies up front, be able to have a conceptual, high level approach to coding the feature set. I think there are key areas that should be looked at first like the data model or Domain Object Model( DOM) and together with re-factoring (Key Practice # 4), be able to make changes along the way. The KEY here is to get agreement within the team on the broad concepts. This allows everyone to speak in the same terms.

Key Practice #3: Continuous Integration and Builds
The pre-requisite here is Key Practice #1 since Continuous Integration(CI) assumes a good SCM behind it for check-ins and versioning. I have personally used Cruise Control(with ANT,MAVEN)  and Hudson and there are other tools available. I cannot stress how important this is, since the CI system will also run Unit test suites which help with regression testing and help push quality up the chain and early in the cycle.
I have seen in previous projects where the Quality Assurance teams have saved up to 30% time on cycles as a result of implementing this. This also means the engineering team needs to stay committed to building and checking in Unit tests frequently.

Key Practice #4: Re-factoring
One cannot expect to know all the design and coding issues up front since we are not implementing waterfall and even in waterfall, you cannot possibly anticipate all the issues up front.  I think that re-factoring must be embraced as standard practice in order to get the quality you need for a winning product. Re-factoring basically means that the functional behavior of the module is the same yet, the code behind it has changed. It has changed because we want to close the technical gap, assumptions,error handling or other aspects , which if not done, create a quality problem. The added benefit is that engineers will get a better sense of how things work as the project moves forward and sometimes assumptions made early are invalid may impact the project. This allows  engineers to re-look at code and reduce the impact of change for later modification.  Let me clarify what I mean, which is, that if refactoring is ignored, then one can have technical limitations within the code which later on, makes it much more time consuming to change since additions feature/function has been added.

Key Practice #5: Automation/Automated Testing Suite
You have implemented a CI system already, having reached this point, so why not implement the the ability to run Unit tests, BIT (Build Integration) tests, or "Smoke" tests in order to ensure builds get to a stability point early. The point of reaching the best quality, is to push Quality Assurance(QA) up the chain to all levels. I have seen from working on product releases, that one saves a great deal of time within the QA organization from having to run functional tests when there is automation in place. You find that with time, your regression test suites mature, more tests are added, freeing up QA to focus on finding the hard bugs.  Ask any QA engineer and they will tell you that functional testing takes a long time so anything that can be done to help your team mates is a good thing.


In addition to the 5 practices I mention above, the final one, which is not to be ignored, but I assume it to hold true is that there needs to be Ownership and Accountability in the team. If there is an problem and we need to resolve it, its important to implement a culture of collective ownership of the code. I was in a situation where there was one key engineer owning key areas and it created a bottleneck for progress, so make sure you build a redundancy model where more that one person knows the particular code line to be able fix issues.  This is less of an engineering operation issue, but more a Team issue and a culture within the team which should be instilled early on.


I strongly recommend you implement these techniques and spend time on each of them so that you are able to get the best results in the end. If there are more details you wish to know, please let me know.