The original question that lead to this talk was asked by Marco
Klemm, initiator and moderator of Agile Nacht
Stuttgart. He asked
(paraphrased) “do Agile & Scrum really hold their promise of increasing
a project’s quality”?.

In this short talk I present my personal opinion and the experience of my last
years as CTO of
vaamo
argue, that while it’s possible to employ practices such as Agile, Scrum
& Software Craftsmanship to increase the quality of software projects (for
varying degrees of quality), the actually important factors and the biggest
leverage to increase quality and success of projects, are the involved humans
and their way of interacting with each other.

Practices, (Management) Frameworks and opinions on how software should be built
are as numerous as there are people on this planet.

A group of such opinions dubs itself Software Craftsmanship and calls for seeing
a software development more as a craft instead of an engineering discipline.

I count myself among the Software Craftsmanship community since 2011. Since then
I’ve been supporting and spreading the ideas of Software Craftsmanship. Be it by
organizing user groups and conferences, by giving talks or via the continuous
efforts incorporating Software Craftsmanship ideas and practices into my daily
work as developer and manager.

In this talk I’ll look back over the last five years, the journey I’ve made as a
software developer and developer of teams. I’ll share how my view on how to do
software development better changed over this time.

In this talk I argue, that the information technology and especially the
software development industry enjoys to talk about their technology stacks and
programming languages a lot, and we attribute a lot of our success to these
technologies, we’re really doing it wrong. And while we often pride ourselves in
using “the best tool for the job”, I argue in this talk that the tool actually
plays only a minor role in the success of our products and projects.

Other factors, primarily the way we interact, treat each other and the
principles that form the basis of our interactions and work are far more
important to making our products successful.

The talk first covers how we made our technology
choice in favor
of Scala. It continues to take a look at the wanted and unwanted consequences of
this choice and closes with my thoughts on how, if at all, it enabled the team
to deliver innovation and value to our business.

As the title may suggest, the talk was about Software Craftsmanship and what it
has to do with Agile in general. The outcome is more or less something like “you
need Software Craftsmanship, whether or not you want it and some of the things
you already do are very likely Software Craftsmanship-related”.
There was a lot of head-nodding from the audience, so I guess, they understood
what I was talking about

The slides
are pretty visual, though the (german) notes are very extensive.

Architectural Katas

The format was created initially by Ted Neward in
response to the lack of practical exercises for software architects. Small
groups solve a given project together (which is similar to a very simple RFP -
Request for Proposal) in a short amount of time and present it to the other
groups afterwards to “defend” it.

Participants of both sessions were very surprised how hard it is to come up
with a meaningful (or even good) architecture in a short amount of time, and
even more so to convey it to other groups. They also acknowledged the usefulness
to practice this kind of architecting in addition to the usual coding
practices.

As far as I know, it was the first Architectural Kata held in germany.