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.
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.