#Code of #DevOps #Practice: #comments

Following recommendations from many reviewers and contributions, the Code’s Values, Pillars and Principles are provided here.

Values

Flexibility and quality over velocity and temporal inconsistency

Companies expect the DevOps Team to provide business flexible products of high quality from the first release. They may be of minimum business values, i.e. offer minimal compositions of features and functions to the product consumers, but what is provided has to work reliably and consistently in the real-world context. Moreover, business flexibility, i.e. readiness to adopt ‘tomorrow’ changes with minimal cost and time, is the modern factor of market competitive advantage and has to be preserved always. No compromises of quality of products attributed to the velocity of development are acceptable by the product consumers.

Specialism and risk-based management over inexpert opinion

Solutions promoted and realised by DevOps Teams should be based on deep professional knowledge and experience of experts and on accurately identified, estimated and mitigated risks. Work with risks is always a collective work of business and technology because many risks are inter-dependent crossing the operational and software boundaries. No “democratic” voting on risk topics is acceptable by corporate management.

The pragmatism of the team culture over the cult culture

A DevOps team can inherit its operational culture from Agile methodology or create its own – it is up to the Team, but this culture has to be pragmatic. If any procedures, rituals or processes appear as not effective enough or lead to extra activities justified only by someone’s else experience or by books, they should not be kept like in a cult and either adjusted/optimised or even removed from the Team’s practice by the Team. Team behaviour and organisation should be adaptive to the changes in its context of operations.

Corporate ownership of the products and the team’s responsibility for the products over isolation and superiority

All outcomes and products created by DevOps Team is a property, including intellectual property, of the company that has employed the members of the DevOps Team. The latter is just a form of organisation and operation in a particular area of Technology. Since the company has tasks of large scope, one DevOps Team cannot be assigned to all of such tasks without creating a development bottleneck and large technology debt log. While different DevOps Teams can have their preferable areas of expertise, coordination of work across Teams belongs to the company. It can create another DevOps Team for the task of coordination or hire specialists for this work. A company cannot accept a practice where if a DevOps Team cannot handle an entire task, it denies recognising and working on such task as a part of a bigger team.


Pillars

Business Value of the outcome

The business value of the DevOps work should be defined outside of the Team or proposed by the Team and approved outside of the Team. A Team cannot be the requestor and the provider of its work when being paid for the work by its Employer. If the Team needs to conduct some work for organising its own development process, improving its efficiency or quality and velocity of its delivery, this work has to be reviewed by the company management and justified regarding business values – immediate or perspective. The Business Value of the DevOps outcome is the major pillar of the Team’s work.

Quality of Product 

Quality of products created by the DevOps Team is one of the most valuable factors of competitive advantage of companies in many industries and markets. Even if only a part of the future product is released, it should meet quality criteria. Corporate management defines quality criteria while consumer base validates both criteria and products. The major driver of quality criteria is product suitability for the internal and external market. A perfectly-developed product may mismatch the corporate strategy, the company’s obligations to partners, the security situation in the market or compliance with the market’s regulations in a certain location.  Quality of DevOps products may be managed and controlled by many different means, not all of which can be easily automated and support speedy delivery – this is the internal business of each individual company. The Business Quality of Products produced by the DevOps is the second pillar of the Team’s work.

Business Flexibility of the outcome

Business Flexibility is the next value of DevOps practice. Business Flexibility is not a qualitative opinion-based category; it has a clear quantitative expression where the software development is expressed via business characteristics such a cost and time-to-market. Proper development organisation, smart design and automation can significantly increase such flexibility. In essence, maximum flexibility of the solution for a business task comprises a combination of the minimum cost of the task (which can be a change) implementation, minimum time-to-market (including the time of product delivery), and minimum cost of changing this implementation for the new task/change. It is a balance of mentioned above ‘minimums’ because a reduction of one them can lead to an increase of another. This Pillar defines the objective criterion of “minimum valuable solution” for the product-candidate to the market release.  For example, a business task or a request for a change in the existing product can be implemented to the last ‘letter’ and all that is not explicitly specified is eliminated as a waste (Lean practice). Such approach makes sense if two conditions are met: 1) the implemented product is supposed to work for a relatively long time before the next change would be requested, and 2) if the implementation team has absolutely certain specification for the to-be implemented product, which can appear only after relatively long design work (including all reasonable alternatives, their risks, available resources, etc.). Modern software market meets none of these conditions, i.e. a hook for ‘tomorrow’ change, which the specification does not articulate but the developer can suggest making the future work easier(e.g. insert a point of indirection in the code instead of direct coupling of logical fragments or modules) is not waste anymore. So, if a task/change is implemented like ‘written in stone’ with minimal cost and tested for only ‘sunny day’ mentioned in the requirement/User-Stories, i.e. time-to-market is minimised, the change of this implementation may become very expensive and even more costly than full re-development. As a result, the cost of this part may be very high and overall flexibility may become much lower than is a bit more then minimum cost and time were consumed, but significantly reduced the cost of their change. The Business Flexibility of the DevOps outcome is the third Pillar of the Team’s work and one of the major factors of competitive advantage of the company in the market.

Professionalism of Team-Members

In the context of DevOps, a professional person is not only the one who can perform work associated with a particular profession. It is a person who possesses special education and training that prepare members of the profession with the particular knowledge and skills necessary to perform their specific role within that profession.  Professionals are subject to strict codes of conduct, enshrining rigorous ethical and moral obligations. In the Code of DevOps Practice, the term is used as shorthand to describe a particular professional stratum of well-educated and highly experienced people have considerable authority in the matters related to their professional area and whose suggestions are not simple personal opinions, but the expertise in given profession. For example, if a DevOps Team contains 3 programmers, 1 designer and 1 QA professional, and the latter is disagree with programmers on which tests to be run on certain modules/products, the Team is expected to follow the QA requirements. This assures company management that the Team delivers professional solutions to different problems always. The professionalism of DevOps is the foundational Pillar of the Team’s work success.

Continuous innovations

Innovations, in contrast to inventions, are contextual and implementation-specific methods, effects or products. So, they are not necessarily only new things, but the things new in the given context. Adoption of DevOps practice can be an innovation for one company while it is a routine for another. Therefore, in the context of the company, the developed/proposed by a DevOps Team should, first of all, aim to increase business values for the company. In technology, innovation is often viewed as the application of better solutions that meet new requirements/User-Stories or needs. Since innovative work is financed by the company, the innovations would be well articulated and justifiable. Creating or applying new tools or methods for the development on the basis that many others do so is a weak justification. From practice and analysis, innovation is generally a result of actions, including code execution, that brings together various novel ideas in such a way that generate either a new business value for the company (and via company – for the industry) or a new, more efficient way of producing existing values. This Pillar depicts the creativity and advances in the work of the DevOps Team. 


Principles  (see post)

  1. Code development, security and compliance have equal realisation priority
    • At the time of global digitalisation cross-country regulations enabling international trading, the concerns of security and compliance have the same importance in priority during design and programming phases as coding itself. For instance, internationally accepted GDPR regulation requires “data protection by design and by default”, i.e. personal data should be encrypted in the storage. When a developer writes code to fetch such data, the code must consider encryption/decryption by default. If security means and regulation compliance are omitted, this may be acceptable for functional Prove of Concept (POC). However, if the POC is about operational aspects, this can result in the misleading outcome because, for example, scalability combined with encryption usually demonstrates different performance. Value of the code with no security and/or compliance is next to zero.
  2. The velocity of product delivery may not reduce the quality of the development outcome in any way.
    • Business and market consumers are entitled to have quality products from the first attempt, The Team should do its best to provide a high quality of the outcome. No development team may define the ‘minimum viable quality’ for a particular product; this is the prerogative of the Marketing and Sales Teams of the company. Velocity should be the natural result of the development and operations automation preserving product quality, security and compliance. Business and market consumers are entitled to have quality products from the first attempt, The Team should do its best to provide a high quality of the outcome. No development team may define the ‘minimum viable quality’ for a particular product; this is the prerogative of the Market and company’s Sales Teams. Security and compliance testing may be performed only by specialists outside of the Team to avoid conflict of interests.
  3. A DevOps person may not be creator, judge, executor and validator of his/her work
    • Design of the product, the judgement of the design suitability for the business task, code development or implementation, product/code executor and result validations are different concerns from the development perspectives and, as such, have systemic reasons for segregation. Otherwise, any accumulation of them for one person constitutes a high risk of conflict of interests. The DevOps Team controls building robust reliable code using the methodology of its choice in the line of the general principle of separation of concern(though unification the best practices across the company is recommended). Automation of these tasks has to exclude the ability of the same person to tune tools for personal convenience – only in this case, automation may be considered compliant with this principle.
  4. Definition of ‘done’ should include full testing, documentation, security and compliance validation
    • In order for a company to market its products to consumers, the company should be confident in that: 1) the product has successfully passed the challenge of real-world ‘sunny’ and ‘rainy’ situations depicted via testing, 2) the company owns the product and the product can be supported in the absence of its developers via appropriate documentation, 3) the product is secured to the level that minimised losses in the security cases, 4) the product is compliant and regulatory fines and court cases are not the risks to the company. An absence of any one of the mentioned four elements in the definition of “done” is equal to “not-done”  
  5. Working software is the one that meets the definition of work is “done”
    • Working code is only a phase in the development. It is not the result and not a criterion of complete work. Working code has its final value only as a POC, not as a product. Apparently, DevOps method may be adopted at different maturity level, i.e. not all operational processing of the code into a product may be performed within the Team. In this case, it is recommended to clearly reflect this situation in the name or category of such Team, For instance, it can be named DevOpsAdopting Team. For management, this will indicate that not covered operation should be realised by other dedicated teams.
  6. The value of the team-work outcome is validated by the consumer, not by the Team
    • In certain types of the company organisations, the team management can be the consumer of the teamwork outcome in addition to it is the owner of the product. The DevOps Team is in right to decide whether the product is ready for deployment, but the act of deployment should be regulated by the company’s policy. The maturity of operation automation has a significant impact on this policy. An ability of an individual member of the DevOps Team to deploy the product into the market does not mean that this is the right of the developer yet.
  7. Decisions about all aspects of product development may be made only in the business and technology context of the product use
    • Business and technology contexts comprise business laws-regulations-rules-policies-customs-ownership of the jurisdiction where the product runs and the technology platforms-infrastructure-bandwidth-programming-licensing-contracts-security of the environment where the product executes respectively. Priorities and preferences dictated by contexts can be not only contradictive but also different in different contexts. Effective technical decisions can appear limited or prohibited in a particular business context. This especially relates to the decision about implementation of business functionality, i.e. in Microservices. Due to remote access to distributed elements of the products, the notion of contexts becomes crucial not only for marketing the DevOps products but also for development of the products. For example, the products should be able to automatically recognise the location of their consumers and act correspondingly. The code of Web and Mobile application or services has to provide a great deal of automatic adaptability, i.e. the actual product outcomes depend on the execution context
  8. Specialist’s opinion may not be suppressed by common opinion in the Team
    • A specialist is the core resource of the DevOps Team. Cooperative work of specialists where each one is responsible for the assigned work is more efficient and effective than just a team-work of inexperts. All Team-members share the same development objectives while particular specialists possess professional knowledge and experience that other specialists do not have. The core of the specialist experience is an ability to judge on the basis of “what if?”. Mitigation of related risks is a special professional skill. Therefore, no simple voting contradicting the specialist opinions may be permitted: the majority of opinions does not mean it is right. All individual opinions should be meticulously documented, especially if they yield to another opinion. The best resolution of opinion mismatch is a balanced compromise based on strong arguments (while “speedy delivery” may be taken as an argument only in combination with documentation, testing, security and compliance).
  9. Design and planning of the DevOps work depend on the task’s subject and complexity, available resources and business or consumer demand, not only on the opinion of the Team
    • Design and planning of implementation for different business tasks depend on many factors that may be (usually are) situating outside of the Team’s realm and competence. If such factors are not in the comfort zone of the Team, they have to be reviewed up-front and the decision about the suitability of the Team to the task is made before the work starts. The Product Owner together with the architect or designer are responsible for the work outcomes to adhere to those factors.
  10. All outcomes produced by the DevOps Team and dedicated to the consumers – internal and external – should be documented to the level where the outcomes can be supported, modified and maintained in absence of the product developers
    • Some DevOps Teams claim that writing documentation slows down their delivery. Definitely – any additional work slows delivery; the question is only what is delivered – a code or a product? From a company perspective, it is a code regardless of how developers name it. If the DevOps Team officially takes maintenance function of its products on itself, it does not only slow down the delivery but appears counter-productive since over the time developers will spend a significant part of their time (and it will be growing) on the maintenance instead of development. At the same time, generation of documentation can be automated, i.e. take minimum time, if it is embedded in the code in the form of comments (a well-known practice). The requirements to such comments are: they have to be objective and to answer two questions – what the code does and why it does it, what for. Also, the code-fragment dedicated to communication with external modules, applications, API, services/Microservices should outline this specific – ‘for interaction’ or’ for integration’. In this case, the comments should contain the SLA-information for particular interaction end-point, i.e. what developers are ready to provide and guarantee. If the products are capable to work with “smart contracts”, related code should be commented in a way that clearly points to the contract conditions and contract execution features.
  11. Cultural environment and Team’s internal culture should link with each other via honesty and transparency at the individual and Team levels
    • A high-performance  culture is generative and psychologically safe. This integrates continuous improvement with continuous learning. That culture needs to include both technical and non-technical competencies and practices so that the Team’s behaviour becomes reflective (and responsive) to the policies and changes in the company the Team operates within. Opposing DevOps culture to the corporate culture is fruitless and should be replaced by reasonable mutual compromises.
  12. The quality of products for an internal user may not be lower than the quality for an external user
    • An ideal quality of software products has to be as such that any internal product could compete with the analogous external one. Otherwise, the DevOps teams will be at risk and steadily replaced by outsourced development. In a highly dynamic market, business feasibility of buy versus build changes frequently leading to frequent changes of preferences. Competency and competitiveness of the DevOps outcomes is the factor than can stabilised position of the DevOps team in the company.
  13. User Stories, as well as Non-Functional Requirements (NFR) to be taken by the DevOps Team for implementation, are subjects for specialist reviews outside of the Team
    • The User-Stories and NFR are the development assets owned by the company and planned for the corporate Target Operating Model. The company works in several contexts and software development is one among others. So, the company is in full right to selecting its business and technology directions/strategies and distributing its funding accordingly. Transparency of the Team’s tasks is a must-have for successful company management. Also, the company drives the adoption of certain security practice and compliance means. These have to be propagated to the DevOps Teams with the expectations of factual feedback from the Team.
  14. Everyone in the DevOps Team is responsible to the Team for the individual contribution; the Team, not only the Product Owner, is accountable to consumers and corporate management for its outcomes
    • Individual contribution is based on the Employment Contract and validated via individual performance of the employee. Participation in the DevOps practice does not change the Employment Contract automatically. The corporate management is still responsible for the individual performance of each DevOps-member, i.e. individual work should be transparent to the management. Cultural and operational segregation of the DevOps Team from the rest of the company leads to the conditional acceptance of the Team in the company and to poor outcomes.

Recommendations

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly”. Agile Manifesto.

Leave a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: