Coming from a business analysis background I’ve always encouraged full requirements traceability – each individual requirement should be traceable all the way back to the requesting stakeholder (mainly customers, but sometimes a customer proxy). Whilst this does require a bit of admin time – minutes for meetings where requirements are discussed, for example – the downstream benefit makes this totally worthwhile.
As someone who has also deployed software services (SaaS) based on captured customer requirements I’ve emphasized the obvious need to engage resources at the other end of the development cycle – the operations engineers and admins who will deploy and support the running service.
Whilst, conceptually, most organizations place these two stakeholders at opposite ends of the development spectrum, there is a need to bring unity within a development context. In simple terms this may mean having Ops people engaged in the Agile/SCRUM process (sprint planning, stand up’s, etc.) This means functional requirements which manifest themselves in live services are discussed, reviewed, estimated and delivered by the Ops team at the soonest opportunity. Likewise any dedicated operational requirements (availability, infrastructure, monitoring, etc.) will be raised and included in the requirements gathering process (with full traceability of course).
Whilst most of this may seem common sense its amazing how even the larger organizations allow the silo/division mentality to pervade, and it usually takes difficult and prickly conversations by the Project Manager to fully engage and direct the unified team.
The product (or service) owner is also now fully integrated into the development process courtesy of the latest Agile/SCRUM thinking so already there is that arbitrator of requirements. The service owner also now therefore takes on the mantle of standing up for ops type requirements (the “accidental admin”) as well as core requirements.
This cross-proliferation of skills and experience does then manifest itself in other ways to – Ops teams are adopting more source code control principles by maintaining environments scripts in a source control system (a recent Puppet Labs report indicated that 89% of respondents use source control for infrastructure management). Chef/Puppet scripts allow the process of environment realization to be coded and subject to the usual software development rigors of the build/deploy/test cycle. Deployment to live (e.g. in a cloud IaaS provider) is no longer the potential gamble it once felt if the script that is being used to deploy an environment to live has already been tested in the cloud provider’s sandbox environment.
ThoughtWorks have also produced an informative e-book on this subject – partnering across the enterprise. The principle of unified, delivery focused teams that transcend organizational boundaries, is rapidly becoming the norm.
craigpearson004 on Musings on the latest Thought… Tarang on Musings on the latest Thought…