John Wadleigh

I am an artist, a designer, an architect at Red Hat, a professional photographer at J.W. Gallery, a musician, and a world traveler.

An opinionated article that attempts to describe a successful model towards helping a company transform and become a more

Update my kickoff slides… https://docs.google.com/presentation/d/1LAtjoLOpZlt0cfsLBVg_GeGl3G-m1xPiVZGu-BUQ5uU/edit?usp=sharing

TODO: Add information about…

TODO: Note the following… In doing transformation, we have to first understand human behavior and the natural tendencies it has towards comfort, building groups that become silos, losing trust in other groups, work being easier in the group versus outside of the group, and so on. This is why transformation requires not only technology modernization but more importantly requires organization changes that prevent these human behviors from ever re-occuring, are resilient, share the pain, and are … (make sure to mention that companies need to build and ensist on having a Continuous Improvement model)

NOTE: Discuss Center of Excellence (CoE), Community of Practice (CoP), Journey, Transformation, etc. https://gocatalant.com/coe-everything-you-need-to-know-about-centers-of-excellence/

TODO: Note the following topics (perhaps in another blog)

  • Swimlane diagrams and their purpose and when they are valuable
  • Release process diagrams, their purpose, and when they are valuable
    • Using Callouts for showing constraints in the process
    • Using colors to emphasize automated step versus manual step
    • Ensure diagram flows from left to right on a horizontal path; vertical paths show work that is optional or an extension of the current step
    • Keep it high level; create separate diagrams on constraint areas

TODO: Create a release process with standard/typical phases/gates and a list of potential products for each phase (Dev, Testing, etc)

TODO: Leverage some architectural probing questions from BlueShield folder

TODO: Nicole to review TODO: Leverage https://dillinger.io/ to review length, reading time TODO: Understand profit margin https://www.investopedia.com/terms/p/profitmargin.asp

TODO: Understand budget cycles and expenditure cycles

TODO: Add the following common points

  • Tool Consolidation to address “Tool Sprawling” issue, which is part of Addressing Technical Debt
  • Governance Model, RACI, Automation Evangelist, CoP, CoE, Dojo? and overall Operating Model

Why start a transformation program?

  • Company is experiencing varying degrees of financial bourdon. Even with high profits, there is very little return on investments (ROI) that were intended for improvement and growth
  • Competition is evolving and company is experiencing customer loss, customer complaints, etc.
  • Transformation attempts made to date have been unsuccessful or slow moving
  • Systemic problems persist and result in financial loss

When does the transformation program end?

In short, a transformation program attempts to attack and address changes across a larger aspect of a company. The basics of a transformation attempt to address:

  • Changing the people
  • Changing the processes
  • Changing the technologies

To emphasize the scale of change, the word “transformation” is leveraged instead of perhaps a “journey”.

This leads us to answer the question of when it ends. Let’s start by defining what a successful transformation should achieve:

“An organization that has the people, processes and technologies in line with a Continuous Improvement model.”

The goal of transformation is NOT to fix everything but to leave an organization in a state where they have the proper model to take care of current and future problems in a manner in which accepts imperfection/failures but insists on improvement and demonstrates it using transparent mechanisms.

So how does the company know when they have achieved that goal?

NOTES:

  • know the skills of your people (cannot stress this enough)
  • project manager (need this person to drive basic info to break down walls, set expectations, ownership, etc)

Communication Model

  • Slack
  • Threads
  • Workstreams
  • Channels
  • Landing pages
  • Meetings
    • Note taking procedures
    • Recording sessions

Reporting Model

Regardless of anything you might improve or change during the transformation efforts, none of it matters if you do not have a solid reporting model that is simple and yet informs the right stakeholders of the value of those changes or efforts.

The diagram below emphasizes the general reporting model and the roles involved.

<insert diagram, middle management, VPs, workers, consultants, architects, program manager, lead architect, customer success exec, etc>

Consider the following:

  • Impacts to the reporting model
    • Level of Effort - This refers to the level of effort required from those trying to make change, as that can consume too much time and is often a weekly effort.
    • Frequency
    • Complexity - If your reporting model looks more like a value stream mapping then its just too complicated.
    • Layers
  • Who can/should report to stakeholders?
  • Understand “Touch Time vs Wait Time”

Understand how to capture and report facts on initiatives: Example (not good): Example (better): Example (best):

Metrics

(consider mentioning KPIs, KPOs, SRE/SRI/SRO/etc)

Within the transformation effort, you will be faced with the need to define your critical metrics. These are commonly used to show how specific changes has truly improved or impacted the organization. This can be financial numbers (optimally), man hours or FTEs, and so on. The challenge with metrics however is that often with transformation there are many organizational and cultural changes that are needed and these are quite challenging to elaborate using specific metrics.

So what to do?

This goes back to the reporting model and how you intend to express these metrics, changes, improvements to the stakeholders. Specifically when you do not have actual numbers, how are these improvements going to be expressed.

Ultimately in any transformation effort, the metrics you report will make or break the transformation program. Everything costs money and a lot of money is required to make big changes. So the result is that the whole program rests on the ability to express these metrics to the stakeholders appropriately to continue the investment for transformation. You can have rock stars on your team delivering fantastic things, but if you cannot express the metrics or cannot convince the stakeholders of the value then the whole program falls apart. This should not come as a surprise to anyone, but in my experience it’s the one piece that is not getting enough focus.

Changing the People

One of the most important areas of change that need to occur within the company is with the Recruiting, Marketing, Interview methods, Definition of roles/resp, and so on.

Skillsets

Basic skillsets are required from the customer looking to transform their organization and technologies. These may not be required for each individual but have an importance in driving change.

  • Gap Analysis
  • Current State Assessment
  • Future State Proposals
  • Collaboration
  • Diagramming

Changing the Processes

Changing the Technologies

Too many technology solutions doing similar things. Expensive solutions that are not used enough Multiple in-house customized solutions creating technical debt and often solving the same problem for different teams

Workstreams

Strategy for each work stream

  • TODO: (put somewhere else) Establish onboarding instructions for Architect/Consultants/etc, which includes setting up development environment, important links to systems, etc.

  • Includes leader from customer who believes in transformation and helps ignite and connect with other teams and employees.
  • Establish Landing Page for workstream (leverage Confluence, Sharepoint, etc)
  • Establish vision statement (talk about activity to establish vision and how to perform it.. add to open practice library?)
    • Schedule at least 1 hour meeting with the stakeholders, generally 2 hours is best just in case conversations happen
    • Use collaborative board (white board, virtual software board - miro, mural, https://ideaboardz.com/, etc)
    • Step 0, moderator prepares board with 1 column titled “Words”, and another column titled “Parking Lot”
    • Step 0, everyone navigates to the prepared board
    • Step X, moderator sets the amount of time for each of the following
      • Step 1, each person creates cards for words that matter them
      • Step 2, merging/grouping similar cards (careful not to merge if person does not agree)
      • Step 3, each person votes on cards
    • Step 4, sort the cards by votes (if possible)
    • Step 5, ask everyone to collaboratively leverge the top voted cards/words and attempt to formulate a vision/mission statement; leverage words that are not voted on if necessary; drag the cards into a sentence structure and add other “bridge” words to create a grammatically correct statement… for example, “reliable”, “stable”, “environment” could be the words and the sentence can be “Build a stable and reliable environment”
    • Step 5, agree on the final vision statement

  • Place the vision statement at the top of the Landing Page (see above) for the team, and have this become the start of your Center of Excellence

  • Establish Kanban or Scrum/Sprints; using MS Teams was easy but JIRA more powerful and more complex

  • Establish planning poker for estimating user stories OPINION: This is great in the beginning, but can be extremely frustrating for the team. The main point of this exercise is to expose differences in the understanding of work that is being done within a sprint. Additionally to expose the complexity of a piece of work in order to attempt to break it down to smaller pieces. OPINION: All teams not in Development, will struggle to enforce work to be completed within the defined sprint as other operational and emergency work always takes priority and consumes the available time. (What to do here??) https://planningpokeronline.com/

  • Establish DOD and DOR https://openpracticelibrary.com/practice/definition-of-done/ https://openpracticelibrary.com/practice/definition-of-ready/

      Summary: “As a [persona], I [want to], [so that].”
  Description:
  As a <insert> I/we want <insert> so that <insert>

  ASSUMPTIONS:
  <insert>

  DEPENDENCIES:
  <insert>

  CURRENT STATE:
  <insert>

  ACCEPTANCE CRITERIA:
  <insert bullet list of future state outcomes and metrics required to sign off for a demo>
  • Example of Definition of Done
    • You have demo’ed the outcome
    • You have updated our documentation
    • Code is committed, reviewed, merged and tested using CI pipeline
  • Leverage SPIKEs for short user stories https://www.scaledagileframework.com/spikes/
  • How to handle operational tasks?

  • How to create an epic, user story or card? Metrics driven

  • For each epic, form a “strike team” channel and weekly meeting cadence; this allows asynch conversations to occur and provides tranparency to those interested and involved, instead of having 1:1 chats that act as the “hallway conversations” that tend to lead to decisions that nobody knew about
    • Must include 1 director that commits to 1) observing, 2) handling escalations, and ultimately understand how soething took 3 months to complete
    • Must include each member required/involved in the process

Sprint Goals

The initial goals of a transformation effort is to:

  • Immediately engage into a release train for a specific value stream (workstream)
  • Determine the MVP that can be brought through the release to production (some might call this Minimum Viable Prod, short for Production, to emphasize the success criteria being the destination) https://www.ycombinator.com/library/4Q-a-minimum-viable-product-is-not-a-product-it-s-a-process https://www.agilealliance.org/glossary/mvp/
  • Kickoff sprint to accomplish above
  • Do NOT over achieve, rather focus on the minimum on the first sprint
  • Establish the goal of the sprint (containerize, replace app, change UI, etc) and drive user stories based on that goal

Meetings and Agile/Scrum Ceremonies

  • Adapt the new philosophy of “whoever can join the meeting are the right people for the meeting” instead of requiring everyone to be available and moving meetings all the time. You can always get something done even if you don’t have everyone. Another term used is a “meeting quorum”.
  • Be concious of two things, 1) number of scheduled meetings, and 2) which day you typically schedule meetings. Keeping 1 or 2 days where you never book meetings, unless there is an exception, allows team members the ability to focus and be productive that day. Often companies are victims too many meetings, and people attending meetings that are not necessary to the success of the meeting outcome. Consider declaring a “meeting bankrupcy” and remove all meetings from calendar to reset.
  • Start a chat thread for each meeting within Google Chat or Slack
  • Take notes on who, why, attendance, etc
  • Notes not needed for standup
  • Share notes with customer AND Red Hat team to highlight and emphasize facts gathered and transparency
  • Always focus on outcome vs output
  • Ownership of working model must eventually transfer to customer
  • Understand general constraints and leverage these as initial epics
  • Try to create small tangible user stories

Agile/Scrum Ceremonies

  • Daily Standup
    • What was worked on
    • What’s the plan today
    • Impediments / blockers
    • Only 15 to 20 minute call
    • Do not invite people that are not part of the sprint
  • Demo
    • What was completed during the current sprint
    • Does not have to be presentation quality, just share
  • Retrospective
    • Establish software solution (Leverage https://ideaboardz.com)
    • Establish columns to capture information
      • Keep doing
      • Start doing
      • Stop doing
    • Establish plan for meeting
      • Time for creating cards
      • Time for merging/grouping cards
      • Time for voting on cards
      • Time to discuss top voted cards
      • Capturing action items
    • Performed every X sprints
  • Backlog Refinement
    • Prepare for meeting by having Product Owner establish priority of Epics
    • User Stories within priority Epics will be reviewed during refinement session
    • Sizing will be done during the session using Poker
  • Sprint Planning

Workstream - Release Management

  • Release Managers vs Release Engineers
  • Environment Landlords
  • Everyone is responsible for the success of the release!
  • Release diagram
    • Determine what is Manual vs Automated
    • Intake process?
      • PI Planning?
  • Standardized process/steps within the release, regardless of release type; for example, developing, testing, perf testing, production release, code merges, etc.
  • One system to track ALL releases/projects/etc
    • Provide current status
    • Provide progress, blockers, etc
    • Eliminate 4 different ways to report status to leadership
    • Most common problem that unnecessarily consumes time/resources

Testing

  • Understand each type of testing and map existing tools
    • Smoke tests, Regression testing, Functional testing, Unit testing, Integration testing
    • Create CD diagram of each test phase/gates
    • Production “Validation” actually falls under what type of industry standard test category? smoke tests? integration? or functional?
  • Google Testing Blog: How Google Tests Software https://testing.googleblog.com/2011/02/how-google-tests-software-brief.html

Kanban

  • Establish meeting cadence (standups)
  • Establish kanban board (JIRA, MS Teams, Trello, etc)
  • Define kanban card template
  • Definition of done

Social Contracts

I have not seen these work so far, so cannot recommend them. However…

https://medium.com/swlh/agile-ways-of-working-social-contracts-ab6b8c93429f

Open Organization

https://www.redhat.com/en/explore/the-open-organization-book

Jim Whitehurst is the CEO of Red Hat, the largest open source software company in the world. When Jim joined the company, he became enamored with how open source was disrupting the world of traditional proprietary software. In his time here, he has become more than just a believer in the power of open source software. Now, he’s an outspoken advocate for opening up nonproprietary data and technology of all kinds.

The Open Organization takes the transformative effects of openness from the community, through the technology, and into the organization at the deepest and highest levels. Jim believes openness must be pervasive to be effective.

Before joining Red Hat, Jim held various positions at Delta Air Lines, most recently as chief operating officer. Prior to joining Delta, Whitehurst served as a partner at The Boston Consulting Group (BCG).

A3 Lean Management / ODIM / Definition of Ready / Etc

  • Developing skills to create User Stories, Cards, etc that provide enough information to allow others to understand, estimate and believe the work is valuable.

Value Stream Mapping

Value Stream Mapping

  • https://openpracticelibrary.com/practice/vsm-and-mbpm/
  • https://www.atlassian.com/continuous-delivery/principles/value-stream-mapping
  • https://www.youtube.com/watch?v=C3LbbgRYBws
  • https://openpracticelibrary.com/practice/vsm-and-mbpm/
  • https://www.atlassian.com/continuous-delivery/principles/value-stream-mapping

Diagrams

Some diagrams help, some provide no value whatsoever. Some diagram systems help and some are darn right frustrating. You might love or hate systems like Miro/Mural but they do enable collaboration when you have a mixed team.

  • Swimlane Diagrams

Wardley Mapping

BSC Program: Pragmatic Wardley Mapping Training Here are the details for this Wardley Mapping training. Sign-up here: https://learn.hiredthought.com/p/wardley-mapping#value choose the $59 corporate rate Use 25% coupon code: REDHAT Expense to the project in Concur. Project code: 51089 Expense code: 998.0

Architecture Workshops

Architecture Strategy Probing Questions https://docs.google.com/document/d/1u8cAufQf8KuI8icq0HrnLmjzM1Lr57VeVCgjWQK5bXU/edit?usp=sharing

Site Reliability Engineering

Google SRE Book https://sre.google/sre-book/service-level-objectives/

Pragmatic SRE https://docs.google.com/presentation/d/1yQcoZtq584HCHkK_Yr0WP2mwj0h03W0tSpPbwUgv2jo/edit#slide=id.gec154cd768_0_9877 How our Red Hat managed services team practices SRE (for ROSA, OSD, etc. Start on slide 11): https://docs.google.com/presentation/d/17EfxxUPmgRt_tv1kh0agsaXEC602N6XoPprfsiJXEWU/edit#slide=id.gf5a6b81e2f_0_0 And a recorded session from the lead to go with the presentation above: https://drive.google.com/file/d/1d-eVZy5dhcoK1Z9htrSbSD9ZLQ76sWVd/view Red Hat’s definition of SRE https://www.redhat.com/en/topics/devops/what-is-sre

Containerization using OpenShift

Automation using Ansible

https://access.redhat.com/documentation/en-us/red_hat_ansible_automation_platform/2.1

Database Management - Data Masking and Subsetting

  • Oracle DMS (Data Masking and Subsetting) Masking Sensitive Data / Overview of Oracle Data Masking https://docs.oracle.com/cd/E11882_01/server.112/e41481/tdm_data_masking.htm#RATUG4003
  • Tonic https://www.tonic.ai/features/overview

References

Learning from Incidents in Software https://www.learningfromincidents.io/

Non Functional Requirements https://nfr.blueshieldca.com/

Continuous Integration vs Continuous Delivery vs Continuous Deployment https://www.redhat.com/en/topics/devops/what-is-continuous-delivery

DevSecOps https://www.redhat.com/en/topics/devops/what-is-devsecops

CAPEX ==> OPEX https://www.investopedia.com/ask/answers/112814/whats-difference-between-capital-expenditures-capex-and-operational-expenditures-opex.asp

Rolling budgeting

Security Solutions Explained - SOAR vs SIEM https://swimlane.com/blog/siem-soar

  • security information and event management (SIEM)
  • security orchestration, automation and response (SOAR)

Open Source Projects on GitHub with Red Hat

IT Automation Tools Are No Longer Enough

Starting Your Cultural Transformation with DevOps

  • Matt Takane
  • John Walter

Why Is Implementing Change So Hard?

Enabling digital transformation via the Red Hat management portfolio

All Things Open CONSCIOUSLY UNCOUPLING FROM YOUR CLOUD PROVIDER WITH ANSIBLE

Steve Jobs’ Reaction to MobileMe Launch, Life at Apple After Jobs, and Other Anecdotes

You May Also Enjoy

DevOps 101 - Vagrant

Learn the basics of Vagrant, a powerful DevOps tool used for managing virtual machines