Benefits of Standardized Development Environments in Agile Development

the following article is a guest post to zephyr from rodney west , senior consultant and the editorial director at isos technology. isos technology is a partner of zephyr and is the market leader in solving complex enterprise challenges from agile adoption and qa to devops and they help teams improve quality and speed delivery.

i’m about to say something that is going to make a lot of developers angry: standardized development environments are a good thing. i know this flies in the face of many developers. as a developer, the development environment is a deeply personal reflection of your development style and needs in the pursuit of expectations. continuously tweaked and constantly evolving, your development environment (theoretically) enables peak productivity. so, why is standardization good?

one of the most important aspects of agile development is the effective use of time. loss of time is the enemy of agile development. unfortunately, custom environments are often speed bumps (and in the worst case, brick walls) in the agile world. how often have you seen teams lose hours, days, or even entire sprints because of development environment issues? standardized development environments to the rescue!

stay flexible

one benefit of agile development is team composition flexibility. is your team going to need more java developers for a couple of sprints? how about increased ux capacity? no problem (as long as resources with the needed skills are available) … until the time comes to ramp up new resources.

time and time again new resources trip over the hurdle of setting up a suitable development environment. on agile projects, resources need to be productive from day one. an entire sprint can easily be lost setting up a new development environment… not including time commitment from other team resources. a standardized development environment will help you here.

why does it work for everyone but me?

when a development environment goes sideways, sprint time is drained away. depending on issue severity and resource skills, this can range from a minor inconvenience to the loss of sprint productivity for multiple resources.

what happens when a database listener issue crops up in a junior ux resource’s environment? how do you deal with missing binaries or incorrect configuration files? anyone who has spent time helping fix another resource’s local environment issues knows the pain of tracking down issues muddled by environment differences.

if everyone starts from the same point, it is simpler to get to the bottom of the issues. files and directories are easier to locate, configurations can be shared, and logs are easier to analyze. this will save everyone involved time and may just save the sprint.

new toys for everyone

what do you do when it is time to update the development environment? you could just be applying a database patch. maybe you are moving from an apache http server to nginx. regardless of the upgrade, having everyone do their own upgrades to unique environments is time-consuming and potentially error-prone. even with detailed upgrade path notes, there will probably be issues. in the agile world, issues equal lost time.

would you task a ux resource with a database upgrade? no. you would have the database export perform the upgrade. using this approach, the standardized environment can be upgraded and debugged before pushing changes to the rest of the team, saving everyone time and headaches. once a stable has been completed, it can be pushed to the whole team.

the time is now

standardized development environments will buy time and productivity in your agile projects. as an added benefit, keeping a history of development configurations allows testing of older configurations as needed. tools such as virtualbox and docker make it easy to create and update standard development environments.

author rodney west: rodney west is a senior consultant and the editorial director at isos technology . he has over 17 years of experience in software development, software architecture, and technical leadership in a wide range of industries. his approach to software development focuses on the interaction between corporate culture and development processes in the delivery of software.