Plan an iteration - sounds pretty easy right? It can be easy using a well defined framework. This sessions will cover the following:

• Owner or facilitator of the meeting
• When to hold the meeting
• Whom to invite
• Materials - please note that this session is not tool specific other than Sharpies and Sticky Notes! But the plan can be input into your tool of choice.
• Purpose
• Agenda
• Planning Data - what to bring to the planning meeting
• Output & Deliverables - All contribute to the iteration planning meeting

A handout will be provided for future reference.

This tutorial, the “small card game”, is a simulation game introducing the concepts of Agile planning, story value, and story cost. Learn to manage scope and optimize return on investment. The students practice planning a project with varying levels of information about the features needed, and experience how “nature” deals with their plan. Again, very appropriate for all team members, in-house customers, marketing, and management, to learn how the process works and what their part in it is.

One of the core values expressed in the agile manifesto is “working software over comprehensive documentation” because working software is what delivers value to our customers. Agile development requires a sofware development team have working software ready to deploy at the end of each iteration; but accomplishing this can be harder than it seems, especially when first starting with agile. In this highly interactive session you will understand how a team definition of “Done” is necessary to making agile delivery possible, and what you can do to make it happen while avoiding the pitfalls.

Imagine yourself with a team that flies in from AU, the UK, and US in bi-weekly shifts to work with a telecommunications giant. Mix in inexperience, a shared resource model, bad behaviours, and a mandated intro to Agile in a silo-ed non-agile environment. Couple this with a capability driven / satellite team who’s focus is to assist other teams to drive out SOA: and you have a recipe for a Team in Flux. Working to find a system that worked for this team was a long and arduous journey full of misdirection, poor choices, and learning around structure, Agile methodologies, and people in general.

Scheduling should be done independent of and orthogonal to workflow. In fact, you don’t have to create a schedule for a flow system. It will flow all by itself, and work will flow much faster and much more reliably than it could possibly follow a schedule. But take a closer look at that workflow: Just when you thought it was obsolete, the V model reappears. This talk will step through systems design, approval processes, and scheduling, development workflow, depolyment, from a completely different angle.