Monday, November 1st, 2010 – Tutorials
Registersoon before the conference is sold out.
Full Day (09:00 – 16:00) Johanna Rothman If you have teams all over the world trying to create a product together, you know how difficult it is to create good products fast. You might get a good product, and it's slow to develop. You might get something fast, but it's not good. Agile, with its approach to frequent valuable-to-the-business deliverables looks like a good bet. And, if you already have geographically distributed teams, why can't you just say "Let's go agile" ? But it's difficult to make agile work on a geographically distributed project. We will first run a simulation, based on the way you manage your projects. We will work through the five levels of planning, through several iterations, and we'll even do a geographically distributed retrospective, time zone differences and all. We’ll debrief how the project proceeds and what you perceived worked well and what was not quite what you expected. We’ll also talk about how to get started and how to address the issues of corporate change. And, we will discuss what to do about those issues in your organization.
Half Day AM (09:00 – 12:00) Michael FeathersSoftware development is hard. It takes years to become a good developer and many more years to become an expert. How much of this time is necessary? Are there any shortcuts? In his book 'Blink', Malcom Gladwell makes the case that experts don't "think through" problems when solving them, they arrive at solutions almost unconsciously. The thing that differentiates an expert from a novice is not the ability to "reason through" but rather the ability to see a problem differently than a novice would. This different way of seeing is something that experts arrive at through their experience and long periods of exposure to problem contexts. In this session, Michael Feathers will work you through a set of examples and describe concrete strategies for cultivating design sense - the ability to instantaneously recognize appropriateness and inappropriateness in software design.
Half Day PM (13:00 – 16:00) Gerard Meszaros High quality automated tests are one of the key development practices that enable highly incremental development and delivery of software by reducing the number of bugs introduced into code as it is evolved. But writing lots of tests is not enough as the tests need to be maintained over the life of the software. This maintenance cost can quickly outweigh the benefits provided by the tests. This tutorial features several cases studies which introduce you to techniques for evaluating the quality of your test code (test “smells”) and improving it (test “patterns”.) The test smells will help you understand how maintainable your test code is and where future test maintenance costs may come from. The associated test patterns describe how to change your test code to avoid these maintenance costs. The smells and patterns described in this tutorial have been observed in tests ranging from technical unit tests to functional acceptance tests automated in a wide range of testing tools and frameworks. You should be able to start improving the ROI of your tests the day you go back to work.
Thursday, November 4th, 2010 – Tutorials
Full Day (09:00 – 16:00) Josh Kerievsky(1 day tutorial) (note from Josh: "We need to stress that this will be a 1-day, very fast-paced workshop, given so many topics. Ok?") Are you and your team able to work in such a way that your product is always ready to ship? Do you avoid spending long times with compilation errors, failing tests, broken builds, un-merged branches, large features and un-released code? In this hands-on, two day workshop, Joshua will share his team’s method for producing an “always shippable product.” You will learn techniques like:
- Visibility Strategies (making new/emerging features visible, partially visible or invisible to selected users)
- Thin Slicing (taking big things and breaking them down into small, shippable bits)
- Sufficient Design (when to sketch, craft and refine your work)
- Test-Driven Development (including patterns like Essence First, Frame First, Break-It-To-Make-It, etc.)
- Refactoring Strategies (including Narrowed Change, Parallel Change, Sequence Change, Gradual Change, etc.)
- Continuous Integration (including how to avoid difficult merges and un-merged branches)
- Continuous Deployment (including zero-down time, automated builds, monitoring and roll back).
Leading and Coaching People to Take Responsibility and Demonstrate Ownership – the Essence of Agility
Full Day (09:00 – 16:00) Christopher AveryField research about how personal responsibility works in the mind of leaders (i.e., how we avoid it and how we take it) now make it possible for coaches and leaders to understand and teach the mental processes, language, and keys to personal responsibility. Cool huh? Doing so inspires your charges to demonstrate far greater ownership behavior as individuals and in teams and enterprises. You add more value as your team or clients take ownership; practice self-leadership; and learn, correct, and improve more easily, directly, and quickly. This is a highly interactive and hands-on workshop. You will work directly with the Responsibility Process and the Keys to Responsibility. You will practice processes and exercises that Christopher and his Leadership Gift students apply with their teams and clients. OUTCOMES Come acquire the basic tools and practices for coaching success with personal responsibility. You will:
- Leave with tools, activities and exercises you can use on an ongoing basis to continually improve your ability to take and teach ownership behavior
- Understand and explain the connection between ownership behavior and success in any pursuit
- Understand and explain the essential role of ownership behavior (i.e., personal responsibility) in agile
- Understand and explain why and how people avoid ownership, and why and how people take it
- Understand why an agile coach would want to demonstrate, inspire, and teach ownership behavior
- Understand, try on, and validate your mind’s internal Responsibility Process
- Understand and practice the 3 Keys to Responsibility for unlocking and mastering the Responsibility Process
- Evaluate your return on investment as a coach to adopt a personal Responsibility Practice for mastering responsibility
- Evaluate and choose the basic tools to support your success practicing and teaching ownership behavior
- Learn the A, B, C’s of teaching responsibility to anyone — what is required, and where the pitfalls are.
- and maybe…Understand why giving advice seldom works (because it shifts the locus of ownership from advice-receiver to advice-giver)
See background material at www.ChristopherAvery.comAs an added treat Christopher will also describe the Leadership Gift Program for Leaders and provide an opportunity to consider membership. This innovative program and leadership community has proven powerful for leaders and coaches who desire a more productive and humane way to lead.
Full Day (09:00 – 16:00) Jeff PattonAgile processes off-the-shelf give us lots of guidance on how to deliver software, but not much on how to discover exactly what we should be delivering. Building great products springs from a balance of effective discovery and delivery practice. In this fast-paced one-day workshop you’ll learn the basics of planning and carrying out an effective product discovery phase. Jeff will describe how design thinking motivates the practices used in product discovery. You’ll learn ways to concisely describe why you’re creating the product, who the product will serve, and what the product solution might be. You’ll learn to write great user stories and organize them into a story map; then, how to slice your story map into holistic viable product releases. At the end of the workshop, you’ll have enough experience and information to plan and execute an effective product discovery phase for your next product release.
Half Day AM (09:00 – 12:00) Stefan Moser, Adam Dymitruk "A lot of overengineering has been justified in the name of flexibility. But more often than not, excessive layers of abstraction and indirection get in the way. Look at the design of software that really empowers the people who handle it; you will usually see something simple." -Eric Evans (Domain-Driven Design) While most would agree with this statement, no one sets out to over-engineer their software; they set out with the best intentions. The requirements for our models are many; they need to be expressive, readable, flexible and correct but these concepts are all fairly abstract and hard to nail down. So how do we build a software model that is everything that we want it to be? How do we avoid the bloat and unwanted complexity that so often plagues our models? In this session we will examine a set of patterns, from small tips through to cutting-edge architectural techniques, that will help you build a richer, simpler more expressive domain model. Slides - Chris Nicola