Unification across the software development lifecycle

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.


About craigpearson004

"Enabling Continuous Delivery" - Creative Agile Partners (http://www.CreativeAgile.co.uk) provides support to organisations transforming their way of working and looking to be "world class" in everything they do....
This entry was posted in Uncategorized and tagged , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s