cross post from labs.sogeti.com
Teams need to move fast, every action which results in wait time must be minimized to zero. Teams need to move flexible, context changes must be easy adoptable by the team and the system they realize.
Two very clear, but hard to accomplish aims. One challenges teams face today in reaching these goals are the availability of environments.
Development environments are hard to setup with mostly big hardware requirements. For example setting up a SharePoint 2013 development machine requires a lot of knowledge and time on an very powerful machine.
This will probably slow down the onboarding of a new team member. Requesting the proper hardware, read the book J install, configure and setup the environment.
The same for the environments that are used by testers. Every developer needs his own machine to develop on the solution, also testers need environments to plan, specify and execute tests. This means not only developers environments need to be available also for the tester a separate environment to execute their tests on needs to be available.
For just a normal development team it will work like explained in this video and diagram:
It gets interesting when the team runs sprints of one week and deliver every week a new increment. An increment which needs to be installed on a clean environment. With for this example a clean SharePoint environment, ready for validation. And, let’s say the team releases every four sprints a release for validation by customers an environment, which has the same characteristics as the production environment must be available.
Asking the supporting operations department first every week a new integration and test server and every month a clean ‘production like’ environment will make them crazy. Probably operational rules will even make this an not supported scenario and slows down the team in delivering value.
Two activities; onboarding of team members (Development), and the availability of environments (Test and Acceptance) are slowing down the team. Not only the complexity, but primarily the company dependencies (approval) which come with these activities bring teams value delivery to a full stop.
Dev and Test Platforms as a Service.
Virtualization is getting mainstream, even IaaS (Infrastructure as a Service) is wildly adopted, teams are using them, the benefit can get higher. Ready-to-use platforms easy to spin up for team members. Microsoft already delivers a Platform (Azure VM Template) preinstalled with Visual Studio 2013. http://www.windowsazure.com/en-us/solutions/dev-test/ (see screenshot)
Not only the pre-installed and configured VM’s from Microsoft can be used for this scenario, also the community started to make VM’s http://www.hanselman.com/blog/Over400VirtualMachineImagesOfOpenSourceSoftwareStacksInTheVMDepotAzureGallery.aspx
The other dependencies.
The tools are there, team members are powered with the capabilities they need to have. Now we get to the biggest problem, company policy and restrictions. Who is going to pay the bill?
Probably a complete sign off mechanism starts when a team needs something. A request for a new laptop is formalized in a full workflow with signatures on multiple documents, only getting approved with a proper business case it will probably take a few weeks, two when its fast but when someone is on vacation six till eight weeks. This same request – approval process is used for cloud possibilities. Cloud possibilities which are needed to move teams fast and flexible. This is definitely counterproductive and this dependency need to be solved fast.
Give the power to create environments in the hands of the people who need them. Then teams are ready to get along with the current development (and test) practices to move fast, flexible and deliver business value add a cadence the business needs.