Agile2012

Learn Agile and have fun at the same time! Everything you learn will be via real Agile activities that you do as a team. You’ll form into cross-functional teams, invent your own software product to use as an example for the activites, and become completely immersed in the principles and practices of Agile. There's no actual coding, no computer required, it's just fun activities that anybody can do that show you what being on an Agile team is really like. For anybody involved in development: management, product managers, business analysts, designers, developers, testers, DBAs, technical writers, project managers, etc. Bring an existing team or create a team with other participants during the session. Activities include: * Forming cross-functional, dedicated, co-located teams * Writing actual user stories for your team's "product" * Creating a backlog * Splitting stories * Estimating the stories using planning poker * Planning a release using two iterations of work * Running an Agile implementation simulation * Doing a retrospective on the simulation Throughout the session, you will also have the experience of seeing a demonstration of self-organization on a large scale.
http://submit2012.agilealliance.org/files/session_pdfs/HandsOnAgile2012Shared.pdf

If you’ve been doing Waterfall delivery most of your career agile can be down right scary: changing requirements, adaptive planning, iterative development. These are all intimidating things for managers and organizations used to doing things in discrete phases one stage at a time. In this introductory talk, we will look at agile in simple terms explaining: * what agile is * what working on an agile project is like * some of it’s myths * which agile method is right for you, and * three steps you can take to becoming more agile today.

If you are new to Agile and attempting to transform your organization, it’s easy to get lost in the details of recommended practices and ceremonies. Too many groups try so hard to exactly follow the descriptions "by the book" that they miss the benefits of those practices. They overlook the very reason the practices exist. It’s more important to be effective than to attempt a large number of suggested practices. George Dinwiddie will highlight one way to judge the effectiveness of your practices in a manner that guides you in improving them.
http://submit2012.agilealliance.org/files/session_pdfs/Baby Steps and Pervasive Feedback-Agile2012.pdf

The Kanban Pizza Game is a unique experience of the benefits of one-piece flow or limiting your work-in-process. You are the proprietor of a new entrepreneurial enterprise, your very own Pizza Shop. You will experience the frenetic energy required to keep up with your customers' needs before using the three simple prescriptions of Kanban to increase your productivity and even offer your customers more choice. You'll experience some subtleties of the Kanban approach before we tie everything back to how software is delivered using Kanban. -- The Kanban Pizza game was created in the summer of 2011, and has been used at Tampere Goes Agile 2011 in Finland and the Agile Coach Camp in Columbus, OH in Sept 2011. Feedback was enthusiastic, and the game has been used numerous times with clients in the passed 6 months to very positive feedback. The benefit of this game over other Kanban experiences is the level of complexity that can be introduced through the variations of pizza slices (for example, incorporating subtle changes in flow through the system). Some feedback from the Tampere exercise can be seen on the [agile42 blog](http://www.agile42.com/en/blog/2011/09/23/kanban-pizza-game/ "Kanban Pizza Game"). Kanban is a tool that allows optimization of a process by visualizing it. Kanban has just three main prescriptions: 1 Visualize the workflow 2 Limit WIP 3 Measure and optimize the average lead time **Visualize the workflow** With the physical production of the Pizza the workflow is always visually present, and with the drawing of the workflow we can reflect the current process. **Limit WIP** Through the game some bottlenecks and queues will emerge. During the game we introduce work-in-process limits to highlight the (often counter-intuitive) benefit of focusing on single piece flow, and so that the teams don't lose points for unused materials. The participants experience that WIP limits are more than just imposed limitations - they change behaviour; people interact more on the overall production, communicate more and help each other when needed. **Measure and optimize the average lead time** In the game we measure the lead time and the cycle time. We also use a point system to approximate value delivery, and in particular the cost of inventory or waste. **Some Benefits of Kanban** - Bottlenecks become clearly visible, leading to increased collaboration - Evolutionary path to agile software development - Provides a way to be agile without iterations, starting where you are - Natural tendency to spread throughout an organization

Businesses rely on rapidly getting valuable new software into the hands of users, while keeping production stable. Continuous Delivery is a revolutionary and scalable agile methodology that enables any team to achieve rapid, reliable releases through better collaboration between everyone involved in delivery, and automation of the build, deploy, test and release process. I’ll present the principles and practices of continuous delivery, including the deployment pipeline, acceptance test driven development, devops, and techniques for low risk releases.
http://submit2012.agilealliance.org/files/session_pdfs/continuous_delivery_agile_2012.pdf

The definition of done is a fairly popular (and sometimes emotional) topic in the Agileverse. It seems everyone has an opinion on the matter ranging from “It depends,” to “Let the teams decide,” to a meticulously designed set of business rules and criteria that account for every possible scenario. However, as organizations adopt Agile practices (and specifically, Scrum), they seek to leverage guidance from those of us who have already blazed the trail. Why then is this such a complex topic? This session will discuss what the "Definition of Done" means to different stakeholders across the organization at the User Story, Sprint, Release, Product, and Program Level. The session is based on a series of articles that I have published on this topic. Also, I have presented various versions of this session for my clients and will be doing a dry-run of the actual Agile 2012 format for one of our Wilmington ALN meetings this Spring.
http://submit2012.agilealliance.org/files/session_pdfs/What's Done is Done - 081412 0800.pptx.pdf

User stories are used to describe the functionality delivered in a product or system. Two common challenges we see recurring, even with experienced teams, are (1) they spend far too much time planning and estimating, getting trapped in the details, and (2) they have difficulty finishing user stories in a time-boxed iteration or Sprint – often realizing, despite the promise of further conversation, that they just didn’t know enough about the user story before taking it on. This hands-on session introduces participants to two techniques to deal with these problems. The first is Silent Grouping, which allows teams to collaboratively size even very large backlogs in minutes. The second is Definition of Ready, which is a set of agreements that lets everyone know when a user story is ready to begin. Combined, these techniques can save your teams literally hundreds of hours in time.
http://submit2012.agilealliance.org/files/session_pdfs/Agile 2012 Working Effectively With User Stories.pdf