At Daysha DevOps we work with Companies who are looking to establish new ways of working. This BLOG reflects something we observed at a client organisations where the change was treating SDLC processes and tools agile style.
History repeats itself
Too often, teams exhausted by the prospect of trying to unravel an earlier generations processes and frustrated by tools that are sucking productivity out of day to day work, engineers will frequently want to just get rid – and start again.
New tools, new processes and start all over again; the only difference being the length of time it takes to get back to square one. Sound like a waterfall?
If you are working in agile fashion and peer organisations are successfully using the same tools as you are then – its fair to assume its not the tools and its time to look at your tools mindset.
Tools are First Class Citzens
SDLC processes are encoded in the tools we use to build and operate code and infrastructure. Dev and Ops engineers bring a large amount of value to these SDLC workflows not least because they created them in the first place.
In an agile world with easy to use tools the system could be continuously updated, but we must first start to think of our own tools as first class citizens not an afterthought when we have some downtime.
The real world is rarely that simple.
In large corporations SDLC systems evolve over time and people come and go. Encoded processes are a good means by which to capture tacit knowledge, but frequently the reasoning behind implementation details are lost. For example why teams decided to adopt test driven development and its consequent effect on the sequencing of tasks, as the unit test is written in advance of the code. Did we keep the workflow updated so we can now measure progress accounting for the change, or do we report that its taking longer to write the code? Empowered teams can make these decisions but the tools need to keep pace.
Everyone involved in implementing SDLC work flows optimise the process at that moment in time but as change occurs, optimisation of the tools is surrendered to time and more pressing issues like the code we are shipping.
It’s the cobbler’s sons and daughter wearing the worst shoes. We build software for our customers in an agile fashion but make do with poor tools with which to do so.
Engineer productivity matters
High performing DevOps teams will capture these small changes during retrospectives (scrum master take note) and add them to the backlog.
A change to Jira or Confluence or whatever tools are your preference, is simply another piece of work to be completed and it carries it’s weight when backlog grooming is progressed with the product owner. And do stand your ground with the product owner. He should be as concerned with dev productivity as the features he needs. Remember we are a team.
The logic underpinning the change can also be readily captured in Confluence, and we are now documenting our workflow tools much as we would customer software. When a new person starts we have a document to share rather than having to allocate a resource to nurse the neophyte through the first few days.
Daysha DevOps offers a support service to improve SDLC process and their codification in Jira. Our Atlassian support services include upgrades and a voice on the end of the phone to supplement the online support community.