JC/00-SI>102706#5 - Team project of IT system (2026/27z)

The program at a glance

Crafting Value with Modern Teams is a ten-lecture journey (W01 to W10) into how modern IT teams create value, structured so each lecture builds on the one before. It starts with foundations (project, product, team) and the agile philosophy behind them, then moves to frameworks such as Scrum, Kanban, XP and Lean, and the roles and competencies that make them work. Later lectures bring the theory to life: a hands-on sprint simulation, building high-performing teams, scaling agility, engineering excellence with pair and mob programming, and product thinking with visions, personas and user stories. The final lecture asks how AI is changing the engineer's role. Expect active learning: exercises, live cases, discussions and live polls, plus the semester project you run in the project classes, all under our shared "4x4" working agreement.

W01 Main Concepts

Foundations for the whole program. You will define three concepts everything else depends on: project, product and team. A project is a time-bound endeavour producing a unique result, judged on scope, time and budget. A product is something physical or digital built through a process, delivering ongoing value and evolving through versions, with product management asking what and why. A team, in Arie de Geus' words, is a group of people who need each other to work effectively, marked by interdependence, collaboration and complementary skills, unlike a task group that could work alone. Think-Pair-Share exercises contrast a city with a bridge and an operating room with a swimming pool, before a summary discussion. You leave able to explain project versus product, define a team, and see why these basics matter for using agile frameworks well.

W02 Why Agile

Why agile exists. The lecture traces the path from craft production and Tayloristic industry, through Ford and the Toyota Just-In-Time system, to modern software work, and frames agility as reacting to change in small steps instead of planning everything up front, echoing Deming's PDCA cycle and Kniberg's cannon versus rockets. The core is the Agile Manifesto: its four values and twelve principles, each on its own card, from early and continuous delivery to reflecting and adjusting. Boris' Ball Game shows estimation and flow under changing constraints, and a pair-reflection exercise has you choose the principle closest to you. Closing slides distinguish iterative from incremental delivery and present the agile mindset as the strong hidden layer beneath values, principles, practices and tools.

W03 Just Frameworks

What a framework is, and what it is not. A framework is a deliberately incomplete set of principles, roles, artifacts and practices that gives teams a frame for action while leaving decisions to them, unlike a prescriptive methodology such as PRINCE2. You see the layered structure: mindset, values and principles underneath, roles, processes and artifacts on top, summed up as "a framework is a skeleton, not a recipe". The lecture then surveys the popular frameworks: Scrum, built on empiricism and its three pillars; Kanban, built on visualizing and limiting flow; Extreme Programming with its engineering practices; and Lean Software Development. Live polls check understanding, diagrams walk the Scrum framework and a Kanban board, and multitasking versus flow shows the cost of context switching. It ends with a first look at scaling, where coordination becomes the challenge once many teams share one product.

W04 Role Model

Who does the work, and what each person is accountable for. The lecture revisits the team definition and the test of a real team versus a task group, then compares the roles the frameworks define: in Scrum the Product Owner, Scrum Master and Developers with their areas of accountability, and in Kanban, where roles are not formally fixed, the service-oriented roles around the flow of work. A central distinction is role versus function: a role is a scope of responsibility, a function is how that responsibility is carried out, so the same role can look different from team to team. You then survey the practical functions of IT teams across business, development, testing, architecture, operations, security and agile coaching, and meet cross-functional (XF) teams and T-shaped competencies. You learn to read framework role descriptions as adaptable frames, not detailed instructions.

W05 Frameworks in Action

Theory becomes practice through a hands-on simulation. Your team runs the "Student CompAnion" case across three short sprints, working with paper cards instead of code: Sprint Planning with drawn capacity and selected User Stories, a short execution window, Sprint Review where the Product Owner accepts the result, and a Sprint Retrospective. Between sprints a wheel of random events changes capacity and requirements, so you feel how planning breaks down when the ground shifts. Along the way the lecture grounds the mechanics: the Scrum framework and its pillars, the areas of accountability, and the artifacts (Product Backlog, Sprint Backlog, Increment). The closing retrospective turns the experience into lessons about what was valuable and what was not, showing how daily, review and retro practices make the Manifesto's values and principles real in a team's work.

W06 High Performing Agile Teams

What separates an ordinary team from a high-performing one. The lecture moves from group to team and presents the models that describe the journey: Tuckman's stages (forming, storming, norming, performing) and Shu Ha Ri, the path from following rules to internal mastery. Management 3.0 tools such as Moving Motivators and the Team Charter show how to build engagement, motivation and shared identity. A block of live cases (a parking space, an exam format, a study trip, a party, how the project is credited) lets you practise agile decision models such as consensus, consent, democratic, directive and random. The lecture then confronts the barriers: Lencioni's five dysfunctions, from absence of trust to inattention to results, and psychological safety as the foundation of honest collaboration. It closes with Mob Programming and a shared reflection on failure that makes it safe to exchange experience.

W07 Agile at Scale

What changes when one team becomes many. The lecture opens with the difference between a small and a big ship, then defines scaling and separates two ways of working: independence, where teams operate autonomously, and coordination, where their work must be aligned. A "Build a Car Together" exercise makes the difference concrete, and the lecture examines what is actually observed when organisations grow. It introduces governance as the mechanism that keeps a large organisation consistent and effective, surveys scaling frameworks such as SAFe, LeSS and Disciplined Agile, and explains the coordination layer: backlog hierarchy (portfolio, program, team, sprint), PI Planning and roles at the ART level. It then looks beyond process to the shape of the organisation, including the six dimensions of scaling and the challenges of distributed teams, and contrasts startup and corporation cultures.

W08 Technical Excellence

Engineering as the foundation of agility. The lecture argues that no process saves a team that cannot build well, using the image of a cockpit full of procedures that is useless without a competent pilot. It returns to the agile mindset and values, then dives into Extreme Programming: its values, activities and, above all, its practices, each given a short treatment: TDD with the red-green-refactor cycle, continuous integration, refactoring, simple design, the planning game, frequent releases, on-site customer, shared code ownership, coding standards, system metaphor, sustainable pace and customer tests. Two hands-on exercises make teamwork tangible: Pair Programming with the "Ugly Number" task, rotating driver and navigator roles, and Mob Programming with "Add Digits" run by the whole team. The lecture closes by explaining why pair and mob programming pay off, for both the product and the team.

W09 The Product Way

Product thinking and its tools. The lecture revisits the product definition and the project versus product distinction, then asks why a product vision matters and how to keep the focus on customer value, working through the "Student CompAnion" case. Its core is a set of practical instruments: the Agile Inception Deck and its ten questions; personas, with templates, an example and two modelled users, one a perfectionist and one a procrastinator; and User Stories with acceptance criteria, including the classic template and worked examples. It shows how a User Story is a conversation that leads from idea to code, and where it sits in the backlog structure of vision and mission, epic, user story and task. A short film, "We need to talk!", illustrates the gap between a solution and the real problem. You practise building a vision, a persona and a story with criteria.

W10 How AI is changing way of working

The closing lecture asks what AI does to the engineer's job. It first looks back at the semester project and exam, drawing five insights about the client, the project, team structure, the main artefact and the team's processes. Then it defines what AI is and how it differs from plain automation: modern systems decide, they do not only execute. The central problem is the "broken rung": fewer offers for juniors, research on employment of 22 to 25 year olds, and the split between codified knowledge, which LLMs easily automate, and tacit knowledge, which stays with seniors. The lecture proposes a new career ladder (junior and implementator, mid and orchestrator, senior and strategist, architect and leader), compares the traditional and agentic models, and introduces selective delegation and intentional learning against skill atrophy.