Ground Zero: Starting Agile Development from Scratch

Carl MiKoy

One of the most challenging things about introducing Agile in the workplace is that it’s not very widespread. People have heard mixed reviews about it’s implementations, and are hesitant to exchange the known (no matter how bad it may be), for the unknown. More and more companies, however, are adopting Scrum for their project management. The “scrum flu” usually starts in one department, and, if implemented successfully, begins spreading throughout the rest of the company. Nevertheless, kicking off any form of Agile Development for a team with no prior experience in Scrum, Kanban or even XP, has to be done with thoughtful deliberation since a poorly managed migration can quickly result in disillusionment.

Here are a few technical steps which have to be made before you change project management styles.

Local development environment

As the internet becomes more and more pervasive, doing software development without a network connection becomes increasingly difficult. Especially, if your application architecture includes several servers with different databases and connecting web-services. Minimally you have to get the core system up and running. Mock out the application interface layers using simple configuration flags. You can use a env=dev with a corresponding if/else block in the code that will bypass the external system lookup.

The local environment is your first quality gate to avoid “breaking the build”. Getting all those tests running on your local machine is not only a great feeling, but real proof that you control the application architecture (and not the other way around).

Source Code Control

The source code is the foundation of any software development project and everybody uses some kind of source code repository. Whether git, svn, perforce or cvs, a successful agile team agrees upon coding standards:

• line breaks
• character encoding
• tabs or spaces

and establishes commit/update rules:

• all tests pass locally before commit (build breakers will be publicly humiliated)
• small commits
• commit only after merging
• complicated, new features on a separate branch

More complicated feature or product packages should be developed on a separate branch. But, don’t forget to do at least a daily merge with the main development line! You’ll thank me when it’s time to release.

Finally, use commit hooks to link source code changes and enhancements to user stories and bugs. Not only is such automatic documentation helpful in the future (“how did I fix that last javascript bug?”), you can use this meta-data to clearly show exactly what fixes and features are running on which systems.

Build & Test systems

Setup a build (integration) system which builds the various branches whenever changes are detected. Only after a successful build, will the test environment be automatically updated to the latest version. Developers should not make it a habit of manually editing files on either the build or test system because it’s important for everyone to know the exact state of each environment.

The QA team can’t reliably test and sign-off features if developers are pushing code willy-nilly to the test environment! If you have your commit hooks in place, it’s easy to create release packages and get the required approvals for live deployments.

Implementing the above suggestions will give your development team a solid foundation on which you can more confidently make the next step – introducing Scrum or Kanban type project management.