This posting about means of communication, accuracy, and aesthetics, appears in german language only due to german language references. International readers, I apologize.

Kommunikationsmittel

Die Sprache, die Schrift, eine technische Zeichnung oder ein Blatt Noten sind »Kommunikationsmittel[…], mit deren Hilfe sich Menschen untereinander verständigen können.«. Ein Architekt vermittelt mit einer Zeichnung anderen, wie das geplante Gebäude aussehen soll, während ein Komponist durch Noten ausdrückt, welches Musikstück sich in seiner Vorstellung entwickelt hat. Damit das Ganze funktioniert, bedarf es einer Konvention – beide müssen “die gleiche Sprache” sprechen.

Interpretationsspielräume in der Kommunikation

Trotz der Konvention gibt es Interpretationsspielräume durch Unschärfen im Kommunikationsmedium. Ein Notenblatt beispielsweise kann weder Tonhöhen noch Rhythmus beliebig fein auflösen. Kommunikation enthält außerdem auch unbewusste Komponenten, die vom Empfänger in seiner Vorstellung in einen entsprechenden Kontext gesetzt werden. Speziell in der schriftlichen Kommunikation kann man zudem gelegentlich feststellen, dass der eine sich präziser artikulieren kann und dabei auch Wert auf ästhetische Gesichtspunkte legt, während der andere wesentlich pragmatischer zu Werke geht. Wer ein Bild malt wird bezüglich der Ästhetik andere Maßstäbe anlegen als jemand, der eine Einkaufsliste verfasst.

Was aber hat das mit agiler Softwareentwicklung zu tun?!?

Code ist ein Kommunikationsmittel

Wie eine technische Zeichnung ist ein Stück Code in der Softwareentwicklung auch die Repräsentation der Gedanken desjenigen, der ein bestimmtes Problem lösen möchte. Mit dem Code, den er schreibt, teilt er nicht nur der Maschine, sondern auch seiner Nachwelt mit, was er dabei erreichen wollte – der Code ist also ein Kommunikationsmittel. Die Wahrscheinlichkeit, dass später entweder der Autor selbst oder ein anderer Fehler beheben, Verbesserungen oder gar neue Funktionalität hinzufügen möchte, ist groß. Sofern der Code bestimmten Konventionen folgt, präzise formuliert und gut strukturiert ist, wird es in einem halben Jahr deutlich einfacher sein, die dann anstehenden Änderungen vorzunehmen.

Wer agile Softwareentwicklung als Profession betreibt wird vielleicht sogar auf testgetriebene Entwicklung setzen, in der die Tests zum Ausdruck bringen, welches Bild der Programmierer beim Schreiben des Codes im Kopf hatte.

Der Softwarearchäologe

Boris Gloger hat vorgestern in seinem Posting Agile Architektur ist änderbar! das Problem beschrieben und ein paar nette Metaphern genutzt. Das Verstehen und effiziente Ändern von Code, den man nicht selbst geschrieben hat, ist für alle Mitglieder eines ScrumTeams ein wichtiger Baustein zum Erfolg.

Boris schreibt:

Lesbarkeit: Der Code sollte so strukturiert und geschrieben sein, dass er leicht verständlich und lesbar ist.

Eigentlich sollte das eine Selbstverständlichkeit sein. Allerdings erfordert das Disziplin. Es ist einfach, Code zu schreiben, der etwas Nützliches tut. Es ist aber aufwändiger ihn so zu schreiben, dass die Gedankengänge auch später noch nachvollziehbar sind – sei es für den Autoren selbst oder für andere. Und nicht zuletzt spart lesbarer Code, der in »Usable Software« mündet, eine Menge Dokumentationsarbeit ein.

Doch halt – was ist mit Kommentaren? Boris schreibt weiter:

Inline-Dokumentation der Entscheidungen: Es sollte im Code erklärt sein, warum gewisse Entscheidungen so getroffen wurden, wie sie getroffen wurden. Der Code selbst ist ja die Dokumentation dessen, was der Code macht. Nur wieso man die Dinge so angegangen ist, wie sie vorliegen, wäre wichtig zu wissen.

Kommentare sollten nur dort zum Einsatz kommen, wo der Code nicht mehr selbsterklärend geschrieben werden kann. Beispielsweise weil man um eine Unzulänglichkeit des Betriebssystemes (»Was macht er denn da?!?«) herumkommen musste.

Kommentare wie

// Traversing the list
for ( int i = 0; i < lst.size(); i++ )

oder

// Checking whether we can open the file
if ( !f.open() )

sollten gelöscht, dafür die Bezeichner etwas sprechender gewählt werden.

Vor ein paar Tagen habe ich eine Codestelle geändert. Gestern bemerkte ich, dass ich vergessen hatte, den darüberstehenden Kommentar zu ändern. Den Bug habe ich gefixt. Indem ich den Code so umgeschrieben habe, dass der Kommentar überflüssig wurde.

Interlude

Goke hält mit ausgestreckten Armen ein iPad so vor sich, dass er die Noten gut lesen kann. Mit spitzen Lippen pfeift er die Melodie. Nach wenigen Sekunden stimmt Peek mit ein.

Schlussfolgerung

Jedes Mitglied eines ScrumTeams, das vom Erfolgsfaktor der kollektiven Codeverantwortlichkeit in der agilen Softwareentwicklung überzeugt ist, wird darauf drängen, dass der Code als Kommunikationsmittel lesbar geschrieben wird. Jeder kann damit aus dem Stand gleich morgen anfangen. Wichtig ist nämlich nicht das Wollen, sondern das Tun in kleinen Schritten.

Wenn sich später noch die Lektüre von Büchern wie Agile Developer Skills (ISBN 3868020608) von Christoph Mathis und Andreas Wintersteiger oder Clean Code (ISBN 3826655486) von Robert C. Martin anschließt - umso besser.

Overview

Though we introduced two physical boards for managing the product and the sprint backlogs, I’m still searching for a method to organize their items in a manner that fits our needs best. There are two books sitting on my couch which I hope to read during the Xmas break. Both are written by Mike Cohn and seem to be standard works for agile addicts (and even recommended by Ken Schwaber).

User Stories Applied

Here’s just a short citation of its¹ back cover:

Thoroughly reviewed and eagerly anticipated by the agile community, User Stories Applied offers a requirements process that saves time, eliminates rework, and leads directly to better software.

Of course the book is not only about user stories, but also about all of the adjacent topics.

Agile Estimating and Planning

Again a short citation of its² back cover:

Using the techniques in Agile Estimating and Planning, you can stay agile from start to finish, saving time, conserving resources, and accomplishing more.

Again, this book is about management of agile software projects in common and not only about estimating and planning. I hope to learn a lot by reading them.

¹ Mike Cohn, »User Stories Applied« 2004, ISBN 0-321-20568-5

² Mike Cohn, »Agile Estimating and Planning« 2006, ISBN 0-13-147941-5

Today the local Scrum User Group met at the usual location. Thomas Spielhofer came from Vienna to gather feedback concerning the study »Successful agile leadership« (German Tongue PDF). Subsequently we discussed the points presented by Thomas.

I’ll not post more details as it’s late already and other things on today’s to-do-list are still open. In case you are living nearby, feel free to visit the next meeting in two months.

The first portable synthesizer, the Minimoog

The Scrum Guide 2011 states:

The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current Definition of “Done.”

and

This Increment is useable, so a Product Owner may choose to immediately release it.

Using Scrum, we intend to create a »potentially releasable« and »useable« piece of product increment which is completely »Done« during each sprint, which means there’s nothing left to do. For example, the software behaves performant under real usage conditions and the end user documentation is written completely.

The Definition of Done is a kind of contract between the Product Development Team and the Product Owner. Together with a Product Backlog Item, it defines whether a product increment is »done«. Only »Done« product increments will be accepted by the Product Owner, otherwise the increment will be rejected.

My team currently struggles with performance issues which need to be addressed prior to releasing the product. The issue exists for quite some while now. It happened since performance was not listed in the Definition of Done yet and the team did only test with a small amount of data. Additionally the Definition of Done was neither respected on a regular basis nor was it maintained or emergent. Now it triggers stress, as improving the performance requires heavy changes under the hood while the planned release date is approaching.

During the last retrospective I grabbed the occasion to point out that the Definition of Done is a major key to success and that we need to learn how to cope with it properly. Unfortunately my team mates still did not understand the sense and purpose of the document. Is it their fault? No. It’s mine as their coach. I’ll try to communicate it once again tomorrow.

Before gaining the Professional Scrum Master I certification two days ago, I gained the Certified Scrum Product Owner certificate after a training with Roman Pichler in february. I’m currently listed as CSPO at scrumalliance.org.

Overview

Four weeks ago, I wrote about trainings, classes, and certificates. Meanwhile I attended a PSM training with Ken Schwaber.

Assessment

Part of the contract was one free attempt of scrum.org’s Professional Scrum Master I Assessment, which I successfully passed yesterday. It consists of 80 multiple choice questions, and the timebox is 60 minutes. To gain the certificate, the rate of correctly answered questions must be better than 85%. IMO you won’t pass the test in case you do not really share an agile mindset, which is required to answer some of the questions. In case you got interested, there’s the Scrum Open Assessment which asks 30 questions in 60 minutes (which I finished in 17 minutes).

Certificate

While writing this posting, scrum.org sent me the logo (see above), the certificate, and put my name on the stack. For me, two years after I introduced Scrum at my current employer’s, it’s just one minor step while learning more about product management, project management, agile software development (including Scrum, of course), and adjacent topics.

Inspect and Adapt

So what’s next? The more I learn, the more I want to learn even more. The next stack of books already is sitting on my couch, and I really enjoy the journey to grow my agile capabilities. The future will prove whether I will find opportunities to make good use of them.

During this year’s ScrumDay, sipgate searched for talents by distributing this flyer:

Content Translation

As it is written in german tongue, here’s a brief abstract of its content:

• Five Scrum Teams are responsible for the products.
• Team members are visiting trainings and conventions frequently.
• Attractive office.
• Extra office hours are avoided.
• Thirty days of vacation are granted.
• Employments are long-term contracts.
• No pressure by investors or banks.
• Team building is not limited to office hours. It is continued during parties, BBQs, and even breakfast.
• Bleeding edge products are developed with joy and passion.
• sipgate is a successful and growing company.

High Performance

The goal of agile product development environments is to set up »high performance«² teams. To achieve this in order to develop »products that customers love«³, you need to hire outstanding people, who will joyfully give the very best they can.

The flyer states that sipgate does not only talk about agile product development, but that they are applying it day by day. Its back provides a checklist for meeting invitations:

Freely translated, the statement below the list reads as follows:

At sipgate this list is used for two reasons:

• It requires to plan any meeting so it gets clear whether the meeting is necessary.
• The invitees can verify whether it makes sense to attend the meeting.

Conclusion

The reader gets the impression that sipgate does not only talk about agile, but is actually doing it all day, so that chances are given they will attract the “right” people. IMO it is a great example of recruitment of an agile company.

Thanksgiving

I’d like to thank sipgate for providing the flyer in PDF format and for the permission to use it for this posting.

¹ Boris Gloger, André Häusling »Erfolgreich mit Scrum – Einflussfaktor Personalmanagement« 2011, ISBN 978-3-446-42515-6, chapter 3.1

² Lyssa Adkins, »Coaching Agile Teams« 2010, ISBN-13 978-0-321-63770-3, chapter 2

³ Roman Pichler, »Agile Product Management with Scrum – Creating Products that Customers Love« 2010, ISBN-13 978-0-321-60578-8

The Scrumday conference 2011 (which was sold out) is past. The focus of yesterday was on workshops (I enjoyed »Value driven product development framework with Scrum« by Jürgen Margetich, bor!sgloger Consulting GmbH) and community building. Today started with keynotes of Thomas Kiessling (Deutsche Telekom) and Ken Schwaber (»How to sell Scrum in your organisation«) and continued with traditional talks. The last one was done by Boris Gloger and André Häusling built ’round their new book »Erfolgreich mit Scrum – Einflussfaktor Personalmanagement«, a topic rarely covered yet (I hope the book will appear in english language also). A further talk I enjoyed was »Agile Developer Skills« by Christoph Mathis, also built around a book².

As always, it was a great chance to learn things from practitioners which you cannot learn from books. This was a worthwhile event for the Scrum addict I am :) .

¹ Boris Gloger, André Häusling »Erfolgreich mit Scrum – Einflussfaktor Personalmanagement« 2011, ISBN 978-3-446-42515-6, pages 81 through 85

2 Christoph Mathis, Andreas Wintersteiger »Agile Developer Skills«

Janus, Vatican, via Wikipedia, public domain

Ken Schwaber continued his excellent training on Friday.

Training Style

The key ingredients of his style are:

• Story Telling – an important technique, and I recommend this posting of Garr Reynolds (found via Boris Gloger, who also mentions the importance of story telling in his book¹).
• Teaching as a one-man-front-show. By keeping those phases short, chances are given that the students actually listen and learn.
• Team exercises that create insight. Those were always timeboxed, and a great chance to improve your skills as a team player.
• Joking to aerate the presentation. Ken is really a master in making use of various incidents for joking, may it be something an attendee just said or a rescue van passing by.

Topics

Topics of this day included the definition of done (there’s exactly nothing left to do), legacy code and the exponential growth of technical debt (which is capable of killing your company), teambuilding, emergent architectures and selling Scrum to managers respectively customers.

Using a squirrel story in the morning and an obviously simple contract exercise a couple of hours later, Ken teached us that it is damn hard to get rid of traditional habits (see the Janus picture at the top of this posting). He also mentioned how simple it is to introduce and how difficult it is to do Scrum.

Fuzziness

Once more I noticed that different trainers and authors teach things differently. While Boris Gloger¹ describes six roles, Ken Schwaber still uses the formula »Scrum Team = Development Team + Scrum Master + Product Owner«.

According to Ken, the Product Owner, as a member of the Scrum Team, should attend the restrospective meetings, a topic also mentioned by Roman Pichler². AFAIR I read contrary statements in other books, and Victor Szalvay writes:

The product owner does not attend this meeting.

As Scrum is a framework, not a religion, such differences do not really matter. It is much more important to internalize what Scrum is all about.

Conclusion

Two intense but worthwhile days are over. It is always a great joy and pleasure to work with people you just met, and Ken’s training style was acknowledge being excellent by the attendees.

¹ Boris Gloger, »Scrum – Produkte zuverlässig und schnell entwickeln« 2011, ISBN 978-3-446-42524-8, page 181

2 Roman Pichler, »Agile Product Management with Scrum – Creating Products that Customers Love« 2010, ISBN-13 978-0-321-60578-8, page 104

Weibliche Ente von Petr Kratochvil

As already outlined in one of the previous postings, certifications do not necessarily tell you anything about the knowledge, skills, or competences of the owner. On the other hand, certificates are usually seen as an evidence in someone’s Curriculum Vitae that she has a certain degree of maturity on the mentioned matter.

After introducing Scrum successfully for my current employer about 20 months ago, the experience I gained since then, and reading some books, I felt it was time to prepare for the Professional Scrum Master (aka PSM) certification provided by Scrum.org. Since Ken Schwaber holds the class in Franktfurt (which is just a trip of about 130 kilometers), there was no excuse to not attend and to not learn from »the master himself«.

Attendees (and Ken) may know why I’ve chosen a duck as the picture for this posting :) . For me, it has a further meaning. A duck is a bird which can walk, swim, and fly. But it is not excellent in any of those disciplines. That’s what I feel about agile in common and Scrum in special. I learned a lot about it, but the more you learn, the more you know that there’s much more you want to discover. While practising Scrum, I always want to learn more »to do a better job tomorrow«.

People came to Frakfurt from several central european countries. The course is held in english language, and frankly, I really enjoy Ken’s style of training. It’s just the right mixture of humor and focus which, combined with the usual team exercises, allows to learn as much as possible. So yes, I’m eagerly waiting for the second day :) .