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

No matter how large and successful a company is today, it's long term survival is by no means guaranteed. Only a few large companies have been able to sustain growth over time by coming up with a steady stream of new disruptive businesses. How do they do it? Innovative companies create a climate in which cross functional teams conduct rapid, inexpensive experiments directly with customers. They foster the five innovation skills described in Clayton Christensen's book: The Innovator’s DNA - Observing, Questioning, Associating, Networking, and Experimenting. This Workshop is about using continuous feedback to speed up learning and radically improve the process of developing of software-intensive systems. It covers: 1. Continuous Delivery 2. Continuous Design 3. Continuous Experimentation 4. Continuous Progress Participants will explore questions such as: 1. Do our value streams bring together into a single network all of the capabilities necessary to create and deliver a compelling offer to customers? 2. Do team members understand who their customers are and why these customers will choose our product above all alternatives? 3. Does value flow from idea to delivery on a continuous basis and in a disciplined manner that delivers unassailable quality? 4. Are features validated against real customer behavior and modified based on whole system feedback? 5. Does everyone constantly challenge the status-quo and experiment with alternate ways of delivering even more compelling value to customers?
http://submit2012.agilealliance.org/files/session_pdfs/Innovation.pdf

Get ready for a challenge as Robert Martin dives deep into the topic of clean Java code by examining what makes a good function. In this talk you will look at a lot of code; some good and some bad. You will experience how such code is analyzed, critiqued, and eventually refactored. You will understand the decisions made by an expert in the field as bad code is gradually transformed into good code. How big should a function be? How should it be named? How should it be documented. How many indent levels should it have? How should it deal with exceptions, arguments, and return values. This talk is all about code at the lowest level. And yet the principles and techniques presented have far reaching implications.

This talk will either be a resounding success or a flop. But hey, what’s the point of mediocrity? We will explore excellence. What it is, how one achieves it, and how one exceeds it. What determines the outer limits of your team’s capability? How can you be continually more awesome? We’ve each got a decade of transitioning to (Jim), being on (Arlo), and building (both) awesome Agile teams. We aim to distill that down to an essence that you can inhale in 90 minutes, yet still apply directly as soon as you get home.

My team takes a lot of time to write user stories in a standard format, what else can we do to develop a good backlog? Aren’t user stories just slimmed down use cases? How does the team start work if you don’t do requirements gathering? What alternatives have you seen to having a product owner/customer proxy on the team? What are the characteristics of a good product manager?

The continuing knock on XP, Scrum and Kanban is that they may work well for small, collocated teams, but they do not scale to the needs of the larger software enterprise. In this presentation, Dean Leffingwell will finally dispel this myth by describing the Scaled Agile Framework™, a well-defined and publicly available set of practices which have been used to successfully scale Lean|Agile development to hundreds—and even thousands—of practitioners at companies like BMC Corporation, John Deere and many others. Results typically include quality and productivity improvements of from 20-50%, along with increases in employee engagement and job satisfaction. In this presentation, Leffingwell will describe how the three key Agile constructs — team, backlog and timebox— can be scaled to the program and portfolio levels of the enterprise. However, since simply making Agile things bigger does not necessarily keep a system lean, Leffingwell will describe how the framework a) keeps work in process visible and limited, b) keeps backlogs and queues short, c) uses cadence and synchronization to align teams to a common mission, and d) applies system-level continuous integration to facilitate fast customer feedback. The presentation also includes a description of kanban systems to manage the flow of the business and architectural epics that drive the agile programs. The presentation concludes with a discussion of how lean thinking executives are instrumental in helping the enterprise achieve the ultimate business benefits that these innovate processes can deliver.
http://submit2012.agilealliance.org/files/session_pdfs/Agile2012 rev4.pptx.pdf

Agile methods depend on effective cross-functional teams. We’ve heard many Agile success stories…at the team level. But what happens when a product can’t be delivered by one team? What do you do when the “team” that’s needed to work on a particular product is 20 people? Or 20 teams? One response is to create a coordinating role, decompose work, or add layers of hierarchy. Those solutions introduce overhead and often slow down decision making. There are other options to link teams, and ensure communication and integration across many teams. There are no simple answers. But there are design principles for defining workable arrangements when the product is bigger than a handful of agile teams. In this talk, I'll cover principles and practices and explain how they work together to address coordination, integration, and technical integrity. These are the principles and practices I'll illustrate. 6 Principles: Manage dependencies in the backlog as much as possible
Aim for long-lived cross-functional teams
Go as far down the technology stack as feasible
Organize teams around context boundaries rather than component boundaries were ever possible
Make cross-context communication explicit
Avoid late learning Technical Practices: Continuous integration (CI) within context
Integration across contexts at some other interval (keeping in mind “avoid late learning”)
Mutually agreed upon and developed automated test across context boundaries
Architectural & coding standards
Technical reviews Social Practices: Scrum of Scrums
Integrating Teams (keeping in mind “avoid late learning”)
Decision Boundaries
Component shepherds
Tech council
Product council
I've attached a PDF of the current version of my slides on this topic. I'm sure they will evolve by next August.
http://submit2012.agilealliance.org/files/session_pdfs/ScalingAgileTeamsDerby2012.pdf

This is your opportunity to meet with, hear from, and ask questions of the Agile 2012 Program Chairs: Michele Sliger, Peter Provost and Pete Behrens along with the Agile 2012 Conference Chair Mitch Lacey. The program chairs, under the guidance of the Agile 2012 Conference Chair, spent almost a full year building the Agile 2012 program from defining the stages and the program schedule, seeding the stage review teams, developing the submission schedule, overseeing the submission process, aligning the stages and sessions to the conference facilities, and pulling together the final program. We would like an opportunity to share our approach in building the program and hear your feedback on your experience through that review process and the results of the program. This session is for you if any of the following apply: 1. You would like to know more about how the program and stage review process works and how submissions were selected for Agile 2012 2. You are interested in getting more involved in the program or stage review process in the future 3. You would like to meet with and/or get to know better those involved in putting together the Agile 2012 Program Added something else

A wise Greek coach said “We have two ears and one mouth so we listen twice as much as we speak. Sadly, many coaches fail to listen before starting to train people around “how to do agile.” This session will challenge you to pragmatically map context (people, product, technologies) to a subset of agile practices and principles. Going beyond simply teaching process we will create outcome based coaching plans that introduce tools that augment existing strengths and address contextual challenges.
http://submit2012.agilealliance.org/files/session_pdfs/CoachingIsMoreThanTelling.pdf

The annual Agile Alliance Member's Meeting will be held at the Agile2012 conference. Members are invited to meet, hear about, and discuss Alliance business with the Agile Alliance board of directors.

Drinks and snacks will be served.

 

There is a lot of confusion about what Kanban is. Some of this is due to the fact that many people who have never used Kanban have been deriding it – saying it is a mechanistic team management method that doesn’t respect people. The fact that Kanban is quickly growing and gaining a reputation for success where other Agile methods have had challenges belies that categorization. But what is Kanban? Even when listening to Kanban thought leaders one will hear different answers. 1) it’s a power agile management system based on lean-flow. 2) it’s a transition management method to assist teams to achieve continuous learning. 3) It’s a way to create visibility for executives to improve their product portfolio management. I can almost here Gilda Radner and Dan Aykroyd on Saturday Night Live describing New Shimmer! This talk discusses how Kanban actually is a multi-faceted method that assists process, transition and collaboration. Kanban is not a mere tool, or even a set of practices. It’s a mindset that attends to people, their culture, and the systems they find themselves working in. The talk presents a few of the basics of Lean-Flow and theory of constraints that it is based on as well as some of the psychological aspects of people adopting new methods. While this talk is intended for those considering adopting Kanban, those currently using Scrum will find it helpful as many of the principles and practices of Kanban fit well into the Scrum framework.
http://submit2012.agilealliance.org/files/session_pdfs/IntroToKanban_Agile2012.pdf

The vast majority of software developers have yet to learn the practices and disciplines that constitute professional behavior. That's because those practices have only just recently been defined. The software industry is barely fifty years old. It has taken nearly that long to figure out what software professionalism is. It is only in the last few years that a set of generally accepted software practices have been defined. But now they are here, and it's time for management to demand that professional behavior. In this talk, Robert C. Martin will describe these disciplines, and practices, and will discuss how to raise the professionalism bar in your projects and teams.

We know that we can only manage what we can measure – but how do we measure productivity, predictability, quality and value delivery of our agile projects and initiative? This interactive session was inspired by the response to Jim’s blog by the same title that drew over 8,000 hits in 4 days and will explore how we should (and shouldn’t) measure the success of agile projects and initiatives. As agile practices have spread widely during the last decade we still struggle with measuring progress in the same ways we did with traditional projects. Is velocity just another productivity measure that we shouldn’t be using? How is it helpful? What else should we measure – and how do we effectively measure value or cycle time? Jim Highsmith and Pat Reed will facilitate an exploration of these questions from both conceptual and very practical perspectives.

"Self-organizing team" may be the most over-used, mis-understood, vague, and mis-leading term of the decade. So what is a self-organizing team? How are self-organizing teams different from other teams? How can managers and team members get the self-organizing mojo going? What are the challenges that self-organizing teams face? In this workshop, we'll explore all these questions and get beyond the buzzword.
http://submit2012.agilealliance.org/files/session_pdfs/SOAgileTeamsDerby2012.pdf