Greater Wisconsin Software Symposium
Feb 27 - Mar 1, 2009 - Milwaukee, WI
David teaches and coaches the adoption and improvement of agility as a delivery tool. His work includes helping companies of all sizes all over the world. Sometimes he is pairing with developers and testers, while other times he is helping to invent, evolve and plan the delivery of all types of products and projects. David also spends a great deal of time helping leaders at all levels find ways to pragmatically use agility to foster innovation.
Prior to working as a full time coach, David spent years building software in a variety of domains: digital audio, digital biometrics, medical, financial, retail, and education to name a few. David now leads DevJam, a company composed of agile collaborators. As mentors and practitioners, DevJam focuses on agility as a tool to help people and companies improve their software production skills. DevJam provides seasoned leaders that strive to pragmatically match technology, people, and processes to create better and cooler products in competitive cycles.
Along with teaching and coaching, David participates in conferences around the world. He is the recipient of the Agile Alliance, 2009 Gordon Pask Award. David continuously contributes to books and various publications.
For coaching information, presentations, and more, visit www.devjam.com
If you are truly working to get value from agile methods, and you have been doing it for some time, you probably have some questions which go beyond "my first agile project". If you are looking for a place to get answers or hear where and how others are struggling, come to this session ready to ask your tough questions. I have coached many communities (of all shapes and sizes) adopt, adapt, and evolve agility beyond the first project or the first few months, and I am sure there will be no shortage of examples and experiences for you questions. Also, I am sure you will learn from others in the audience as well.
Going beyond big A Agile, we will start with some the common questions I see people facing who have long running or large scale agile projects. From there, we will prioritize the questions from the audience and take them one at a time. Any questions which go unanswered will be fodder for the agile BOF (if it follows the session).
People ask me all the time, "How do you get people to buy in the use of agile methods?" While this is easier than it once was, there are still many challenges, and agile snake oil sales are on the rise. If you are looking to sell agility or deeper your agile investment (or your sales force), this session will provide you with tools that will help you frame your sell points, select your sales tools and communicate the value (of a practice) over the mechanics.
This session will start out showing how agility sells (or does not) and where the sales have added value or simply added noise. From there, we will talk about the value of various practices as we re-frame them into valuable items which sell. Lastly, we will finish up talking about how to sell each of these to the various buyers within organizations: managers, directors, tech leads, developers, business partners and more.
Being agile does not mean living life one iteration at a time. Agile projects without a long view can run into the common design problems of the past. Planning iteration by iteration is often foolish and feeds the myth that agile projects do not think beyond a few weeks. Successful agile projects plan within iterations and across iterations. The later planning is called release planning and it is the forum where agility first engages architecture and other cross cutting concerns.
Architects who think that agile projects evolve code one test at a time are only partially correct. Agile projects review and evolve architecture with unit tests, acceptance tests, architectural spikes, and continuous review of the system's ability to adapt and respond.
There is a home for architects and architecture on agile projects, and other traditional roles, but the there are some new variations. This session will talk about the relationship of agile methods and architecture and design and how they can work together to make stronger products and systems. The session will draw on information and anecdotes will come from projects of all sizes within companies of all sizes, including some large and complex systems.
Whether it was intentional or not, the agile community has been borrowing successful ideas from the lean manufacturing for years. Lean practices, like finding and removing wasteful work, can be applied without needing special permission or certification. Ideas like kanban (visual planning aids) and kaizen (continuous learning) are simple, helpful tools that are easily applied and produce great results.
This session will discuss how lean thinking has influenced agile methods and how you can use simple lean ideas to produce better software more often. We will not get stuck on wasteful discussions about "what is Scrum?" or "what is agile?" Instead we will talk about (and try - time permitting) a collection of useful lean practices and tools.