Author: suhaw

https://techbeacon.com/gene-kims-7-secrets-devops-success

1. Change often begins in operations: “For early adopters, it’s operations leading the charge, followed by architecture,” Kim says. “These folks have the full end-to-end view of the value steam and can see the problems that need to be solved.”

2. DevOps transformations start small—but not too small: The sweet spot is where DevOps is introduced to solve a very specific business problem with clear, anticipated benefits, like shorter lead times or increased reliability. That is why DevOps initiatives are often driven by second-line managers, such as a director of operations in a business unit.

3. Business-savvy technologists take the lead: The leaders most likely to recognize the “just right” opportunity to introduce DevOps are engineering or IT professionals who are close enough to the business to appreciate its biggest challenges intimately, but with a clear understanding of the technology in play.

4. DevOps change agents take risks: “All of these DevOps leaders are given some degree of air cover, but they go beyond that to the point that it puts them in some personal jeopardy,” Kim says. Why risk their careers? “They have a level of certainty that the capabilities they are creating for the organization are needed—not just to win in the marketplace, but to survive.”

5. DevOps demands a culture of trust: When it comes to successful DevOps transformation, culture is key. In fact, it’s one of the top three predictors of DevOps performance, according to five years of analysis done for the annual State of DevOps report, whose cosponsors include Kim’s IT Revolution and HPE. Power- or rule-oriented cultures are not well suited to the type of collaboration and information sharing that DevOps requires.

6. DevOps expansion requires leaders to evolve: When solving problems at the business-unit level, these tech professionals have a high degree of control over the transformation. As they get promoted, they have less overt control and must learn how to lead through influence. “That’s much more challenging,” he says.

7. CIOs are key enablers of DevOps: While not all IT executives will be directly involved in the introduction of DevOps in their organizations, CIOs play a key role in removing obstacles and setting up DevOps teams for success.

https://www.oreilly.com/ideas/an-efficient-approach-to-continuous-documentation

Excerpts:

• Start with nothing more than a single blank text file.
• Each of these notes could be captured in seconds, at the moment the thought came up. More detail can always be added later, but that’s strictly optional. Whatever you do, make it so that your daily journaling is easy enough that you stick with it, even if it means writing only a tiny bit each day.
• After a few weeks, review your notes and look for recurring themes.
• Create a new document for each of the themes you’ve identified, and then spend a few moments summarizing the more interesting parts of your journal related to that theme.
• Your summarized notes will start to become more structured, because you’ll be intentionally looking for common threads during each review. Once that happens, it’s a sign that you’re ready to start building out a formal knowledge base.

Before speaking truth to power can be considered virtuous, the act must meet several criteria:

• It must be truthful.
• It must do no harm to innocents.
• It must not be self-interested (the benefits must go to others, or to the organisation).
• It must be the product of moral reflection.
• It must come from a messenger who is willing to pay the price.
• It must have at least a chance of bringing about positive change (there is no virtue in tilting at windmills).
• It must not be done out of spite or anger.

This list is neither complete nor all-inclusive, and meeting each criterion requires considerable ethical analysis.

— Warren Bennis, Daniel Goleman, James O’Toole with Patricia Ward Biederman, “Transparency: How Leaders Create a Culture of Candor”, Page 56

What I bring to the OPI table:

• Understanding of and hands-on experience with SMC/IS staff, processes and systems
• Competence with the English language and ability to handle documentation, where necessary
• Coupled with an appreciation that documentation is an important, but ultimately only a small contributor to the successful implementation of any initiative/project

 

Aspirations:

• Work closely with SMC/IS staff to be more effective, efficient and resilient by making better use of systems and tools (technological and otherwise, corporeal and cerebral) at our disposal
• Apply the theoretical concepts learnt at Lean 6 Sigma and NTU Knowledge Management courses, as well as the many books I have read on related subjects.

 

Background:

• In my early years of working, namely 1996 to 2000, I was part of a small team that provided the bridge between Editorial and Technology colleagues to bring SPH’s English language newspapers into the Internet medium.

12 December 2016 addendum:

In SGX today, our approaches toward system improvements/enhancements can be viewed through 2 lenses.

In the first approach, we meticulously draw up all our manual processes. Then we try to find a system that replicates every step, down to the last detail. This is often very costly and back-breaking due to the massive amount of customisations required.  And sometimes projects are abandoned because they were found to be prohibitively costly (resources, time, etc).

The other approach is to take a product off the shelf and have Ops staff make up for whatever deficiencies in the product. Oftentimes, we wonder why we pay so much for a defective product that seems so inadequate, i.e. why we even bother to change in the first place.

The first approach is far too onerous on our Tech colleagues while the second shifts the same burden to Ops. In both cases, Ops and Tech seem to operate independently of each other.

I’d like to propose a third way that calls for Ops and Tech to work together. Instead of requiring a new system to do everything the existing system already does and more, we should evaluate what we really need and want of any system. Furthermore, we should also seek to understand (and take advantage of) what the new system has to offer and open our minds to the possibility to paradigm shifts that make old assumptions obsolete.

It would, imho, be so much more productive if Ops and Tech were to understand and appreciate each other’s perspectives better and jointly work out solutions.  I think that is what Agile seeks to achieve.

 

This morning, Jarod and Lum came over to Vista to give our Issuer Services (“IS”) Team a heads-up on his re-organisation plans to merge the IS and Securities Market Control (“SMC”) teams.

I can personally see a number of positives to this merger plan:

• With more staff, it would alleviate the difficulty rostering sufficient staff at both operational sites.
• Although it will mean that the staff needs to be trained/knowledgeable in “each other’s” systems, it may also mean less chance or boredom and maybe also less possibility of “taking things for granted”.
• The added responsibilities and tasks might provide the necessary push towards simplifying processes, perhaps out of necessity.

An interesting reaction/feedback was how we (SGX, particularly Operations) have been toggling between Functional and Customer alignments:

• Pre-SGX: Customers – Securities and Derivatives markets were respectively by SES and Simex
• Under Tim Kloet and Fu Hua – Market Control handled both Securities and Derivatives markets
• Magnus Bocker re-aligned to customer segment groups and Market Control focused on Trading and Clearing members while Depository attended to the needs of Issuers, Depository Agents and Retail
• Jarod Ong re-aligns along Functional lines with this merger

I personally feel that everytime we toggle, we learn to see things differently and learn different methods and techniques. Such that if/when we get toggled back to an earlier framework, we can apply these new stuff.