agile journeys

...rants by Asheesh Mehdiratta on Coaching, Transformation and Change

Page 3 of 7

Breaking down the Walls, brick by brick !

brick by On your transformation journey, sometimes you meet the bright sparks who simply GET IT, and sometimes you are faced with the hard rock faced bozos, who are simply DEAD! They build a WALL around themselves. They simply have no desire to CHANGE!

What do you feel?

Do you get mixed feelings, mixed emotions ?  Do you ignore this dead stock ? or do you try to turn them around ? 

What if they are a critical piece to the overall transformation? with all the right authority and are riding the right power pedestal? and you simply cannot ignore them.

What is your next step?

For me, sometimes it helps to simply listen to them and give them your ear !

The act of empathizing with the hard rock faces sometimes melts them ~slowly~ one day at a time and then another day and so on.
It helps if you understand what are their Drivers? which may be in conflict with the transformation agenda! Sometimes their ego simply needs a massage.

By listening to them and all the other nay-sayers, you just break down one brick at a time and suddenly one day you find that the wall no longer exists, and they simple GET IT!

Time to move to the next wall to break !

Do you have any stories to share of your hard rock faces, who you were able to turn around? brick by brick ? what was your strategy?

 

If you like what you read, subscribe to my blog , and feel free to share your feedback here

Blockers are sometimes good for your Transformation

Does your transformation suffer from ‘blocker’ souls?

Does your transformation really need those ‘blocker’ souls?

Have you tried to ‘unblock’ those ‘blocker’ souls? and FAILED !

Sometimes it may be better to let the transformation efforts be BLOCKED (for some time at least)

and let the ‘blocker’ souls rejoice ~silently ~

But this can be your ally in most cases, as  the BLOCKED transformation now suddenly gives you the SPACE and Time to re-evaluate your OPTIONS, your EXPERIMENTS.

It gives you the time to think and rethink your change management strategy. 

  • Does your message needs a refresh ?
  • Should your medium be changed ?
  • Are you under estimating your Impact Radius?
  • Is your staff aware of the overall strategy and why this change is coming?

Sometimes the BLOCKERS are useful to take a pause and reset your clock!

So go ahead and let those ‘blocker’ souls not derail you from your journey!

Feel free to share your ‘blocker’ stories in the comment and keep on listening and subscribe to my blog.

ALL Metrics are Useless except what you need !

metrics

For a large number of enterprise shenanigans, Metric creation, collection and measurement can sometimes become a way of life ! They do not really care what the metric destroys, the impact on the human behavior and how these Metrics are simply — USELESS ! The typical story line has been made famous by the myth around –

WHAT YOU MEASURE IS WHAT YOU GET !

(chasing the WYSWIG rainbow made popular from Wintel era)

and then this is supported by, You can Measure ANYTHING, which simply simmers the already hot embers.

But we need to watch for Albert Einstein’s quote – “Not everything that counts can be counted. And not everything that can be counted counts

But the real question to ask is

Do you really need to measure <fill in your favourite metric here>?

Have you ever wondered how the intelligent folks will react when they hear that they are being measured on this metric ?

What will you do as a sane individual ?

Will you ignore this metric if you know someone is tracking and watching this metric? especially if you are caught in the day job cycle, and your promotion depends upon improving this metric?

The answers can range from subservient YES to timid agreement mostly.

But what we are really looking for when thinking of a metric is changing behavior, so that it provides feedback to ignite the FIRE within the individual, within our organization.

So if you are thinking about introducing a new metric, think Twice !! Even if you still insist that you really need this metric, then don’t make THE Metric your GOD, which needs to be fed, but instead make it a Servant for yourself, for your team ! and use the metric as a feedback to improve your condition, your team’s current state and move towards your target state.

Do share your stories on  – What has been your most scary metric?  Which metric you hated ? Which metric made you do the opposite ?

Subscribe to my blog , and feel free to share your feedback here.

Takeaways from the DevOps++ Global Summit Conference

 

It was a pleasure to be invited as a Speaker at the DevOps++ Global Summit, and present my views on the Key Success (and Failure) modes for Large Scale DevOps Transformation, based on the patterns that I have seen across multiple organizations. My session slides can be viewed here.

It was also great to be able to hear other speakers and capture some Key Takeaways below:

  1. DevOps is all about positive economic outcome and benefit to the people, though wrapped up in too much technical tooling jargon by eager vendors.
  2. DevOps is more about the mindset, human aspects relationships and only then about methodologies and frameworks.
  3. Automation should be about automating the right thing, the right way, at the right time.
  4. Micro services architecture enables the DevOps ways of working and complement the Cloud architecture, compared to monolith applications.
  5. Lean principles, especially Value Stream Maps, are a key element in identifying the process debt and wastes, which slow down E2E delivery.
  6. Continuous Deployment/Monitoring workshops wrt. popular tooling using Docker, Prometheus, Ansible etc.
  7. Salesforce stack development and deployments aided with Jenkins, Gitlab, Qualitia.

If you attended this conference, do drop in a link to your notes below in the comments.

Subscribe to my blog for more, and feel free to share your feedback here.

Build technical agility as your Basic ingredient !

Enterprises today struggle with large scale agile adoption and transformation, without looking at the prevalent technical agility, which is a basic ingredient for building the organizational and business agility blocks.

Wishful Dreams

The dreams of Successful Agile Transformation at SCALE, are sold and bought easily today, with  customer success stories , customer quotes and a conference presentation to back it all up. What else do you need? to dream up wishful thinking.

Reality Beckons

But if you dig deeper you realize that even Basic team level agility is a daily struggle for most enterprises. Most enterprises in the agile fluency model are at the 2 or 3 star teams. Rarely the teams go higher and almost all of them struggle!

So go ahead and ask  if your engineering team is leaning toward heaven or hell? As the statistics show that we are losing the engineering practices and the decline of extreme programming is evident now and ‘scrum’ and ‘scaling’ has overtaken as the Main menu item driven by the transformation office.

THE FIX 

Build up your team's technical agility FIRST.

Technical agility is the ability of your team to undertake technical endeavors, using the core tenets of extreme programming and agile modeling, without impacting the business delivery or compromising on the quality of the solution.

This means that you need to take care of your engineers and their engineering practices. You need to ask if the team is writing the best code, are aware and making use of the modern day engineering practices, which a true software professional would, and are they indeed proud when they sleep at night?

Summary

If the Technical agility is missing in your team, your agile transformation would miss the bus and fall flat on it’s back. You would end up as just another data point which supports this graph, and that would not be what you really need.

So cheer up and let the technical practices bloom first in your transformation, and then the honey bees will surely follow.

Subscribe to my blog for more, and feel free to share your feedback here.

Watch out for Fly-by Coaching

When your Agile coach simply throws the ‘jargon’ that you do not understand ??? and then pretends that this ‘jargon’ is way above you “mortal” souls, you are entering the world of “Fly-by coaching”

The coach can run this routine once or twice or even thrice if lucky, but the team members can quickly figure out the reality (thanks to google!) and will pick up that the coach is simply faking his stuff and is not really strutting his stuff.

When asked for How do you actually show the stuff (as put up in the jargon)? – you will see the coach either disappearing or simply attending to prepare some management reports.

You should realize that indeed that you have a ‘Fly-by’ Coach in your mix, and you can almost predict the disappearing act!

5 Tips to integrate Change management in DevOps

 

TalkIn order to reduce operational risks, organizations put in CONTROLS, typically via Change Management processes, which satisfy audit and compliance requirements. These CONTROLS create friction among the team. To minimize this friction,  let us look at 5 Tips to integrate Change management in your DevOps journey.

TIP #1 – TALK TO YOUR AUDIT/COMPLIANCE TEAM

START a conversation with your Audit/Compliance team members now, and try to understand their needs. These conversations will help your team to empathize and see the world from the ‘audit’/’security’ lens. You can then move forward to provide the ‘solution’ instead of jumping in with precooked notions. Read more here on how to start these conversations and ASK the right questions.

TIP #2 – CREATE TRACEABILITY AND CONTEXT FOR YOUR CHANGE SET

START providing the traceability and context for your change set to the operations teams. The goal for your team should be to provide evidence of quality test results for the proposed change set, which will provide the required CONFIDENCE for the Operations team. Read more here on how to start providing this traceability and have a deeper engagement with your Operations teams.

TIP #3 – RE-CLASSIFY YOUR CHANGE SETS

Start to reclassify your change sets, and build agreements, which allow you to auto-deploy to production. Building “standard” change sets, with pre-defined risk profile (low risk first!), you can move towards building a culture of trust with change and operations teams. Read more here on how to reclassify your change sets and increase transparency across the team.

TIP #4 – — USE TELEMETRY TO SHOW EVIDENCE

Start to build out your telemetry systems. These systems allow capturing error, warnings, events, trigger points, and logging this data to central\distributed stores. Use this evidence to show the CONTROLS required for the audit, change management processes. Read more here on how to build these telemetry systems in your DevOps journey.

TIP #5 – AUTOMATE, AUTOMATE, AND AGAIN AUTOMATE !

Stop doing manual steps in your change management teams, STOP ! Start to automate your workflows –build-automated tests – deployments –reports. Read more here on how to increase the automation across the life cycle and increase transparency across the team

So go ahead, kick start and integrate the change management in your DevOps with these tips. Subscribe to my blog for more, and feel free to share your feedback here.

Tip #5: 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#4, let us look below for the Tip#5 for effective change management.

TIP #5 – Automate, Automate, and AGAIN Automate !

Change management typically includes a CAB (Change Advisory Board) meeting. This CAB meeting reviews the list of change sets, which the operations team filters and can either accept or reject,  to move the change-set into production.

The "Advisory" Board just became the "Gate Keeper", if you noticed!

Large enterprises will work with a traditional mindset. This traditional mindset assumes a Large Batch of changes, which may have been suited in the past for a BIG CAB meeting. But now with smaller change-sets (read as micro services) becoming the norm, imagine going through the rigor of a 2 hour CAB meeting. It will not be a very pleasant experience !!

Therefore we need to re-imagine the CAB meeting and ask the simple but difficult question - WHY DO I NEED A CAB ? 
Purpose of the CAB

Typically the purpose of the CAB meeting is to verify all the artifacts, as below-

  • Have you tested your changes?
  • Have you integrated the security practices?
  • Have you tested the migration, rollback and can provide evidence?
  • Is the change-set linked to the business need and do you have approvals?
  • and the list can go on and on…..
Good news?

But there is good news now !  All these questions can be answered easily by automating your change management workflows. This is now supported by the convergence of the tooling across the application development life cycle and all the evidence required along with the artifacts can be easily built into your automated build and deployment pipelines and integrating with the change management workflows.

Thus the elimination of CAB is done by Automation of our workflows!

These automated workflow makes it possible for the Operations teams to trace the requirements as they become implemented, and improves the ability to see changes, the effects of changes, approvals, and gather the evidence in a self service model using telemetry.

Many teams start with an intermediate manual approval step, till they start to trust the teams, and their change sets. But this manual approval step also goes away, over a period of time depending on the maturity of your teams.

As the teams look to implement pre-approved change strategy, and look for future opportunities to keep on continuously improving and widening this definition, it is a win-win for both sides.

So if you still doing manual reviews in your change management teams, STOP ! Start to automate your workflows, start to automate your build process, start to add automated tests for security into your coding, start to automate your deployments to production, start to add Telemetry and automate the production reports, start to complete the feedback loop, and in the end increase the Transparency across the team.

So go ahead – Automate, Automate and again Automate !

Subscribe to my blog for more learning’s, and feel free to share your feedback here.

Tip #4: 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#3, let us look below for the Tip#4 for effective change management.

TIP #4 – Use TELEMETRY to show evidence

Traditional thinking auditors look for evidence, and will typically ask for screenshots, configuration logs, settings etc. If you manage thousands of servers, this itself is a cumbersome activity, especially if you are launching and shutting down servers in the cloud all day.

Imagine the activities needed to manage the expectations and you would simply need an army to satisfy the audit needs!

But the auditors and compliance personnel cannot read code, and hence need all the help they can get, to satisfy the regulatory bodies. So you can help them with providing evidence using the following options.

 1. Create alternate data sources to present evidence 

Applications which are ‘operationally-aware’, will include telemetry data, including capturing error, warnings, events, trigger points, and logging this data to central\distributed stores. Typical telemetry systems (MS Insights/Kibana (logstash) ELK stack / Splunk etc.) can capture all this information and present in visual dashboards.  These dashboards can be customized, based on the needs of the users, and present the data at multiple levels of detail.

Auditors can slice and dice this data, and ‘self serve’ their audit needs !

2. Use Iterative approach to building CONTROLS evidence

As part of early engagement with the auditors, successful teams invite audit teams to their sprint planning and sprint reviews. This conversation can kick start rich discussions on how to build controls evidence in every sprint, instead of the end stage.

Teams can start to build controls right from the beginning! 

Sometimes the solutions to meeting the audit controls could be as simple as maintaining version control for all the artifacts. Other solutions could be simply linking all the artifacts across the complete application development life cycle. This allows traceability for each change set put in production.

To help you explore further, read up the fictitious narrative DevOps Audit Defense Toolkit. This provides some real life examples and links it all together.

So go ahead and start to build out your telemetry systems. Start doing early engagements with the change teams. Start to build out the controls iteratively, thereby building Trust and Transparency across the team.

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

Tip #3: 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#2, let us look below for the Tip#3 for effective change management.

TIP #3 – re-classify your change sets

Enterprises will have multiple change requests being pushed to production, of varying size, complexity and with different risk profilesBut existing change management processes today do not distinguish between these variations!

In reality, different change sets allow us to build different risk profiles.

So let us try to understand these variations in the Change sets, which can typically be classified into one of these 3 categories –

 1. STANDARD Change sets

These change sets are very low risk, and operations are familiar with these. These change sets have an established approval process in place. Examples – web style changes / data table updates etc.

2. NORMAL Change sets

These change sets are high risk, and operations are not familiar with these. These change sets typically use a CAB (Change Approval Board) process to approve/reject the changes. This process requires submitting change forms, with schedule, impacts, risks etc. Examples -New feature/product etc.

3. HIGH Urgency Change sets

These change sets are emergency changes, with potential high risk, and may need approvals from senior management. Examples -Security patch, Service fix patch etc.

Now with the above classification, we can aim to align with the operations teams and change management and ask for an agreement.
Agreement:  Can the STANDARD Change set be Pre-APPROVED?

As the standard changes sets are low risk => Operations teams do not need to approve. This agreement immediately give us the ability to define a pre- approval process. This allows us to deploy our change sets automatically (using  our automated deployment pipelines).

I am sure that this agreement itself will allow you to breathe more freely !

So go ahead and start working with your change management teams. Start to build these agreements, which allow you to auto-deploy to production, with complete Trust and Transparency across the team.

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

« Older posts Newer posts »

© 2024 agile journeys

Theme by Anders NorénUp ↑