Private corporate batches, live online cohorts and 1-on-1 mentoring in the Scrum framework in practice — accountabilities, events, artifacts and the engineering discipline behind a real Increment — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches Scrum against the parts that actually break: a Definition of Done with engineering content rather than a checklist, backlog refinement that produces genuinely ready work, Sprint Goals that survive mid-Sprint interruption, and the continuous integration and test automation without which a usable Increment every Sprint is arithmetic that does not work. Twenty years across DevOps, SRE and Security and 10,000+ engineers trained mean the sessions connect the framework to what happens in build, test and release — including how Scrum teams handle production incidents, dependencies and change approval without abandoning the Sprint.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Scrum that means a trainer who has run it in production — the Scrum framework in practice — accountabilities, events, artifacts and the engineering discipline behind a real Increment — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Scrum batchScrum is a lightweight framework for delivering complex product work in short, fixed-length cycles called Sprints. It defines three accountabilities — Product Owner, Scrum Master and Developers — five events, and three artifacts, each with a commitment attached: the Product Backlog has a Product Goal, the Sprint Backlog has a Sprint Goal, and the Increment has a Definition of Done. That is the entire framework, and its brevity is deliberate.
Scrum is built on empirical process control. When the work is complex enough that you cannot specify the outcome in advance, you proceed by transparency, inspection and adaptation: make the current state visible, inspect it at defined points, and adapt based on what you find. Each event exists to serve one of those. Sprint Planning sets a goal, the Daily Scrum inspects progress toward it, the Sprint Review inspects the Increment with stakeholders, and the Retrospective inspects how the team works. Remove the inspection and you are left with a schedule of meetings.
What Scrum deliberately does not prescribe is how to engineer the product. It says every Sprint must produce a usable Increment; it does not say how. That gap is where most implementations fail — teams adopt the events, produce work that is 'done except for testing', and discover that a Sprint has become a two-week deadline with an integration debt attached. A serious Scrum course therefore spends real time on the Definition of Done, on backlog refinement, and on the technical practices that make a genuinely usable Increment possible every Sprint.
Scrum is the most widely adopted delivery framework in software and, by a wide margin, the most widely misapplied. The recognisable pattern is a team with all five events, a board, a velocity chart and a Scrum Master who administers a tool — and a Sprint that reliably ends with unfinished work carried over. The framework is present; the empiricism is not.
That is why demand has moved from awareness training to remediation. Organisations are not buying an explanation of what a Daily Scrum is; they are buying help with a Product Owner who cannot order a backlog, a Definition of Done that excludes testing, dependencies that make a Sprint Goal impossible, and a Retrospective whose output nobody implements.
For individuals, the framework is also a career floor rather than a differentiator. Knowing the events is assumed. What gets someone hired as a Scrum Master or Product Owner is the ability to refine a backlog into ready work, facilitate a difficult conversation between engineering and stakeholders, protect a Sprint Goal from mid-Sprint churn, and demonstrate improvement with data.
What Scrum actually is according to the Scrum Guide, and why it is deliberately incomplete. Empirical process control — transparency, inspection, adaptation — as the reason each element exists, the five Scrum values, and a clear line between what the framework prescribes and what a team must decide for itself.
Topics: Complexity and why empirical control is required · Transparency, inspection and adaptation · The Scrum Guide: what it does and does not prescribe · The five Scrum values and their practical consequences · Scrum compared with Kanban and with stage-gate delivery · Common misreadings of the framework
Three accountabilities, not job titles, and what each is genuinely responsible for. Product Owner as a single ordering authority, Scrum Master as a facilitator and impediment remover rather than an administrator, and Developers as a self-managing whole. Then the anti-patterns: the proxy Product Owner, the Scrum Master as tool clerk, and component teams that cannot finish anything alone.
Topics: Product Owner: value, ordering and stakeholder management · Scrum Master: facilitation, coaching and impediment removal · Developers: self-management and collective accountability · Cross-functional teams versus component teams · Anti-patterns: proxy Product Owner, Scrum Master as administrator · Managers and the team: what changes and what does not
The three artifacts and the commitment attached to each — Product Goal, Sprint Goal, Definition of Done. Then the Definition of Done in depth, because it is the artifact that decides whether an Increment is real: what belongs in it, what teams routinely leave out, and how to strengthen it without stalling delivery.
Topics: Product Backlog and the Product Goal · Sprint Backlog and the Sprint Goal · The Increment and the Definition of Done · Writing a Definition of Done with engineering criteria · Undone work, carry-over and integration debt · Transparency of artifacts and who they serve · Strengthening a weak Definition of Done incrementally
All five events, each with its purpose, timebox, participants and failure mode. Sprint Planning across its three topics, the Daily Scrum as a plan adjustment rather than a status report, the Sprint Review as a working session with stakeholders, and the Retrospective as the team's own improvement mechanism.
Topics: The Sprint as a container and why the length matters · Sprint Planning: why, what and how · The Daily Scrum: adjusting the plan toward the Sprint Goal · Sprint Review: inspecting the Increment with stakeholders · Sprint Retrospective: formats and facilitation · Timeboxes, attendance and cancelling a Sprint · Event anti-patterns and how each one presents
Where Sprint quality is actually determined. Refinement as a continuous activity, ordering by value and risk, splitting items so they fit inside a Sprint, and forecasting — Sprint capacity, release forecasting and the difference between a forecast and a commitment.
Topics: Refinement as a continuous activity, not an event · Ordering by value, risk, dependency and cost of delay · Story writing, acceptance criteria and Definition of Ready · Splitting items to fit within a Sprint · Estimation, story points and their misuse · Sprint capacity and release forecasting · Managing stakeholders and competing priorities
The framework requires a usable Increment every Sprint and does not say how to get one. This module supplies the missing half: continuous integration, test automation, refactoring inside the Sprint, and how to handle production support, interrupts and dependencies without carrying work over every time.
Topics: Continuous integration and keeping mainline releasable · Test automation as a Definition of Done requirement · Refactoring and technical debt inside a Sprint · Handling production incidents and interrupt work · Cross-team dependencies and Sprint Goal risk · Why 'Sprint zero' and hardening Sprints are symptoms · Making a Sprint Goal achievable when dependencies exist
Multiple teams on one product, and how to know whether any of it is working. Scaling approaches in outline, multi-team planning and integration, then measurement — outcome over output — and the coaching stances a Scrum Master needs when the impediment is a person rather than a process.
Topics: Multiple teams on one Product Backlog · Scaling approaches in outline: Nexus, LeSS, Scrum@Scale, SAFe · Multi-team refinement, planning and integration · Measuring outcomes: evidence-based management · Flow metrics alongside Scrum: cycle time and throughput · Coaching stances: teaching, facilitating, mentoring, challenging · Handling conflict, silence and dominant voices in a team
We rebuild the agenda around the tools you actually run.
Request a custom agendaWrite a Definition of Done with engineering criteria, then apply it retrospectively to the last Sprint's completed items and count how much would have failed it.
Take an unrefined feature request through story mapping, splitting, acceptance criteria and ordering until Sprint Planning could start without discovery.
Plan, execute, review and retrospect a compressed Sprint against a real goal — with an injected mid-Sprint interrupt and a stakeholder who changes their mind at Review.
Facilitate three scenarios a Scrum Master actually faces: a Product Owner overriding the team's capacity, a silent team member, and a Retrospective that has become a complaint session.
Build a release forecast from historical throughput, express it as a range with confidence, and rehearse presenting it to a stakeholder who wants a fixed date and fixed scope.
Deliver a complete proposal for a real team: accountabilities, Definition of Done, refinement cadence, event design, interrupt policy, metrics and the first three improvements.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.