agile journeys

...rants by Asheesh Mehdiratta on Transformation and Change

Tag: ops pain index

How much time do you allow for Improvements?

This is a common question from many Scrum teams, as they embark on their continuous improvement journey. Multiple teams struggle and then look to the higher powers or just ram through their way. As a Change Agent, to answer this, here is what you can ask them –

Do you allow ‘any’ time currently for Improvements?
  • You would typically hear the team saying as 0% ! and then a good response is to then START Small, with the emphasis on START.
  • You could alternatively talk about doing  10% more than what they are currently doing
  • or simply follow the 1% daily improvement paradigm (aggregation of marginal gains)
  • or you could ask the team about their Pain Index as discussed earlier, and then review from 10-90% of the sprint
So what has been your advice to your teams?

If you like what you read here, then do subscribe to my blog , and feel free to share your feedback in the comments below.

Tip #2: Effective Change management in DevOps

TalkIn order to reduce operational risks, organizations put in CONTROLS, typically via Change Management processes. To minimize the frictions in your DevOps journey, and building on my previous Tip#1, let us look below for the Tip#2 for effective change management.

TIP #2 – create traceability and context for your change set

Operations do not want to be Surprised by any change!!  When you are working in operations every weekend and having multiple late nights, for supporting servers going down or applications crashing, you really want to know what’s the next patch upgrade going to do and how well it will work on the production box. Operation team members are also human and need to have the same LIFE as development team members. ASK your Operations team the OPS PAIN INDEX

OPS PAIN INDEX = #EXTRA HOURS WORKED x  EXTRA NIGHTS

A higher value for this Ops Pain Index will give you a better understanding of the need for Ops to learn more, about every new change being proposed and it’s impact for deployment on existing running stable system. Talk about building TRUST in the development change set!!

Thus, the key is to INCREASE THE TRUST IN YOUR CHANGE SET, by creating traceability and providing context.

With today’s tools and deployment pipelines, it is easy to link your work items in the planning tools (say JIRA, TFS, Rally…etc.). These typically include features/stories/defects – including the Ticket number, version control checkins, comments, release notes. This input can be easily feed into the deployment pipeline tools (Jenkins, Chef, Puppet etc.). This integrated view provides complete traceability across all stages from requirements to the deployment.

The linkage of the work items to the deployment artifacts describes CHANGE SET and provides the CONTEXT for the Operations team.

The additional evidence from a Quality standpoint is typically available from various channels. This includes automated builds results, automated testing results, showing the test cases executed, pass/fail ratio etc. across the various test stages (unit, integration, regression, performance, security tests). All these provide the additional confidence to the operations teams that the development team has really tested the application.

When the development says it works, they really mean it !

Aim to provide evidence of quality test results for the proposed change set, which will provide the required CONFIDENCE for the Operations team.

So go ahead and start providing the traceability and context for your change set to the operations teams and you will be on your way to building some new OPS friends 🙂

Subscribe for more tips in my next post, and feel free to share your feedback here.

© 2018 agile journeys

Theme by Anders NorenUp ↑