<<< Previous speaker next speaker >>>

Dan North, Agile troublemaker, developer, originator of BDD

Dan North Dan writes software and coaches teams in agile and lean methods. He believes in putting people first and writing simple, pragmatic software. He believes that most problems that teams face are about communication, and all the others are too. This is why he puts so much emphasis on "getting the words right", and why he is so passionate about behaviour-driven development, communication and how people learn. He has been working in the IT industry since he graduated in 1991, and he occasionally blogs at dannorth.net.

Presentation: "Keeping Agile Agile"

Time: Wednesday 15:35 - 16:35

Location: Stanford Room

Abstract:
Adopting Agile often involves creating special process teams and hiring Methodology (with a big M) consultants to implement and enforce Agile Best Practices. Entire industries have grown up around accreditation, auditing, and support of specific Agile methods. So is this approach really helping you, or might it in fact be working against your organization?

Dan argues that best practices and are useful only up to a point, and that rigidly enforcing them is counter to the values of Agile and will eventually drive away your best people. He looks at the motivations behind Agile initiatives and introduces the Dreyfus model of skills acquisition to explore how effective best practices really are.

Presentation: "Introduction and Overview of Thursday's Tracks"

Time: Thursday 09:00 - 09:20

Location: Metropolitan Ballroom

Abstract: Floyd Marinescu and Thursday Track Hosts will present the program and provide a short introduction of the Tracks scheduled for Wednesday.

Presentation: "Deliberate Discovery: code like you mean it"

Time: Thursday 10:35 - 11:35

Location: Franciscan I & II

Abstract: Modern software delivery involves a top-down decomposition of a problem into packets of business and technical analysis, design, architecture, programming, testing, integration and deployment, as well as documentation and training. No matter how well-intentioned our approach to these activities, whether iterative or sequential, our success rate is still way below what it should be.  Dan thinks it's because we are focusing on the wrong things, which means any software delivery is a happy accident. In this talk, he explains why ignorance is the greatest enemy to success, and presents some strategies and techniques for deliberately reducing ignorance, increasing learning and moving towards a more deterministic and lower risk software delivery.

Training: "Secrets of Agile Architecture"

Time: Monday 09:00 - 16:00

Location: City Room

Abstract:

We architects love a good framework. We like our abstractions, we like to design "enterprise" solutions, we like to mandate complex algorithms, or better yet to prescribe toolkits to enable other teams to implement complex algorithms under our expert guidance. If it looks like a good idea we slap the label "pattern" on it and tell everyone to do it.

Ok, maybe that isn't you. But it's likely you work in an organisation where the other guys do. So what can you do about it? Is this the only way to do architecture?

This tutorial looks at strategies and techniques to incrementally architect your way out of a legacy mess, and to set up new applications for success.

During this one day tutorial you will learn, among other things:

  • the joys of a strong domain model, and how to evolve one.
  • how to use an anti-corruption layer as a border guard.
  • to get over your dependence on dependency injection frameworks.
  • not to have interfaces for everything.
  • that you can incrementally replace legacy apps more often than you realise.
  • how to successfully decouple subsystems.
  • the value of getting into production early.
  • not to fear integrating with third party libraries.
  • the courage to automate the things you should, the serenity to accept the things you can't and the wisdom to know the difference.
  • why "transfer object" is an oxymoron, and how to do remoting properly.

More importantly, you will learn to doubt what your experience is telling you, and instead to focus what's really there. Maybe.