What DevOps Means to Me

Magnus HedemarkDevOps Instigator

magnus@yonderway.comhttp://www.linkedin.com/in/hedemarkhttp://opusmagnus.wordpress.com/

@Magnus919 on Twitter

Who am I?

● I'm not Gene Kim.● Usually Systems Engineer,

sometimes a people manager, always a geek.

● Transitioning from an Engineering Manager role at Amplify Education to Principal Systems Engineer role at Red Hat (Aug 2013)

● Stirring the DevOps pot wherever I go.

Who are you?

DevOps Snowflakes

● DevOps means different things to different people.

● Sometimes it even means different things to the same person.

● This is work in progress, it's new, and we're still figuring it out.

● Wikipedia has a very well-tended page on DevOps.

What does it mean to me? Today?

● “DevOps is not about a technology; DevOps is about a business problem” – Damon Edwards

● The software industry is still rather nascent, and doesn't operate effectively yet. DevOps seeks to address this problem, mostly through cultural, process, and organizational changes.

● Sometimes technology is leveraged to succeed at these other more important things.

CAMS (John Willis)

● Culture● Automation● Measurement● Sharing

Culture

“People and process first. If you don’t have culture, all automation attempts will be fruitless.”

Automation

“This is one of the places you start once you understand your culture. At this point, the tools can start to stitch together an automation fabric for Devops. Tools for release management, provisioning, configuration management, systems integration, monitoring and control, and orchestration become important pieces in building a Devops fabric.”

Measurement

“If you can’t measure, you can’t improve. A successful Devops implementation will measure everything it can as often as it can… performance metrics, process metrics, and even people metrics.”

Sharing

“Sharing is the loopback in the CAMS cycle. Creating a culture where people share ideas and problems is critical.”

Eli Goldratt

● Israeli physicist, business process guru

● Theory of Constraints

● Author of “The Goal”

Theory of Constraints (The Goal)

● Identify the system's constraint(s) (that which prevents the organization from obtaining more of the goal in a unit of time)

● Decide how to exploit the system's constraint(s) (how to get the most out of the constraint)

● Subordinate everything else to the above decision (align the whole system or organization to support the decision made above)

● Elevate the system's constraint(s) (make other major changes needed to increase the constraint's capacity)

● Warning! If in the previous steps a constraint has been broken, go back to step 1, but do not allow inertia to cause a system's constraint.

William Edwards Deming

● American statistician● Major influencer in rise of

Japan as an industrial powerhouse

● Plan-Do-Check-Act

Deming Cycle

Taiichi Ohno

● Japanese businessman

● Father of Toyota Production System (TPS)

● Just In Time (JIT)● Lean Manufacturing

Toyota Production System (TPS)

● Design out overburden and inconsistency● Eliminate waste● Deliver the required results smoothly● Process is as flexible as necessary without

stress or overburden● Overburden generates waste● Tactical improvements of waste reduction or

the elimination of waste are very valuable

Seven Kinds of Waste

● Waste of over production (largest waste)● Waste of time on hand (waiting)● Waste of transportation● Waste of processing itself● Waste of stock at hand● Waste of movement● Waste of making defective products

Continuous Improvement

● Challenge (We form a long-term vision, meeting challenges with courage and creativity to realize our dreams.)

● Kaizen (We improve our business operations continuously, always driving for innovation and evolution.)

● Genchi Genbutsu (Go to the source to find the facts to make correct decisions.)

Respect for People

● Respect (We respect others, make every effort to understand each other, take responsibility and do our best to build mutual trust.)

● Teamwork (We stimulate personal and professional growth, share the opportunities of development and maximize individual and team performance.)

Long-Term Philosophy

● Base your management decisions on a long-term philosophy, even at the expense of short-term financial goals.

The right process will produce the right results

● Create continuous process flow to bring problems to the surface.

● Use the "pull" system to avoid overproduction.

● Level out the workload (heijunka). (Work like the tortoise, not the hare.)

● Build a culture of stopping to fix problems, to get quality right from the first.

● Standardized tasks are the foundation for continuous improvement and employee empowerment.

● Use visual control so no problems are hidden.

● Use only reliable, thoroughly tested technology that serves your people and processes.

Add value to the organization by developing your people and partners

● Grow leaders who thoroughly understand the work, live the philosophy, and teach it to others.

● Develop exceptional people and teams who follow your company's philosophy.

● Respect your extended network of partners and suppliers by challenging them and helping them improve.

Continuously solving root problems drives organizational learning

● Go and see for yourself to thoroughly understand the situation (leave your desk!)

● Make decisions slowly by consensus, thoroughly considering all options; implement decisions rapidly

● Become a learning organization through relentless reflection and continuous improvement (Kaizen)

Gene Kim – The Three Ways

● Systems Thinking

● Amplify Feedback Loops

● Culture of Continual Experimentation and Learning

First WaySystems Thinking

● emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department

● never pass a known defect to downstream work centers

● never allow local optimization to create global degradation

● always seek to increase flow

● always seeking to achieve profound understanding of the system (Deming)

Second WayAmplify Feedback Loops

● create the right to left feedback loops

● shorten and amplify feedback loops

● necessary corrections can be continually made

● understand and respond to all customers, internal and external

● embedding knowledge where we need it

Third WayCulture of Continual Experimentation and Learning

● continual experimentation

● taking risks and learning from failure

● understand that repetition and practice is the prerequisite to mastery

● allocate time for the improvement of daily work

● create rituals that reward the team for taking risks

● introduce faults into the system to increase resilience

Agile Manifesto

We value: Over:

Individuals and interactions

processes and tools

Working software comprehensive documentation

Customer collaboration contract negotiation

Responding to change following a plan

Agile Principals (1-6)

● Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

● Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

● Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

● Business people and developers must work together daily throughout the project.

● Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

● The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Agile Principals (7-12)

● Working software is the primary measure of progress.

● Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

● Continuous attention to technical excellence and good design enhances agility.

● Simplicity--the art of maximizing the amount of work not done--is essential.

● The best architectures, requirements, and designs emerge from self-organizing teams.

● At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Paths to Agile

Scrum● Full-Time ScrumMaster Identified and Team Members Available to Do Work

● Team Agrees to Demonstrate Working Software in No More Than 30 Days

● Stakeholders Invited to Demonstration

● Full-Time Product Owner (with Expertise and Authority) Identified

● Product Owner Works With Team and All Other Stakeholders

● Product Backlog Created and Managed by Product Owner

● Daily Scrum Meeting with 3 Questions (Completed? Will Complete? Obstacles?)

● Daily Scrum Meeting Same Place and Time and Less Than 15 Minutes

● Regular Sprint Length (no more than 30 days)

● Sprint Planning Meeting to Create Sprint Backlog of Estimated Tasks

● Sprint Burndown Chart

● Team Room with All Needed Equipment and Supplies

● Retrospective Meeting for Process Improvements

● Definition of Done

● Commitment Velocity Calculated (from Sprint Backlog Estimates)

● Team Size 7 +/-2, Maximum of 12

● Cross-Functional Team Including ScrumMaster and Product Owner

● Team Self-Organization – Team Members Volunteer for Tasks

● ScrumMaster Tracking and Removing Obstacles

● - Team Safety – No Interruptions to Team’s Work During Sprints

● - No “Breakâ€� Between Sprints

● - Sustainable Pace – Timebox Effort, Not Just Schedule

● - Quality is Not Negotiable – Defects Go on Top of Product Backlog

●

● Optional Rules of Scrum to Implement Depending on Context:

● - Test Driven Work and Continuous Integration

● - User Stories as Product Backlog Items (As a I can so that )

● - Project Burndown Chart

● - Release Burndown Chart

● - Planning Velocity Calculated (from Product Backlog Estimates)

● - Scrum of Scrums for Multiple Teams

● - Canceling the Sprint Early

● - Financial Modeling for Product Backlog

● - Sprint Backlog Tasks on Big Visible Chart on Wall

● - Backup Product Owner Identified

● - Team of Volunteers – Self-Selecting

● - Rotate the ScrumMaster Duties

Kanban● Visualize your

workflow● Limit your work in

progress

Kanban

Kanban – Six Core Practices

● Visualise ● Limit WIP (Work In Progress)● Manage flow ● Make policies explicit● Implement feedback loops● Improve collaboratively, evolve

experimentally