Skip to content

Talks

(Click on this iconslides for slides or handout.)

In Seattle and Vancouver, slides for presentation on Technical Debt. in October 2011.

At  Agile New England in Waltham, Mass. on July 7, 2011, Agility and Architecture or: What colours is your backlog? .

At the CSEE&T conference in Honolulu on May 23rd, the Frog and Octopus.

At the Workshop on Architecture at RUG, in Groningen, Netherlands, on April 18th 2011, Games Architects Play.

At Agile Vancouver, on March 21st, On Technical Debt.

My “Sabbatical Year” Talks around the world:

For OOP 2010 attendees, here are the missing slides , for the afternoon “exercise”. (Germany)

Three presentations in Japanese, with many thanks to Taku Fujii:

Older presentations, and in English, mostly:

… where I revisit an older presentation, adding some elements about value, cost, technical debt, risk… Videos of the presentation are here.

  • Agile Vancouver on September 21, 2009 & Scrumtisch in slidesBerlin on June 17, 2009: What colours is your backlog?

… where I speak about backlog and time-box, about value versus cost, about visible features versus invisible features (and in particular software architecture), about defects and technical debt, and more generally about release planning and sprint planning for non-trivial and long-lived software development projects.

  • slidesUSC in LA, June 8, 2009: Software Architecture and Agile Software Development—An Oxymoron?

Can an architecture-centric process be also agile? Should an agile team focus on architecture? BUFD and YAGNI? More a matter of co-existence between two cultures.

  • Scrum Gathering, in Orlando, March 2009: What colours is your backlog? (see above; almost same slides)
  • slidesXP 2008 Keynote in Limerick, on June 14, 2008: Agility situated–Context does matters, a lot

… where I contend that most of the value of any software development practice depends on its context, and that Agility for an organization is not defined by simply embracing a labeled set of practices; nor even by a level of conformance to the agile manifesto. Agility should be defined relative to the value it brings to the business, namely the capacity of an organization to react and adapt faster than its environment can change. How agile an organization is, or can afford to be, will depend not on the practices alone, but on the context in which they are applied: how fit to that context are they. How do we define “context”? What elements or attributes of this context have a bearing on the selection of the set of practices an organization should adopt, and therefore how ‘agile’ it should strive to be? I’ll share some experience of applying agile practices far from their “sweet spot”, leading to the concept of situated agile processes. (see also this post)

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 34 other followers