Scrumgineering defined

Scrumgineering simply put is:
  "Practicing the craft of Software Engineering in a Scrum team". 

The rabbit hole goes much deeper though when we start talking about how to deliver quality software.  It takes a firm understanding of design principles, solution domain and especially various practices that ensure the delivery of quality software.  These various practices include but are not limited to: Unit Testing/TDD, Continuous Integration and Deployment Automation.


Unit Testing/TDD
In a world where the development iterations are short, QA will most likely find themselves receiving completed stories closer to the end of the sprint.  On the past 2 agile teams I've been a team member of, this has certainly been the case.  Since the collective goal of the team needs to be to carry little or no technical debt over to subsequent sprints, unit testing must be employed by the team's developers to minimize the footprint over which the QA team member(s) must test.  Testing all the non-visual aspects of the source code with unit tests ensures that QA can focus mainly on blackbox testing the features.  In a recent project, we even included a small test harness to allow our developers to execute queries against views and verify they met the global business requirements for queries (threshold on logical reads and on total execution time).  Test Driven Development can be used strategically to drive out a design when the problem domain isn't completely known/clear.  I still recommend a "Sprint Zero" to define high level architecture.

Continuous Integration
Taking advantage of build servers is equally important for 2 reasons.  First, it provides a sterile environment in which to execute the unit tests and helps us avoid the "But it works on my machine" mantra.  Second, it allows us to integrate the various components and run tests that are similar to unit tests but broaden the spectrum to encompass more than one class/component.  This second set of tests helps drive out problems with configuration and especially with deployments.

Deployment Automation
Deployment Automation is just that.  It means that we automate the configuration and installation of our application.  Most applications these days are web-based meaning there is typically no media to be circulated for clients.  Instead, the application is installed and configured on a web server or server farm.  ASP.NET applications make it relatively easy to deploy and in most cases can be done using XCOPY.  The challenge comes when moving from environment to environment (eg., Staging to Production).  Often, configuration differs greatly and managing configuration manually introduces major risk.  Taking advantage of the Continuous Integration servers mentioned earlier, it is relatively easy to set up an application's configuration and target a specific environment.  Most tools like MSBUILD and NANT provide an ample set of tasks that allow configuration settings to be changed on the fly.  Add-on tasks such as SDCTasks add even more functionality to the build engine (for MSBuild that is).

These practices coupled with Agile software development techniques (more to follow on this topic) will greatly improve overall software quality.