Archive for the ‘Scrum’ Category

Kommunikationsmittel, Konvention, Präzision und Ästhetik

Tuesday, January 17th, 2012

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.

User Stories Applied & Agile Estimating and Planning

Tuesday, December 13th, 2011

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

Scrum User Group Karlsruhe – December 2011

Thursday, December 8th, 2011

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.

Scrum – The Definition of Done

Sunday, November 27th, 2011
The first portable synthesizer, the Minimoog

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.

Certified Scrum Product Owner Certification

Tuesday, October 11th, 2011

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.

Professional Scrum Master I Certification

Monday, October 10th, 2011

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.

Scrum – How to attract talents

Saturday, October 8th, 2011

In their book¹, Boris Gloger and André Häusling describe a (fictive) scenario where a company struggles with recruiting a ScrumMaster. One year after they finally filled the vacancy, they are searching anew, as the candidate signed off. Subsequently they share some knowledge how to attract and select Scrum specialists.

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

Scrumday Conference 2011 is past

Wednesday, September 28th, 2011

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«

Professional Scrum Master Course With Ken Schwaber, Day II

Saturday, September 24th, 2011
Janus, Vatican, via Wikipedia, public domain

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

Professional Scrum Master Course With Ken Schwaber, Day I

Thursday, September 22nd, 2011
Weibliche Ente von Petr Kratochvil

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 :) .

Scrum – Trainings, classes, and certificates

Sunday, September 11th, 2011

Companies usually exist »to earn profit to increase the wealth of their owners.«. Ken Schwaber mentiones[1],[2] that Scrum is not a methodology, but a framework for risk management and value optimization by frequent replanning. The key advantage of Scrum is that impediments and dysfunctions which prevent an organisation from being successful are made transparent to everyone, so that they can be addressed and solved systematically. Ken also warns that organisations which do use Scrum not to analyse and optimize themselves will fail miserably.

(more…)

Scrum – Basic flow of user stories

Saturday, September 10th, 2011

In Scrum, at least the two most basic boards should exist, the Product Backlog Board and the Sprint Backlog Board. There are a couple of synonyms for the latter one, like Selected Backlog Board or Task Board. User Stories flow over these boards, using the following approach.

(more…)

Agile software development – User Stories

Wednesday, September 7th, 2011

In the world of agile software development, user stories are a common way of creating product backlog items. They are often found in Scrum and Extreme Programming (XP) environments, and often printed to small cards or hand-written on index cards. The advantages of user stories include that they are simple to understand and maintain. In case you are interested in more details, you might as well read »User Stories Applied« by Mike Cohn[1].

(more…)

Eleven years of success

Friday, September 2nd, 2011

I came to the software business »through the back door«. I joined »the company« back in 2000, and I was its very first full time employee. I’ve seen growing the company, its products, and myself. Meanwhile I’m the product manager for interiorcad, and the one who successfully introduced Scrum 20 months ago.

Did I enjoy the journey? Sure, and I learned a lot. As a team player, you have to ensure that people are making the right decisions by providing the right arguments. As a change manager, you have to convince people, day by day. Sometimes it is necessary to overwhelm individuals also, though it is not much fun. As a product manager, you need a clear vision, you need to be open minded and you need to listen. And you need to resist the temptation to try to suit everybody. The latter issue is hard for yourself, and it is hard for your partners as well. But the key to your personal and your employer’s success is focus.

I’m currently transmogrifying my product into a product »that customers love«¹. We’re building an appearently simple feature which is capable of completely changing the perception of what interiorcad is. My teammates sometimes disagreed, sometimes they complained, and some colleagues even tried to antagonize it. This week we encountered a major breakthrough. During the last couple of days, some of them stated that I was right and it was a worthwhile effort. I’m not a stubborn guy. But when you know you are right, stubbornness is not a bug, but a feature :) .

My life is just half over, and I served the same company for more than a decade. I’m really curious what interests, challenges, and opportunities will arise during the next thirty years.

 

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

Scrum – The Meetings

Tuesday, August 30th, 2011

Sharing knowledge, whenever possible by face-to-face communication, is an important aspect of Scrum. The Scrum meetings consume a significant amount of time, as we understood the importance of direct communication. Here’s a citation of the Manifesto for Agile Software Development:

Individuals and interactions over processes and tools

(more…)

»Scrum – Produkte zuverlässig und schnell entwickeln« von Boris Gloger

Saturday, August 27th, 2011

Nachdem ich in den letzten Jahren einige (zumeist englischsprachige) Bücher und sonstige Quellen zum Thema Scrum gelesen habe, lese ich derzeit das Buch »Scrum – Produkte zuverlässig und schnell entwickeln« von Boris Gloger1. Es ist das bisher beste, weil es den aktuellen Stand hochkomprimiert auf dem Silbertablett präsentiert. Überraschenderweise liegt es in deutscher Sprache vor – was mich üblicherweise eher abschreckt, weil deutschsprachige Fachbücher sich oft mit Themen beschäftigen, die im angelsächsischen Sprachraum fast schon wieder “Schnee von gestern” sind. Im vorliegenden Falle ist es erfreulicherweise eher umgekehrt :) .

(more…)

The High Performance Boat

Monday, August 22nd, 2011

Scrum is about building a high performance team (in case someone can share a good german translation, please drop me a line).

Lyssa Adkins suggests a »high performance tree«¹ to visualize the basic Scrum values, the characteristics of high collaboration and the outcomes. I’ve never been good in creating artistic drawings, but as Lyssa writes »You can see from the illustration that you need not be a good artist to do this.«, here’s an adaption. Instead of the tree, I used a boat metaphor:

The high performance boat

The high performance boat

Feel free to comment, download, and reuse it. On request, I’ll also share the original source drawing in SVG format.

¹ Lyssa Adkins, »Coaching Agile Teams« 2010, ISBN-13 978-0-321-63770-3, Page 24

Coping with complaints in agile Teams

Sunday, August 7th, 2011
Graphics by openclipart.org, public domain

Graphics by openclipart.org, public domain

Last week, a team member complained about the behaviour of another one and asked me to talk to her. So I did.

(more…)

Agiler Schmusekurs

Saturday, August 6th, 2011

Je mehr ich über das Coaching von agilen Entwicklerteams lese, desto mehr zweifle ich daran, dass alle dort vorgestellten Mehoden ein Team tatsächlich performanter machen (Davies&Sedley, Adkins, Derby&Larsen). Mag sein, dass das auf angelsächsische Verhältnisse passt. Aber lässt sich das ohne weiteres auf Europa (und weitere Kontinente) übertragen?

(more…)

Scrum – The Roles

Saturday, August 6th, 2011

This posting exists due to a discussion about Scrum failure in a Scrum User Group. Common causes for Scrum failing is the absence of a Scrum Master, a Product Owner, or the roles not being played correctly.

Let’s first face the reason why Scrum exists. What is motivating a company’s management to install a Scrum framework? Privately owned companies often are “administered to earn profit to increase the wealth of their owners.“. Less surprising, the answer to the above question is obvious – business figures.

(more…)