DevOps Culture, People, and Tools

6.1 Behavior-Driven Development (BDD)

6.1.1 When BDD Fits and How It Works

Behavior-driven development (BDD) is a way of building software by first writing down the behavior an end user will experience, in the form of concrete scenarios, and then checking the production code against those scenarios. It fits a specific kind of situation: when the customer is not clear about the technology, is not clear about the functionality, and cannot say exactly what they expect from you — while at the same time, the IT team is also new to the complexity of such a project, totally new towards the characteristics of the project. In that case, the sensible move is to implement or develop exactly what your customer is asking for, instead of assuming.

Why does BDD shine exactly there? Because a vague request cannot be coded directly, but it can be observed. Nobody can tell you "build me an app", but anyone can tell you what they expect to see on the screen when they open it. BDD captures that observable behavior instead of the unspoken expectation.

When both sides are this unclear, the user stories are defined in user personas — descriptions of what exactly the users are expecting out of this product. A persona (a written profile of a typical user, with their goals and habits) turns "someone will use this" into "a busy traveler on a phone will want to sign up in under a minute". That concreteness is what makes a persona testable.

BDD works especially well for web-developer-based projects, because you can sit down and think about what exactly a customer will look forward to when they go and log in to a particular site. That concrete, experience-based thinking is what turns a vague request into testable behavior.

Visually, a BDD flow is a screen-by-screen chain: app home → create-account button → social sign-up buttons → chosen provider's permission screen → new account created. Each arrow in that chain is one scenario; the chain as a whole is the sign-up journey of a real user.

6.1.2 Worked Example: Mobile App Sign-Up with Social Memberships

Here is a worked example that shows how BDD works in practice.

User story: For a mobile app, we want to allow an end user to sign up using any membership they already have — a Google membership, a Facebook membership, an Instagram membership, or something like that. The user story is: allow them to sign up using any other account.

BDD approach: the method follows by finding out the scenarios.

6.1.3 The Scenarios Become the User Acceptance Test

The key idea is that BDD works with customer-centric scenarios, but the behavior belongs to the end user — the person who will actually use your application or product. The earlier term "customer" was corrected mid-explanation: it was not right; the correct term is "end user". The scenarios describe how an end user behaves, and that same description doubles as the acceptance test the development team checks against.

A user acceptance test (a test that checks whether the software actually does what its user needs it to do) is normally written as a separate phase at the end of a project. BDD collapses that phase into the start: the scenarios written before coding are the acceptance test, so there is never a surprise at the end — the code either matches the scenarios or it gets refactored.

Real-world and domain connection: the BDD sign-up flow above is exactly what today's mobile apps ship. The "sign up with Facebook", "continue with Google", "log in with Instagram", "sign in with Twitter", and "sign in with Gmail" buttons on real apps implement precisely this scenario chain — tap the button, land on a permission screen, grant access, and the account is created. In industry, BDD is typically written in tools like Cucumber and SpecFlow, where Given–When–Then scenarios are stored as plain-text feature files that double as both documentation and automated acceptance tests.

6.1.4 Student Questions and Answers

6.2 Scrum Essentials

6.2.1 The Three Scrum Roles

Scrum is the Agile method that is vastly accepted by all the industry — people use Scrum widely when it comes to Agile — and it has basically three roles. Understanding these three roles first makes everything else in Scrum (the sprints, the meetings, the backlogs) click into place.

The details of Scrum will be covered in depth in the Agile software processes course; this session gives only a brief idea, because Scrum is the method most widely accepted by industry. One practical way to see the roles and the rhythm in action is the YouTube video of the first bank in the world that adopted Agile Scrum, which was shared in class for a layman's perspective on the whole flow.

6.2.2 The Scrum Workflow from Backlog to Retrospective

The flow of Scrum runs as a loop that repeats for every sprint. Each cycle takes a chunk of the product backlog, turns it into working software in a fixed-length sprint, gets feedback, and feeds what was learned back into the next cycle.

The seven steps of the loop, with the rationale for each:

The practical cost of the workflow is the meeting time itself: a daily scrum plus planning, review, and retrospective takes hours out of every sprint. That cost stays small when the sprint is the size of a couple of weeks and the team is small; it grows when the team is large — the daily scrum itself creeps from 10–15 minutes towards 30–40 minutes for teams of six to eight members, especially working from home — and the meeting overhead starts to eat the delivery time it was meant to protect.

6.2.3 Sprint Goals and Sprint Misconceptions

A few rules of Scrum came up repeatedly in this session and are worth fixing, because they are exactly the points where industry practice and the Scrum method differ — and the Scrum method is the exam's answer.

Three more clarifications from the session:

• DevOps teams can work in sprints. A DevOps team doing CI/CD, following best process, and including ops can still work with the sprint method — the sprint is a planning rhythm, and CI/CD is the delivery machinery under it; they are not in conflict.
• Every sprint should have a design phase. The roadmap exercise gives a high-level design; each sprint then refines it incrementally and iteratively, because design, like development, is an ongoing process. You start with something broad, and every sprint's increments are folded back into the design and architecture.
• The product owner is not part of the daily scrum. The daily scrum is for the development team; the scrum master is only initially needed to help the team follow the process, and then not needed either.
• Refactoring sprints exist but should be combined with delivery. Technical debt may justify a refactoring-heavy sprint, but generally a sprint should combine refactoring with a small workable product.

6.2.4 Student Questions and Answers

6.3 The DevOps Mindset

6.3.1 The Quiz Question: Which Mindset Drives DevOps

Exam note: a quiz question asked "DevOps is based on which mindset?" Most students answered people, services, and process — and that is the incorrect answer. The correct framing is that in DevOps we have people, process, and tools. The question was raised because students were in confusion, and the correction matters: process is definitely needed, but the DevOps mindset is not a process mindset.

Why DevOps culture at all? Business was already achievable through waterfall. Why did we shift to agile? To grab more business — to be more perfect at delivering your solution and getting the business from other customers. Ultimately it is a service mindset: you want more business, you want to be more business-centric, you want to give this product early to the market. Being an IT organization, why would you look for a solution where you can push the code early to the market? So that your customers and end users can use your functionality early — and why? To grab more business.

The two candidate answers differ by exactly one word, and that one word changes the whole emphasis:

When the quiz appears again, pick the trio — people, process, and tools — and attach the service mindset on top.

6.3.2 Why Culture, Not Process

The output any organization looks for should be measurable — the vision and mission should be measurable — and the measurable output is grabbing more business. Everybody is there to make the business; if an organization wants to increase its business, it looks for tools, new methods, new processes, new improvements — and the reason is always the same: to grab it. So the mindset should be a service mindset.

Culture is the operative word. You need a process, you need tools, and you need people who will run those processes and automate those processes using a tool. The tool alone does not create the mindset; the people operating the process with the tools do. Tied to this, DevOps also wants effective people management, because organizations do not want attrition in their workforce — that theme is the core of section 6.5, and it is not a side concern: a culture built on people falls apart the moment the people leave.

Real-world and domain connection: this is why real DevOps adoptions start with the team, not with the toolchain — industry surveys and the DevOps literature repeatedly report that buying a tool does not change a culture, and that hiring a "DevOps engineer" without changing how people work is a common way to fail. The service mindset also explains the DevOps goal of reducing time to market (as the reference text frames it: shorten the time between committing a change and placing it into normal production, at high quality) — every practice in the rest of this course traces back to that one measurable output: business.

6.3.3 Student Questions and Answers

6.4 Transforming an Enterprise to a DevOps Culture

6.4.1 Where the Transformation Steps Come From

Whenever you want to adopt something, there should be steps that are followed; with engineering steps, you can travel down and achieve the particular goal. Software development has software engineering, whose engineering steps help design and develop a product. Similarly, for the DevOps culture there are certain steps that the industry follows — but they are not hard-coded steps. They have not been given by some institute or some authority center of DevOps. These are the steps identified by most of the industries that have adopted the DevOps culture, drawn from their experience of how they opted for it and how they went ahead.

Many surveys were conducted, every organization responded to the same survey questions, and out of those surveys a design document was prepared to broadly identify what was common across most organizations that converted themselves into a DevOps culture. That is what this session presents. Because these are not stone-written steps, there can be changes and improvements to the steps ongoing, as reports keep coming in from other industries and organizations that have recently adopted the DevOps culture.

6.4.2 What an Organization Gains from DevOps Culture

Before looking at the phases, it helps to see what an industry gains after adopting this culture. The DevOps culture is a movement based on human and technical interaction, and this movement exists to improve the relationship and see the improvement in the outcomes — your results to your industry or enterprise.

Four gains stand out:

1. Broader automation. With the DevOps culture you definitely get broader automation. Repetitive work — builds, tests, deployments, environment setup — moves from human hands to automated pipelines, so the same team ships more with fewer manual slips.
2. Transparency. Because automation exists, everything is transparent — you have audit logs, and every aspect of your software development lifecycle or of your project is transparent, and that gives you an effective measurement. When every step leaves a trace, a manager can measure, and a team can prove what it did.
3. Sharing, no silos. This culture is purely based on sharing; you will not have silos in your enterprise. Multiple hands in your industry or enterprise share their experience to get an effective product. Knowledge moves sideways between teams instead of being locked inside one tower.
4. Lean process. Since you are adding the agile process, you definitely remove the waste from your value stream map with the help of lean management. Every step that adds no value to the user — waiting, rework, handoffs — is identified and trimmed.

Visually, picture the before-and-after: before, the organization is a row of boxes — development, testing, operations — each with a wall, each handing work over the wall and losing information at every handoff. After, the same organization is a shared pipeline: one flow from idea to production, with automation, logs, and shared knowledge moving along it. The gains above are the measurable side of that picture: automation is the machinery, transparency is the light that lets you see inside, sharing is the flow between people, and lean removes the dead weight.

This is what an industry should expect out of DevOps. The phases below are the ones an industry can look for when transforming.

6.4.3 Phase 1: Initial Planning for Enterprise Readiness

This first phase checks how much the enterprise is ready to opt for the DevOps culture. The participants should come from absolutely every tower — not all participants, but there should be people from each and every tower of the industry. Those participants then run a design thinking session, which is the greatest method here: you brainstorm, use the expertise of stakeholders, discuss with them, and enable a common understanding.

Design thinking (a structured, user-centered way of exploring a problem before solving it) is the engine of this phase: instead of jumping to solutions, the participants put the enterprise itself under the microscope — what does each tower need, fear, and expect from the change? Because every tower sends representatives, no department discovers the plan from the outside.

From this design thinking brainstorming session, the high-level output is generated: with this phase you just create a design of what the initial planning should be for a particular enterprise to go and opt for the DevOps culture. The output is deliberately high-level — a readiness picture and an initial plan — not a detailed implementation blueprint.

6.4.4 Phase 2: Establish a DevOps Center of Excellence

At the right organizational level and enterprise authority, the enterprise needs to identify a face — create a face that is laid by an enterprise leader, someone from a higher hierarchy who has the support or buy-in from all the towers or all the departments of the industry or enterprise. The active participants from all towers of delivery must be chosen wisely; which people and members are picked from each department should be decided wisely.

This phase also helps concretize the vision and strategy of the organization, and helps set up the best practices to support the cultural movement — what best practices the organization should opt for to support this movement. In short: find out the authority, create the face — a person with buy-in from all departments — and involve everyone in running the show. This group becomes the DevOps center of excellence.

Why does the face have to come from the higher hierarchy? Because culture change needs authority to be taken seriously: a transformation championed only by mid-level enthusiasts stalls the moment it needs a budget, a policy, or a headcount decision. The center of excellence is that authority made visible — a standing group, not a one-time task force.

6.4.5 Phase 3: Establish Program Governance

Here, Agile and DevOps practitioners will definitely change the roles and responsibility, which means there will be a change in the organizational structure. Awareness, enablement, and empowerment are needed, and this phase delivers them: people must first know the change is coming (awareness), then be given the skills and mandate to act (enablement and empowerment) — otherwise the new roles exist only on paper.

6.4.6 Phase 4: Establish the Project Intake Process

For this phase, you opt for DevOps subject matter expertise, and those subject matter experts conduct a workshop for your organization's Scrum teams. Why Scrum teams? Because DevOps and Agile run hand in hand, so the first prerequisite is that the team should follow Agile.

The best practice is to bring the subject matter expert from outside the organization. Why? If your own organization's senior or higher authority people drive the workshop, members start feeling there could be some huge change in the organization — there would be layoffs, or "since I'm not in a good book with my manager, probably it will impact on my position." Such questions arise in the mindset, and suddenly the organization ends up with attrition — the attrition percentage increases. If the workshop is conducted by an industry expert from outside, the tendency of grabbing the concept is different, because now everyone feels this is for everyone; no person would be targeted out of it, because it is something designed for a better business organization. That is the reason people opt for an outside member to drive such workshops.

The workshop covers: how to automate scripts, the infrastructure assets you are going to use, how you will do configuration as a code, test automation, branching, merging, and lesson learned. Fit-for-purpose tools are also selected in this phase. The phase gives the output as right sizing — what kind of tools and technology the team should opt for in terms of adopting DevOps. The organization also looks for reusable assets: what tools and technology they already have, whether they can reuse them, and what best practices can be added, right sizing the tools and technology that should be used.

Right sizing means choosing just enough tools and technology — not the biggest or the newest. Reusing what the organization already owns first, then adding only what the gaps demand, keeps the transformation affordable and the tool landscape manageable.

6.4.7 Phase 5: Identify and Initiate the Pilots

DevOps is not very easy to adopt. It is not a one-month or two-month journey; it is a long-term journey to opt for a DevOps culture. If it is a big elephant, it is really difficult. Think of Tata Motors or any other industry that has existed for decades, grown up over the past 20 or 30 years: for a big elephant to learn dance is really difficult, so you have to opt for slow and steady steps to adopt this culture.

If your organization is really huge, you cannot do all the towers or all the departments at once. In this phase you identify and initiate the pilots: which teams can be considered initial pilots, and they opt for and start using the DevOps culture. The pilot team does a value stream mapping exercise, performs the end-to-end process with the automations, exercises with the toolings, understands which manual processes exist, identifies them and automates them, learns the new skills, and grabs the right people to do so. Then the pilot team executes a project with the DevOps culture.

The outputs of the pilot are then scaled out for the DevOps program: the same team can onboard a parallel release train, apply the intake process, support monitoring and manage, do continuous monitoring, and automate the monitoring tasks as much as the team can. Then you look at the outcome of this team, pick another team, and the second team runs the show the same way the first team did. Then the third and the fourth, and after that other departments — overall, the organization moves towards the DevOps culture.

For a startup company it is really easy to opt for the DevOps culture, because they have really small members, and with few people the communication gaps are less — running this phase is easy with startups.

6.5 DevOps People Management

6.5.1 Why Culture Is Built on People

DevOps is a cultural movement, so it is all about people. When you talk about culture, even though you have good tools and a good best process to adhere to, if your people are not ready there won't be any output out of those. Even no matter you have a standard process and a licensed full-fledged tool, if your people are not prepared to start using it, you will not get an output. Building a culture is the core of DevOps adoption, so this dimension of DevOps holds real value.

Building a culture is not like adopting a process or a tool. To adopt a tool, you hunt for a tool, see the options, choose which version you want, pay for it, and start using it. For a process, you hunt for the best practices and you get it. But if you do not have people to follow, it is useless. That is why culture is really difficult: it needs the social engineering of team people. You need to follow the unique predispositions, the experiences, and the biases of people, and you need to handle those biases. At the same time, our teams hold diversity, and that becomes a challenging part of managing the people aspect of DevOps.

Why is this harder than buying a tool? Because a tool's manual is complete and final, while a person's "manual" never is: every teammate arrives with a different history, a different way of thinking, and different fears and ambitions — and the culture has to work with all of them at once. This is why the practices below exist: each one is a concrete handle on this hard, human part of DevOps.

6.5.2 Manage People, Not Resources

The first best practice: manage people, not resources. Be clear — they are people, not resources. Stop calling people resources.

The people who work as project managers, doing estimations and resource planning, will agree. When we start planning a project, we create a rough plan: say there are four tasks, and we judge that these four tasks can be done by two people — two full-time equivalents (FTEs) would complete these four tasks in one month of time. But when the two people actually start working on that project, looking at the skill difference and the thinking difference, there could be changes: either you need more effort, or actually it has to be done by one person — you see that they both are scaled enough, and the project is completed in 15 days rather than the 30 days you initially planned. The plan changes because of the people working on the project — only because of the people. One Java developer is just not the same as another Java developer: their experience changes, their logical thinking is different, so you cannot compare one Java developer exactly to a second Java developer. That is why they are people, not resources.

6.5.3 Don't Change the Organization — Change Yourself

The next practice: every member in your industry should have the approach of "don't change organization, rather change yourself." You will not be able to get the organization to change — being a single person, you cannot run the entire show. But you definitely can change your part in your organization: the way you are working, you can change that part.

If you are a manager, manage the teams or treat your team the same way you were expected to get treated by your manager in the past. Do not think that since you went through troubles with your previous manager, the same should happen to your team. No — change the way you work, into the way you wanted to get treated by your manager. That part is in your hand.

As you climb higher in your hierarchy, your area of influence increases in the organization. When your influence increases, many people get affected by your way of working and adopt the same; slowly and steadily, at one point in time, your organization will change the way it manages people.

This connects to the software project management course, where resource planning and managing the resource were discussed — and it is the same lesson from the other side: the plan is only as good as the people it treats as humans.

6.5.4 Identify Business Objectives

Don't keep goals as individual-focused goals; instead get everyone headed into the same direction, and working together with the same goal will help the team work more closely. Identify a common business objective for the team and the organization, and incent the entire team based on the business outcomes, versus conflicting team incentives. Do not incent the one person in the team; rather, give the credit to the entire team for their work.

Why team incentives and not individual ones? Because an individual-focused incentive splits the team into competitors — each person optimizes their own visible score, and help stops flowing sideways. A common objective aligns everyone on the same target, and when the target is met, the credit belongs to the whole team, which reinforces the sharing culture from section 6.4.

It becomes easy to measure the progress of a goal for the team and the organization if you have a single objective or a single goal. And the key framing: DevOps is not the goal — it helps you to reach your goals. The culture, the tools, and the automation are all means; the measurable end is the business outcome the whole team works towards.

6.5.5 One-on-Ones

One-on-ones are a practice that has matured in organizations over the last few years. The class shared what they discuss in their one-on-ones, and the agenda items covered: feedback; achievements; challenges; performance; career; scope of improvement; understanding expectations; open discussion and general discussion with the manager; deliverables; hiccups; aspirations; current progress; setting future goals; manager feedback about the employee; challenges in the work; process gaps; KPI and KRA; areas to concentrate; issue escalations; career progress; what did not go well; and personal aspiration. One student mentioned PTO plans — the correction was clear: PTO plans should not be discussed in one-on-ones.

Who starts the one-on-one? The class answered: the employee, anyone, the manager, the senior, the junior — either one, but at least one. The guidance is that the one-on-one should start with the people, that is, the employee. Being an employee, you should not go blind: you should not go blank. Have your agenda — the points you want to discuss with your manager should be clear; it should not be an open mind. One slide deck, one PPT, with four or five points you have to discuss, should be ready with the employee, and the manager should allow the employee to start.

The one-on-one should not be used as a place for business announcements — it is not an announcement; it is designed only for the manager and the employee who wants to discuss. This helps the employee feel that they are important in the organization, that there are people who know them: every time you connect with your manager you feel you are getting noticed, and you have a room where you can discuss your obstacles, your progress, your feedback, and where the improvements are that you need to look for. It should not be anonymous — you should not join just because it is a calendar one-on-one and HR will raise a concern about why you did not conduct it. It should be a proper agenda-oriented meeting, and that agenda should come from the employee.

An open door policy is not the same as setting up a one-on-one. Even if you have an open door policy and people can come and discuss, that is not the same case, because again, people are different. There are people who will happily walk in and discuss with the manager; there are people who feel they should probably discuss or not, always in a confusion — "if I discuss, what will my manager think?" — and slowly, steadily, they won't go. But if they are not going, how will the manager understand that particular person? A one-on-one is definitely different from an open door policy: it makes the people feel they are important to you, that you are making time for them.

The best practice is weekly or bi-weekly, 30 minutes of one-on-one. Here you should learn more about the person. For the manager, the opportunity is to learn more about that employee — let them raise first and provide your updates. The benefit for the manager: knowing where that employee is standing, the capability of the employee, where the employee needs more trainings or more hands-on to improvise, and what particular kind of project this employee would be best fit for. The benefit for the employee: you can always discuss your obstacles, look for improvements, and ask for the opportunities where you would like to grow. Sometimes, through these one-on-ones, people get a job change: you are a developer, but your core point is management — you are management material. Even the employee may not be aware of that ability; the manager gets the idea by discussing and listening, understands what the aspirations and capabilities of the employee are, and in certain cases people get headed into the correct role and responsibility where they can contribute more effectively.

6.5.6 Give Positive Feedback, Not Negative

When you hear that you get feedback from a manager, that feedback should not be negative feedback; it should always be positive feedback. This is a lesson for all managers who give feedback to their employees.

Here is the contrast. Positive version: "When you do X, Y happens, which is not optimal. Can you find a way to do it differently next time, to lead to a better outcome?" Negative version: "Why did you complete this with the X approach? Because you did X, this Y happens. Next time onwards, make sure that you won't do this." The second way is negative — you are scolding; it is like putting all the things on the employee's head. The polite, positive way lets them grow from their own mistakes.

For the employee side: always focus on your feedback and act on it, not ignore the feedback. The feedback should be accepted positively and improved accordingly.

6.5.7 Delegate to Grow the Team

The class was asked whether delegation is good or bad. The answers: good; depends — the diplomatic answer, because people misuse delegation too; good as long as it is maintained in a healthy way; we are grooming the next level team; good, otherwise everything will be on you; good and bad — and the point about misuse is that everything has to be done by the person and credit goes to the person who did nothing; reduce, scaling up to the next level; when you delegate routine things, you can explore new things.

The reference: managerial economics says that delegation is good as long as it is healthy. Delegation should always be there in an organization. Why? Otherwise your employee won't grow, because you are not giving them a task where they can grow more. And if you are delegating your work, it means that if that work can be done by a junior person, you are meant for way more tasks that should be completed by you, rather than giving your time to tasks a junior can implement. Delegation is always fruitful for an organization and even for the employee.

The unhealthy side to avoid: delegation that simply shifts the workload down while the credit travels up — "everything has to be done by the person and credit goes to the person who did nothing". Healthy delegation transfers both the task and the responsibility for it, so the junior person actually grows and the credit follows the work.

6.5.8 Create a Blameless Culture

In your team, the people should not start blaming each other. If an issue occurred because of any person, the entire team should not point at that person — "because of you, this happened" should not happen in any team. The team should share with the rest of the organization the positive impact a member of your team has made, but not share the negative impact of that person. These two practices empower the people on your team to do the best job they can for you. Rather than blaming, cover that person as an entire team.

Whenever you have failures or problems, your root cause analysis should not focus on who did this; it should focus on how you can first solve it, and how you will change the system so that the next person does not make this mistake again — the mistake should be avoided in the future by any other person in your team. Root cause analysis is not to find out who did what; it is to fix it and avoid it in the next upcoming future.

6.5.9 Measuring People Management with Surveys

If an organization adheres to all these practices — treating people as people, giving positive feedback, running great one-on-ones, keeping a blameless culture — how can it measure whether it is following effective people management? There are a few different ways to measure the culture; the most famous is to conduct surveys.

According to the Western surveys, you measure the culture in an organization by asking several questions:

• "On my team, information is actively sought." If most of the feedback from the employees is strongly agree, good people management is being adhered to in the organization.
• "On my team, failures are learning opportunities, and messengers of them are not punished."
• "On my team, responsibilities are shared."
• "Cross-functional collaboration is encouraged and rewarded."
• "Failures cause inquiry; new ideas are welcome."

The survey is conducted and, looking at the answers, you can measure whether the organization is adhering to effective people management. There are a few more suggestions the organization can keep adding based on their own business requirements or their own comfort:

• "I would recommend the team to my friend as a good place to work."
• "I have the tools and resources to do my role well."
• "I rarely think about leaving this team or my company."
• "My role makes good use of my skills and abilities."

Notice what these questions share: they all measure psychological safety and shared ownership — whether people feel safe to speak, whether failures are treated as learning, whether responsibility and credit are shared, and whether anyone wants to leave. That is the measurable fingerprint of the practices in this section: a team that is managed as people scores high on these statements.

Remember the advice already stated: you can only control your part in the organization. So after this session, think about how you can change your part in your organization — to be effective in your team and to manage your juniors in your team effectively.

6.6 DevOps Tools: An Introduction

6.6.1 The Tools Dimension and What Comes Next

The agenda of this session was the people dimension in depth, plus a high-level look at the tools dimension. The tools dimension was explained only at a high level on purpose, because the subsequent contact sessions are purely focused on the tool aspects; today there was just a small introductory look towards the DevOps tools. The people dimension came first because DevOps is a cultural movement — tools and processes produce no output if people are not ready to use them.

So what does the tools dimension actually contain? As a map for the sessions ahead, the tool landscape can be grouped into a handful of families — the same families that will each get their own dedicated session later:

A useful way to read the table: the left-to-right flow of the table is the flow of a change — write code (version control), freeze the environment (configuration management), build and test every commit (CI), check quality (test automation), ship it (deployment), and then watch it (monitoring). That chain is the deployment pipeline that later sessions will build piece by piece.

One caveat that keeps the tool dimension honest — from the DevOps literature and from industry experience: tools do not fix broken cultures; they expose and sometimes amplify what is already there. Two teams that do not talk to each other will not start talking simply because a chat tool was installed; and a team that cannot ship will not learn to ship by buying a deployment product. This matches the lesson of section 6.3 exactly: the tool alone does not create the mindset — the people operating the process with the tools do.

Exam Guidance Summary

Exam note: the recurring quiz question is "DevOps is based on which mindset?" Most students answered people, services, and process — the incorrect answer. The correct answer is the service mindset: DevOps rests on people, process, and tools, and the measurable output of the organization is business — pushing functionality early to the market to grab more business.

Exam note: the Scrum misconceptions flagged in this session are classic revision targets — there is no sprint zero and no requirement gathering sprint; sprint lengths are fixed and must not change; a sprint should not be closed in between unless the sprint goal becomes obsolete; the number of sprints can change but the sprint length cannot. Related to this, be ready to separate the project objective (the vision captured during scope and the roadmap exercise) from the sprint goal (the narrow outcome defined for each sprint, such as a login page that lets the end user access the system).

Exam note: BDD's defining idea is examinable in one sentence — the scenarios written before coding become the user acceptance test, and the behavior described belongs to the end user, not the customer.

The rest of the session was conceptual: the five phases of transforming an enterprise to a DevOps culture and the practices of effective people management, which a question on the exam could test by asking you to name or explain any of them — for example, why the subject matter expert for the intake workshop should come from outside the organization (an internal authority figure triggers fear of layoffs and raises attrition), or why people should be called people and not resources (two bags of sand are interchangeable; two people are not, which is why plans based on interchangeable "resources" go wrong).

Key Industry Applications

• Real-world: BDD sign-up flows are exactly the Google, Facebook, Instagram, Twitter, and Gmail login buttons on today's mobile apps — the scenario of "click sign up with Twitter, then grant permission" mirrors real apps. Next time you sign up for an app with an existing account, you are walking through the exact scenario chain from section 6.1.
• Real-world: Scrum is the most widely adopted Agile method in industry; the YouTube video of the first bank in the world to adopt Agile Scrum was shared for a layman perspective on how the roles, sprints, and meetings look outside the classroom.
• Real-world: post-COVID work-from-home reality stretches daily scrums from the suggested 10–15 minutes to 30–40 minutes for teams of six to eight members — a live example of industry practice drifting from the Scrum method.
• Real-world: lean management and value stream mapping are used to remove waste from the software development lifecycle — the same lean thinking that appears in the transformation gains and in the pilot phase's value stream mapping exercise.
• Real-world: DevOps teams in industry do run CI/CD while working in sprints, including ops in the same team — the answer to the in-class question about whether a DevOps team can work with the sprint method.
• Real-world: Jack Welch's transparent glass cabin at General Electric, labelled "please disturb me", is a leadership example of openness — a CEO using his position to pull concerns directly to him instead of waiting for them to travel up chains.
• Real-world: Tata Motors is the example of a decades-old "big elephant" that must adopt DevOps culture in slow, steady, pilot-based steps; startups adopt it quickly because small teams have fewer communication gaps.
• Real-world: culture surveys like "I would recommend the team to my friend as a good place to work" are used to measure people management — the same survey statements measure psychological safety and shared ownership in industry organizations.
• Real-world: Scrum documents prepared for the PSM (Professional Scrum Master) examinations and a document on best practices for defining objectives were shared as study resources; managerial economics is the reference for healthy delegation.