Agile training
Agile training for teams, in IT and beyond
- Tailored after a scoping call
- In person or remote
- For business teams
- Practice, not theatre
Plenty of organisations say they are agile. They hold stand-ups, run sprints, use sticky notes and move tickets across a board. Yet work still arrives late, priorities still change without warning and teams still deliver things customers did not need. Much of what passes for agile is theatre: the ceremonies without the mindset, and the vocabulary without the results.
Collective Campus has been building team capability in Australia since 2015, and its agile training focuses on what actually makes agile work: delivering value in small increments, learning from feedback, making work visible, limiting work in progress and improving continuously. The training is framework-agnostic. It draws on Scrum, Kanban and lean thinking where they help, and it works for technology teams and for teams that have never written a line of code, such as marketing, HR, finance, policy, operations and customer teams.
Quick answer
Agile training teaches teams to deliver value in small increments, prioritise work in a visible backlog, plan in short cycles, limit work in progress, gather feedback early and improve continuously. Good agile training is practical and framework-agnostic, applying Scrum, Kanban and lean practices to the team's real work, including non-IT work. Collective Campus tailors every agile program after a scoping call, with no fixed format, length or group size, and does not publish prices.
What agile actually means
Agile began in software. In 2001, a group of practitioners published the Manifesto for Agile Software Development, which valued individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. The manifesto's twelve principles describe practices such as delivering frequently, welcoming changing requirements, working closely with customers, building around motivated people and reflecting regularly on how to become more effective.
Stripped of software language, agile is a way of working for any situation where the problem is complex, requirements are uncertain and learning matters. Its core ideas are simple:
- Deliver in small increments. Break work into small pieces that create value on their own, rather than waiting for one big release.
- Get feedback early. Show work to customers and stakeholders often, and use what is learned to adjust.
- Prioritise ruthlessly. Keep a single, ordered list of work, with the most valuable items at the top.
- Make work visible. Use boards and simple metrics so everyone can see what is happening and where it is stuck.
- Limit work in progress. Finish things before starting new ones, reducing multitasking and delays.
- Inspect and adapt. Regularly reflect on what is working and change how the team works.
- Empower teams. Give teams the context and authority to decide how to do their work.
Agile theatre and how to avoid it
Agile theatre happens when teams adopt agile rituals without the underlying intent. Signs include:
- Stand-ups that are status reports to a manager rather than coordination among the team.
- Sprints that are simply deadlines, with no working increment or feedback at the end.
- Backlogs that are endless wish lists rather than prioritised, refined work.
- Retrospectives that produce the same complaints and no changes.
- Velocity treated as a performance target, encouraging teams to inflate estimates.
- Teams called agile but given fixed scope, fixed dates and no authority to change either.
- Frameworks applied rigidly because "that is what the book says".
The training addresses these directly. Rather than teaching ceremonies for their own sake, it asks what each practice is for and how the team can achieve that purpose in its own context.
Agile for non-IT teams
Agile is not only for software teams. Many business teams face exactly the conditions agile was designed for: changing priorities, competing demands, unclear requirements and the need to deliver value faster. Marketing teams run campaigns, HR teams design programs, policy teams develop advice, finance teams build reports and operations teams improve processes. All can benefit from visible work, clear priorities, small increments and regular reflection.
Non-IT teams often face particular challenges:
- A mix of project work and business-as-usual. Unlike many software teams, business teams juggle planned projects with a steady stream of requests and routine work.
- Many stakeholders. Work often serves several internal customers with different priorities.
- Less obvious increments. It can be harder to see how to break a policy, campaign or program into smaller pieces that deliver value.
- Unfamiliar language. Terms such as sprints, story points and product owners can feel foreign or off-putting.
The training adapts agile to these realities. For many business teams, a Kanban approach, with a visible board, clear policies and limits on work in progress, works better than time-boxed sprints. For project-heavy teams, short planning cycles and regular reviews help. Language is adapted so practices feel natural rather than imported.
What the training covers
Every program is tailored after a scoping call. Most draw on the following building blocks.
Agile mindset and principles. Why agile works, where it fits and where it does not, and how to tell genuine agility from theatre.
Backlogs and prioritisation. Building a single, ordered backlog, writing clear work items such as user stories, splitting large items into smaller ones and prioritising by value, urgency and effort.
Planning in short cycles. Planning work in short iterations or cadences, agreeing what can realistically be delivered and committing as a team.
Estimation. Practical approaches to estimation, including relative sizing, and when estimation is useful and when it is not.
Visualising work. Designing a board that reflects how the team actually works, from simple to-do, doing and done columns to boards that show stages, blockers and classes of work.
Flow and work in progress limits. Understanding why limiting work in progress speeds delivery, identifying bottlenecks and managing flow.
Scrum essentials. Roles, events and artefacts in Scrum, for teams for which it fits, with an emphasis on purpose rather than ritual.
Kanban essentials. Visualising work, limiting work in progress, managing flow, making policies explicit and improving continuously.
Reviews and feedback. Showing work to customers and stakeholders regularly and using feedback to adjust priorities.
Retrospectives. Running retrospectives that lead to real change, with simple formats and follow-through.
Working with stakeholders. Managing demand, saying no or not yet, and making trade-offs transparent.
Aligning technical and non-technical people. Building shared understanding between technology teams and the business so they can plan and deliver together.
Scrum, Kanban or something else?
The training is framework-agnostic because no single framework suits every team.
- Scrum works well for teams developing a product or service in which work can be planned in fixed-length iterations, delivered as increments and reviewed with stakeholders. It provides clear roles and a regular rhythm.
- Kanban works well for teams with a continuous flow of work, varied request types and a mix of planned and unplanned work. It starts with how the team works today and improves it gradually.
- Lean thinking focuses on delivering value and removing waste, and is useful for improving processes and reducing delays across teams.
- Hybrid approaches combine elements, such as a Kanban board with regular planning and retrospectives, and are common in practice.
The right choice depends on the nature of the work, the team and the organisation. The training helps teams choose and adapt rather than adopt a framework wholesale.
Case studies from Collective Campus
Deakin University. Collective Campus ran an agile bootcamp for Deakin's data and business analysts, covering practical skills such as building backlogs, writing stories and estimating work, so analysts could apply agile practices to their own projects.
Bluedot. Collective Campus ran a Scrum workshop for Bluedot that helped align technical and non-technical staff around a shared way of planning and delivering work, and the team reported improved estimation.
B2Cloud. Collective Campus worked with B2Cloud to align technical and non-technical staff around agile ways of working, building a shared understanding of how work flows from idea to delivery.
Who agile training is for
- Technology and digital teams adopting or refreshing agile practices.
- Business teams such as marketing, HR, finance, policy, legal and operations who want more visible, focused and responsive work.
- Analysts and project teams who need to plan and deliver iteratively.
- Leaders and managers who need to support agile teams rather than undermine them.
- Mixed teams of technical and non-technical people who need a shared way of working.
- Teams new to agile and teams that have been "doing agile" for years without seeing results.
The role of leaders
Agile teams struggle when leaders keep working in the old way. If leaders set fixed scope and fixed dates, bypass the backlog with urgent requests or treat velocity as a performance measure, agile practices quickly become theatre. Leaders need to set clear goals and priorities, protect teams from constant interruption, trust teams to decide how to work, accept that plans will change as teams learn, and remove obstacles teams cannot remove themselves. Agile training for leaders focuses on these behaviours.
Formats (shaped after a scoping call)
Every program is tailored after a scoping call, so there is no fixed length, headcount or package. What changes from one organisation to the next is the mix of the elements below, chosen to fit the outcome the team needs and the real constraints on its time.
- Focused workshop. A single facilitated session built around one live problem the team brings into the room. Best when the goal is a shared language, a quick diagnosis and a small number of agreed next steps.
- Workshop series. A sequence of shorter sessions spaced out so people apply each idea at work between sessions and bring back what happened. Best when the goal is behaviour change rather than awareness.
- Applied program. Training combined with a real piece of work: a service, process or team challenge the group moves forward while learning. Best when leaders want a visible result, not just a completion record.
- Leadership session plus team rollout. Leaders go first so they can model the behaviour and remove blockers, and then teams follow with sessions that reflect what leaders agreed.
- Coaching and follow-up. Check-ins, clinics or office hours after the formal sessions so teams get help when they hit the hard part of applying the method.
- In person, remote or hybrid. Delivered on site in Sydney, Melbourne, Brisbane and other Australian cities, or live online for distributed teams. Remote sessions are designed for remote work rather than a slide deck streamed over video.
The scoping call covers who is in the room, what is already in place, what success looks like in practical terms and what would get in the way. The design follows from those answers.
What teams leave with
- A shared understanding of agile principles and how they apply to the team's work.
- A working backlog of real work, prioritised and broken into smaller items.
- A board designed around how the team actually works.
- A planning rhythm suited to the team, whether sprints, a Kanban cadence or a hybrid.
- Work in progress limits and practices to improve flow.
- Better estimation and planning skills grounded in the team's experience.
- Retrospective formats that lead to real improvements.
- Stronger alignment between technical and non-technical people.
- A clear view of agile theatre and how to avoid it.
How to tell whether it worked
Agree a few practical measures before the program starts, so success is judged on evidence rather than on how the session felt. Useful measures for this topic include:
- Lead time. How long work takes from request to delivery.
- Throughput. How many work items the team completes over a period.
- Work in progress. How many items are in progress at once, and whether limits are respected.
- Predictability. How consistently the team delivers what it plans.
- Blocked work. How often and how long work is blocked.
- Stakeholder feedback. How satisfied customers and stakeholders are with what is delivered and how often they see progress.
- Retrospective actions. Whether improvements agreed in retrospectives are implemented.
- Team health. How team members rate clarity, focus and workload.
Why capability building beats one-off training
Most training fails for a simple reason: people learn something in a room, return to a full inbox and an unchanged system, and within a few weeks behaviour drifts back to where it started. The research on learning transfer has said this for decades. What predicts whether learning sticks is less about the quality of the session and more about what happens around it: whether leaders expect and reinforce the new behaviour, whether people get to apply it immediately on real work, and whether the system they work in makes the new way easier rather than harder.
Collective Campus designs for transfer from the start. That means working on live problems rather than case studies from other companies, involving leaders so they can reinforce the change, building in practice and follow-up between sessions, and agreeing practical measures upfront. It also means being honest when training is not the answer. Sometimes the real blocker is a policy, an incentive or a system, and the most useful thing a scoping call can do is name it.
The difference shows up in what teams say afterwards. A one-off session produces "that was interesting." A capability building program produces "this is how we work now," along with the evidence of a changed process, a fixed journey or a decision made differently.
Comparing provider types
Agile training comes from several kinds of provider. The comparison below describes provider types, not individual firms.
- Capability building provider such as Collective Campus. Typically strong at: Practical, framework-agnostic workshops applied to the team's real work, in IT and beyond. Watch out for: Focuses on team capability, not certification. Best fit when: You want a team to work in a genuinely agile way, quickly.
- Certification course provider. Typically strong at: Preparation for formal agile and Scrum certifications. Watch out for: Strong on theory and exam content, less on the team's real work. Best fit when: Individuals need a recognised certification.
- Agile coaching consultancy. Typically strong at: Embedded coaches working with teams over time. Watch out for: Can be a significant ongoing commitment. Best fit when: You are undertaking a large agile transformation.
- Tool vendor trainer. Typically strong at: How to configure and use a specific work management tool. Watch out for: Teaches the tool, not the way of working. Best fit when: You have chosen a tool and need people to use it.
- Online course platform. Typically strong at: Self-paced videos on agile concepts. Watch out for: Little practice or tailoring to the team. Best fit when: You want low-cost awareness for individuals.
Decision checklist: choosing a provider
Use these questions when comparing providers. A strong provider will answer most of them clearly before any proposal is written.
- Is the training framework-agnostic, or does it push one framework?
- Will we work on our real backlog and real work during the training?
- Does it suit non-IT teams if that is who we are?
- Does it address agile theatre directly?
- Does it cover both Scrum and Kanban, and help us choose?
- How will leaders be involved?
- Will technical and non-technical people learn together?
- Will we leave with a board, a backlog and a planning rhythm?
- How will we know whether delivery has improved?
- Can it be delivered remotely or in a hybrid format?
- Can the provider show real case studies?
- Is the program tailored after a scoping call rather than sold off the shelf?
How Collective Campus scopes and runs a program
Collective Campus has been running capability building programs for teams in large organisations since 2015. The approach is the same whatever the topic.
- Scoping call. A conversation with the sponsor, and often with a few people from the team, about the outcome, the context and the constraints. Nothing is proposed before this call, because a generic proposal would be guessing.
- Discovery. Where it helps, short interviews or a brief survey with participants so the content reflects their real work and the language they use.
- Design. Content, exercises and examples are built around the team's own situations. Generic case studies are kept to a minimum; the team's live work is the main material.
- Delivery. Highly practical, facilitated sessions where most of the time is spent doing rather than listening. Participants leave with things they made, not just notes.
- Application. Agreed actions, owners and a simple way to check progress, so the work continues after the facilitators leave.
- Review. A debrief with the sponsor on what changed, what got stuck and what the team needs next.
Pricing, format and timing are all discussed after the scoping call, once both sides understand what the work actually involves.
Preparing for a program
A little preparation makes a large difference to the result.
- Name a sponsor. Someone senior enough to remove blockers and to ask about progress afterwards.
- Pick real work. Bring a live problem, journey, project or decision the team actually needs to move. Abstract exercises produce abstract results.
- Tell participants why. People engage more when they know why they are there and what will be different afterwards.
- Protect the time. Sessions interrupted by email and calls produce half the value. Agree that the time is protected.
- Plan the week after. Book the first follow-up action before the program starts, so momentum is not lost.
- Gather what already exists. Data, feedback, previous reviews and earlier attempts all help tailor the content.
Key terms
- Agile: A way of working that delivers value in small increments, uses feedback and adapts to change.
- Backlog: An ordered list of work the team intends to do.
- User story: A short description of a piece of work from the perspective of the person who benefits.
- Sprint: A fixed-length period in which a Scrum team delivers an increment of work.
- Scrum: A framework for delivering work in iterations, with defined roles, events and artefacts.
- Kanban: A method for managing work by visualising it, limiting work in progress and improving flow.
- Work in progress limit: A cap on how many items can be in a stage at once.
- Lead time: The time from when work is requested until it is delivered.
- Retrospective: A regular meeting in which the team reflects on how it works and agrees improvements.
- Stand-up: A short daily coordination meeting for the team.
- Product owner: The person responsible for maximising value and ordering the backlog in Scrum.
- Increment: A usable piece of work delivered at the end of an iteration.
- Agile theatre: Adopting agile rituals without the mindset or results.
Agile and high performing teams
Agile practices and high performing teams reinforce each other. Agile provides structure for focus, feedback and improvement, while strong teams bring trust, clear goals and accountability. Programs on high performance teams complement agile training by building the team dynamics that make agile practices stick.
Agile also connects to other capabilities. Design thinking helps teams understand customers and frame the right problems before building solutions, which keeps the backlog focused on what matters. Agile ways of working are central to innovation capability, because they allow organisations to test ideas in small steps and learn quickly. And limiting work in progress and protecting focus links directly to productivity: teams that start fewer things finish more of them.
Getting started: a practical sequence
Teams new to agile do not need to change everything at once. A practical sequence helps them build momentum.
- Make the work visible. Put all current work on a board, including business-as-usual and requests that are usually invisible. This step alone often reveals overload and hidden priorities.
- Agree priorities. Create a single ordered backlog and agree who decides the order. Remove or park work that does not matter.
- Limit work in progress. Set simple limits and focus on finishing before starting.
- Establish a rhythm. Agree a regular cadence for planning, coordination, reviews and retrospectives that suits the team.
- Deliver in smaller pieces. Practise breaking work into smaller items that deliver value and can get feedback sooner.
- Measure and improve. Track a few simple measures, such as lead time and throughput, and use retrospectives to improve.
Each step delivers value on its own, and together they form a genuinely agile way of working.
Common mistakes in agile adoption
- Starting with the tool. Configuring software before the team understands why and how it wants to work.
- Copying another team. Adopting practices that suited a different context without adapting them.
- Too many ceremonies. Adding meetings without removing others, leaving teams with less time for work.
- Ignoring business-as-usual. Planning only project work, then being overwhelmed by everything else.
- Measuring the wrong things. Using velocity or story points to compare teams or judge performance.
- No leadership change. Expecting teams to become agile while leaders keep working the old way.
- Stopping at training. Treating agile as a one-off course rather than a capability the team keeps building.
Agile in the public sector
Government agencies and councils increasingly use agile approaches for digital services, policy and program delivery. Public sector teams face particular constraints, such as governance, procurement, accountability and fixed budgets. Agile can work within these constraints when teams are clear about what is fixed and what can flex, involve governance stakeholders early, deliver and demonstrate progress regularly and document decisions appropriately. Training for public sector teams adapts agile practices to these realities.
Remote and hybrid agile teams
Many agile teams now work across locations. Remote and hybrid agile depends on digital boards that stay current, clear working agreements, well-run online meetings and deliberate effort to maintain connection and shared understanding. The training covers practices that help distributed teams coordinate, collaborate and improve without relying on being in the same room.
Tailored after a scoping call
Collective Campus has been running programs since 2015 and tailors every agile program after a scoping call. The conversation explores the team's work, its current practices, what is getting in the way and what better delivery would look like. The program is then designed around real work, so the team leaves with a board, a backlog and a rhythm it can use immediately. There is no fixed format, length or group size, and prices are not published.
Writing good work items
Much of agile's value comes from how work is described and split. Large, vague items such as "improve onboarding" or "launch the campaign" are hard to estimate, hard to prioritise and slow to deliver. The training helps teams write clearer work items and break them into smaller pieces.
A useful work item explains who benefits, what they need and why it matters. In software, this is often written as a user story: a type of user, a need and the goal it serves. Business teams can use the same structure or a simpler one, as long as the purpose is clear. Each item should also have acceptance criteria, describing how the team will know it is done.
Splitting work is a skill that improves with practice. Teams learn to split by customer group, by step in a process, by channel, by level of detail or by the simplest version that delivers value first. A new onboarding program, for example, might start with a single improved welcome pack for one team, tested and refined before being extended. Smaller items move faster, generate feedback sooner and reduce the risk of large failures.
Estimation without the theatre
Estimation is one of the most debated parts of agile. Used well, it helps teams plan, spot large or unclear items and have useful conversations about scope. Used badly, it becomes a time-consuming ritual or a performance target.
The training covers practical approaches. Relative sizing compares items with each other rather than guessing hours, which tends to be quicker and more reliable. Techniques such as planning poker help teams surface different assumptions; when estimates differ widely, the discussion usually reveals something important. Some teams find they can stop estimating individual items altogether, instead splitting work into similarly sized pieces and forecasting from throughput. The right approach depends on what the team and its stakeholders need to know.
Above all, estimates are forecasts, not promises. Teams that treat them as commitments tend to pad them, which defeats the purpose. Leaders play an important role in keeping estimation honest.
Running retrospectives that change things
Retrospectives are the engine of continuous improvement, yet many teams find them repetitive or pointless. Common problems include the same issues raised every time, no follow-through on actions, people not feeling safe to speak honestly and too many actions agreed at once.
The training gives teams practical ways to make retrospectives work. Vary the format to keep thinking fresh. Focus on one or two improvements at a time. Make actions specific, owned and visible on the team's board. Start each retrospective by reviewing the previous actions. Use data, such as lead time or blocked work, to ground discussions. And create conditions where people can raise problems honestly, which depends on trust within the team.
Managing demand and stakeholders
Business teams often struggle less with doing the work than with managing the demand for it. Requests arrive from many directions, everything is urgent and the team has little say over priorities. Agile practices help make this visible and manageable.
A single backlog shows stakeholders everything the team is being asked to do. Clear intake processes make it easier to capture and assess requests. Regular prioritisation conversations with stakeholders replace ad hoc escalation, and work in progress limits make trade-offs explicit: if something new starts, something else waits. Teams also learn how to say no or not yet constructively, explaining the impact of a new request on existing priorities and inviting stakeholders to make the trade-off.
Signs a team would benefit from agile training
- Too much work started and too little finished.
- Priorities that change constantly with no clear owner.
- Work that is invisible until it is late.
- Long delays between starting something and getting feedback on it.
- Frequent context switching and multitasking.
- Technical and business people who struggle to plan together.
- Agile ceremonies in place but no improvement in results.
- Retrospectives that repeat the same complaints.
If several of these apply, practical agile training, combined with leadership support, can help the team deliver more of what matters with less stress.
What a session looks like
Sessions are hands-on and built around the team's real work. Rather than learning agile through generic simulations alone, participants bring their current projects, requests and routine tasks. Early in the program, the team maps all of its work onto a board, which often surprises people with how much is in progress at once. From there, the team builds a prioritised backlog, practises splitting large items into smaller ones, designs a board that reflects its actual workflow and agrees work in progress limits.
Short explanations of concepts are followed immediately by practice. A team might learn the purpose of a review, then plan its first one with real stakeholders in mind. It might learn about flow, then identify where work tends to get stuck on its own board. Simulations and games are used where they help people experience an idea, such as the effect of multitasking on delivery, but always connected back to the team's own context.
By the end, the team has more than knowledge. It has a working system that it can start using the next day, and a plan for how it will review and improve that system over the following weeks.
Sustaining agile after the training
Agile capability grows through use. Collective Campus encourages teams to treat the first few cycles after training as an experiment: try the new practices, observe what happens, and use retrospectives to adjust. Simple measures such as lead time, throughput and work in progress give the team evidence of whether things are improving. Leaders can support momentum by using the backlog for new requests, attending reviews and acting on obstacles the team raises. Where helpful, follow-up sessions can help a team refine its practices once it has some experience, tackle problems that have emerged and extend agile ways of working to neighbouring teams. Over time, the team stops thinking of agile as something it was trained in and starts treating it simply as how the team works, which is the clearest sign the capability has taken hold.
Talk to Collective Campus
If agile has become theatre, or a business team wants to work in a more focused and responsive way, start with a short scoping call. The conversation covers the team's work, what is getting in the way and what better delivery would look like. Book a scoping call.
Frequently asked questions
- What is agile training?
- Agile training teaches teams to deliver value in small increments, prioritise work, plan in short cycles, make work visible, limit work in progress, use feedback and improve continuously.
- Can non-IT teams use agile?
- Yes. Marketing, HR, finance, policy, operations and customer teams can use agile practices such as visible boards, prioritised backlogs, work in progress limits and regular retrospectives, adapted to their work.
- What is the difference between Scrum and Kanban?
- Scrum organises work into fixed-length sprints with defined roles and events. Kanban manages a continuous flow of work by visualising it and limiting work in progress. Many teams use a hybrid.
- What is agile theatre?
- Agile theatre is adopting agile ceremonies and vocabulary without the mindset or results, such as stand-ups that are status reports or sprints with no feedback.
- Is the training framework-specific?
- No. Collective Campus training is framework-agnostic, drawing on Scrum, Kanban and lean thinking to suit the team.
- Does the training lead to certification?
- The focus is practical team capability rather than certification. Teams that need formal certification can pursue it separately.
- How long is agile training?
- There is no fixed length. Collective Campus tailors every program after a scoping call, depending on the team and its goals.
- How much does agile training cost?
- Collective Campus does not publish prices. Pricing is discussed after a scoping call, once the scope and format are clear.
- What do leaders need to do differently in agile teams?
- Leaders need to set clear goals and priorities, protect teams from constant interruption, trust teams to decide how to work and remove obstacles.
- Can agile training be delivered remotely?
- Yes. Programs can be delivered in person, remotely or in a hybrid format, using digital boards and the team's real work.
Tell us about your team
A short scoping call is the next step. You can also send a note about what the team is working on.