Skip to content

Blogs

A Whirlwind Tour of the Kotlin Type Hierarchy

Mistaeks I Hav Made - Nat Pryce - Fri, 10/28/2016 - 10:08
Kotlin has plenty of good language documentation and tutorials. But I’ve not found an article that describes in one place how Kotlin’s type hierarchy fits together. That’s a shame, because I find it to be really neat1. Kotlin’s type hierarchy has very few rules to learn. Those rules combine together consistently and predictably. Thanks to those rules, Kotlin can provide useful, user extensible language features – null safety, polymorphism, and unreachable code analysis – without resorting to special cases and ad-hoc checks in the compiler and IDE. Starting from the Top All types of Kotlin object are organised into a hierarchy of subtype/supertype relationships. At the “top” of that hierarchy is the abstract class Any. For example, the types String and Int are both subtypes of Any. Any is the equivalent of Java’s Object class. Unlike Java, Kotlin does not draw a distinction between “primitive” types, that are intrinsic to the language, and user-defined types. They are all part of the same type hierarchy. If you define a class that is not explicitly derived from another class, the class will be an immediate subtype of Any. class Fruit(val ripeness: Double) If you do specify a base class for a user-defined class, the base class will be the immediate supertype of the new class, but the ultimate ancestor of the class will be the type Any. abstract class Fruit(val ripeness: Double) class Banana(ripeness: Double, val bendiness: Double): Fruit(ripeness) class Peach(ripeness: Double, val fuzziness: Double): Fruit(ripeness) If your class implements one or more interfaces, it will have multiple immediate supertypes, with Any as the ultimate ancestor. interface ICanGoInASalad interface ICanBeSunDried class Tomato(ripeness: Double): Fruit(ripeness), ICanGoInASalad, ICanBeSunDried The Kotlin type checker enforces subtype/supertype relationships. For example, you can store a subtype into a supertype variable: var f: Fruit = Banana(bendiness=0.5) f = Peach(fuzziness=0.8) But you cannot store a supertype value into a subtype variable: val b = Banana(bendiness=0.5) val f: Fruit = b val b2: Banana = f // Error: Type mismatch: inferred type is Fruit but Banana was expected Nullable Types Unlike Java, Kotlin distinguishes between “non-null” and “nullable” types. The types we’ve seen so far are all “non-null”. Kotlin does not allow null to be used as a value of these types. You’re guaranteed that dereferencing a reference to a value of a “non-null” type will never throw a NullPointerException. The type checker rejects code that tries to use null or a nullable type where a non-null type is expected. For example: var s : String = null // Error: Null can not be a value of a non-null type String If you want a value to maybe be null, you need to use the nullable equivalent of the value type, denoted by the suffix ‘?’. For example, the type String? is the nullable equivalent String, and so allows all String values plus null. var s : String? = null s = "foo" s = null s = bar The type checker ensures that you never use a nullable value without having first tested that it is not null. Kotlin provides operators to make working with nullable types more convenient. See the Null Safety section of the Kotlin language reference for examples. When non-null types are related by subtyping, their nullable equivalents are also related in the same way. For example, because String is a subtype of Any, String? is a subtype of Any?, and because Banana is a subtype of Fruit, Banana? is a subtype of Fruit?. Just as Any is the root of the non-null type hierarchy, Any? is the root of the nullable type hierarchy. Because Any? is the supertype of Any, Any? is the very top of Kotlin’s type hierarchy. A non-null type is a subtype of its nullable equivalent. For example, String, as well as being a subtype of Any, is also a subtype of String?. This is why you can store a non-null String value into a nullable String? variable, but you cannot store a nullable String? value into a non-null String variable. Kotlin’s null safety is not enforced by special rules, but is an outcome of the same subtype/supertype rules that apply between non-null types. This applies to user-defined type hierarchies as well. Unit Kotlin is an expression oriented language. All control flow statements (apart from variable assignment, unusually) are expressions. Kotlin does not have void functions, like Java and C. Functions always return a value. Functions that don’t actually calculate anything – being called for their side effect, for example – return Unit, a type that has a single value, also called Unit. Most of the time you don’t need to explicitly specify Unit as a return type or return Unit from functions. If you write a function with a block body and do not specify the result type, the compiler will treat it as a Unit function. Otherwise the compiler will infer it. fun example() { println("block body and no explicit return type, so returns Unit") } val u: Unit = example() There’s nothing special about Unit. Like any other type, it’s a subtype of Any. It can be made nullable, so is a subtype of Unit?, which is a subtype of Any?. The type Unit? is a strange little edge case, a result of the consistency of Kotlin’s type system. It has only two members: the Unit value and null. I’ve never found a need to use it explicitly, but the fact that there is no special case for “void” in the type system makes it much easier to treat all kinds of functions generically. Nothing At the very bottom of the Kotlin type hierarchy is the type Nothing. As its name suggests, Nothing is a type that has no instances. An expression of type Nothing does not result in a value. Note the distinction between Unit and Nothing. Evaluation of an expression type Unit results in the singleton value Unit. Evaluation of an expression of type Nothing never returns at all. This means that any code following an expression of type Nothing is unreachable. The compiler and IDE will warn you about such unreachable code. What kinds of expression evaluate to Nothing? Those that perform control flow. For example, the throw keyword interrupts the calculation of an expression and throws an exception out of the enclosing function. A throw is therefore an expression of type Nothing. By having Nothing as a subtype of every other type, the type system allows any expression in the program to actually fail to calculate a value. This models real world eventualities, such as the JVM running out of memory while calculating an expression, or someone pulling out the computer’s power plug. It also means that we can throw exceptions from within any expression. fun formatCell(value: Double): String = if (value.isNaN()) throw IllegalArgumentException("$value is not a number") else value.toString() It may come as a surprise to learn that the return statement has the type Nothing. Return is a control flow statement that immediately returns a value from the enclosing function, interrupting the evaluation of any expression of which it is a part. fun formatCellRounded(value: Double): String = val rounded: Long = if (value.isNaN()) return "#ERROR" else Math.round(value) rounded.toString() A function that enters an infinite loop or kills the current process has a result type of Nothing. For example, the Kotlin standard library declares the exitProcess function as: fun exitProcess(status: Int): Nothing If you write your own function that returns Nothing, the compiler will check for unreachable code after a call to your function just as it does with built-in control flow statements. inline fun forever(action: ()->Unit): Nothing { while(true) action() } fun example() { forever { println("doing...") } println("done") // Warning: Unreachable code } Like null safety, unreachable code analysis is not implemented by ad-hoc, special-case checks in the IDE and compiler, as it has to be in Java. It’s a function of the type system. Nullable Nothing? Nothing, like any other type, can be made nullable, giving the type Nothing?. Nothing? can only contain one value: null. In fact, Nothing? is the type of null. Nothing? is the ultimate subtype of all nullable types, which lets the value null be used as a value of any nullable type. Conclusion When you consider it all at once, Kotlin’s entire type hierarchy can feel quite complicated. But never fear! I hope this article has demonstrated that Kotlin has a simple and consistent type system. There are few rules to learn: a hierarchy of supertype/subtype relationships with Any? at the top and Nothing at the bottom, and subtype relationships between non-null and nullable types. That’s it. There are no special cases. Useful language features like null safety, object-oriented polymorphism, and unreachable code analysis all result from these simple, predictable rules. Thanks to this consistency, Kotlin’s type checker is a powerful tool that helps you write concise, correct programs. “Neat” meaning “done with or demonstrating skill or efficiency”, rather than the Kevin Costner backstage at a Madonna show sense of the word↩
Categories: Blogs

Links for 2016-10-26 [del.icio.us]

Zachariah Young - Thu, 10/27/2016 - 09:00
Categories: Blogs

Links for 2016-10-24 [del.icio.us]

Zachariah Young - Tue, 10/25/2016 - 09:00
Categories: Blogs

Integreer Kwaliteit met Lean Software Ontwikkeling

Ben Linders - Wed, 08/24/2016 - 13:26

Integreer kwaliteit Agile LeanAgile methoden zoals Scrum leggen de nadruk op functionaliteit. Klanten verwachten echter naast functionaliteit dat ook de kwaliteit van het product in orde is. Waar Agile voornamelijk aandacht geeft aan het software team en de interactie met de omgeving, kijkt Lean naar de gehele keten: van klantbehoefte tot waarde voor de klant. Een van de aspecten van Lean Software Ontwikkeling is het integreren van kwaliteit.

Lean Software Ontwikkeling combineert Agile en Lean met de volgende 7 principes:

  1. Verminder Verspillingen (Eliminate Waste)
  2. Integreer Kwaliteit (Build Quality In)
  3. Leer Voortdurend (Learn Constantly)
  4. Lever Snel (Deliver Fast)
  5. Betrek Iedereen (Engage Everyone)
  6. Verbeter Continue (Keep getting Better)
  7. Optimaliseer het Geheel (Optimize the whole)
Kwaliteit begint bij de klanten


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Mijn definitie van kwaliteit (zie Hoe zorg je met Scrum voor Kwaliteitsproducten en Diensten) is:

Kwaliteit is de mate waarin voldaan wordt aan de behoeften van de gebruikers, en aan de eisen van de opdrachtgevers. Dat kunnen zowel functionele behoeften zijn (iets wat het product of dienst moet doen), of “performance”of niet-functionele eisen (hoe snel, hoe veel, de betrouwbaarheid, etc), vaak is het een combinatie van beide.

Het zijn je klanten die bepalen wat kwaliteit is (en wat niet), en wat vereist is voor een goede kwaliteit. Pas als je weet wat je klanten nodig hebben kun je naar goed oplossingen zoeken om aan hun wensen te voldoen. Je integreert daarmee kwaliteit in het gehele ontwikkelproces. Het juiste product

Hoe kom je erachter wat de klant nodig heeft? Agile kent diverse practices waarin het team en de klanten (in de Scrum praat men over product owner ipv klant) intensief samenwerken om ervoor te zorgen dat het juiste product geleverd wordt. Voorbeelden daarvan zijn de planning game en de product demonstratie.

In de planning game gaat het erom dat de product eisen duidelijker worden. Wat willen klanten bereiken met het product, welke waarde moet het hun gaan bieden? Wat moet het product doen om die waarde te kunnen leveren? Maar ook de kwaliteitseisen: hoe snel moet het werken, en hoe betrouwbaar en stabiel moet het zijn? Het team benut zijn kennis en ervaring om te bepalen wat mogelijk is, en hoe het product op een Lean manier ontwikkelt kan worden.

In de product demonstratie laat je het product zien aan de klanten en vraag om je feedback. Is dit wat de klant wil? Is het goed genoeg? Maar ook: Is het snel genoeg, handig te gebruiken. Betrouwbaar en veilig? En, gegeven wat het product nu doet, wat is er nog meer nodig? Kwaliteit met Agile en Lean

Hoe gaat dat in de praktijk? Laten we kijken naar een medisch systeem wat specialisten gebruiken om onderzoek te doen met patiënten. De specialisten (klanten) willen een aantal mogelijkheden hebben om data en scans van een patiënt te bekijken. Ze willen beelden van eerdere scans kunnen oproepen, inzoomen, en vergelijken. Omdat ze dat vaak met de patiënt erbij doen moet dat snel gaan, en eenvoudig te bedienen zijn. De gegevens mogen niet fout zijn, de specialisten gebruiken ze om beslissingen te nemen waar het leven van de patiënt van af kan hangen.

In de discussies vooraf en in de planning game formuleren de product owner en het team de acceptatie criteria. Voor kwaliteitseisen moeten die criteria meetbaar zijn. Dus niet “snel genoeg” maar “in 90% van de gevallen reageert het systeem binnen 1 seconde”.

Samen met de product owner formuleren de teamleden user stories. De acceptatiecriteria in de user stories worden door het team gebruikt om af te spreken hoe ze de software gaan maken en verifiëren.

Bijvoorbeeld, voor een bepaalde user story doen ze een spike, ze maken een stukje sofware en een testcase die meet hoe snel de software is om te bepalen of wat de klant wil haalbaar is. Voor een andere user story wil het team pair programming gebruiken, het is een complexe functie waarmee de team leden nog geen ervaring hebben.

Er zijn ook stories waarbij test driven design volgens het team de beste aanpak is, en een enkele story waarbij de klant nog niet echt weet wat het product precies moet gaan doen om er op  een handige manier mee te kunnen werken, daar lijkt prototyping met Lean Startup het beste te passen.

De vereiste functionaliteit en kwaliteit is bepalend voor de aanpak. De product owner maakt duidelijk wat er nodig is en welke kwaliteit de klanten verwachten. Het team weet wat met een bepaalde manier van werken haalbaar is, en check in de planning game met de product owner. Te weinig kwaliteit is niet goed, maar teveel ook niet. Het gaat bij lean om het vinden van de juiste balans tussen tijd, geld en kwaliteit voor het leveren van functionaliteit.

In de demonstratie wordt de software getoond en gechecked of het voldoet. Daarbij telt zowel de functionaliteit als de kwaliteit. Het moet niet alleen werken, het moet ook snel genoeg zijn, betrouwbaar, bedienbaar, etc. Pas dan voldoet het product aan alle eisen en is het af.

De kracht zit in de samenwerking tussen het team en de product owner gedurende de ontwikkeling. Is er een gedeeld beeld wanneer, hoe en waarvoor klanten het product gebruiken? Wat betekent het product voor hun en welke waarde het kan toevoegen? Kan de product owner voldoende duidelijk maken wat nodig is, en checken de teamleden of ze het goed begrepen hebben? Leren ze van dingen die niet goed zijn gegaan? Integreer kwaliteit

Lean en Agile versterken elkaar als het gaat om de kwaliteit van de producten en diensten. Met agile en lean practices integreer je kwaliteit in de volledige productontwikkelingsketen.

kwaliteitsverbeteringIn de workshop software kwaliteitsverbetering leer je hoe je goede producten en diensten kunt leveren. Kwaliteitsverbetering helpt organisaties om beter te voldoen aan de behoeften van de gebruikers en aan de eisen van de opdrachtgevers.

Categories: Blogs

Continue Verbetering met Agile in Bits&Chips

Ben Linders - Wed, 08/24/2016 - 11:05

bitchipslogoMijn artikel Continue Verbetering met Agile is gepubliceerd in Bits&Chips nr 4. In dit artikel laat ik zien dat continue verbetering een integraal onderdeel is van de Agile-mindset en van de Agile-principes en -practices, en geef ik tips en advies voor verbeteren met agile:

Silver bullets bestaan niet in softwareontwikkeling. Effectieve softwareteams bepalen zelf hoe ze hun werk doen, passen zich continu aan en verbeteren zichzelf. Continue verbetering is ingebed in de Agile-mindset en -principes en helpt zo om de flexibiliteit in bedrijven te verhogen en meer waarde te leveren, betoogt Ben Linders.


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Bits&Chips publiceert een magazine over ontwikkelingen in de high-tech industrie en organiseert de jaarlijkse smart systems conferenties (Software-Centric Systems Conference in 2016).

Eerder dit jaar publiceerde Bits&Chips een Engelstalige editie, met daarin mijn artikel Delivering quality software with Agile.

Categories: Blogs

Survey on Agile Manifesto 2.0

Ben Linders - Mon, 08/15/2016 - 17:59

Survey agile manifesto KamleshIs There a Need For Agile Manifesto 2.0? That’s the question that Kamlesh Ravlani, Agile / Lean Coach and Scrum Trainer, is asking the Agile community. He is running a Survey on Agile Manifesto 2.0, which he announced on LinkedIn Pulse.

Lately there is a lot of buzz in the Agile community around the need to update the Agile Manifesto. Many agilists have been vocal about it and some have floated their own versions of the manifesto. Let’s explore collectively as a community the need for changes in the Agile Manifesto.


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Please support this survey by answering three questions (it only takes a couple of minutes).

Kamlesh will publicly share the findings from the survey:

Who can participate?
All practitioners, Agile coaches, trainers and thought leaders are invited to share their opinion.

How will this information be used?
I intend to share the results of this survey with community via recognized platform for example – Infoq, ScrumAlliance, etc.

I’ve responded to this survey and I’m hoping many of you will do the same :-).

Categories: Blogs

Feedback in Agile

Ben Linders - Wed, 08/10/2016 - 11:38

feedback agileAgile software ontwikkeling kent ingebouwde feedback. Iedere iteratie wordt afgesloten met een sprint review/demo en een agile retrospective, waarin feedback centraal staat. Ook tijdens de iteratie is er gelegenheid voor feedback. Een overzicht van de diverse manieren van feedback in agile en de voordelen die feedback oplevert. Product Demonstratie

De product demonstratie (sprint review in Scrum) is bedoeld om feedback te krijgen op het product. Een goede demo zorgt voor antwoorden op vragen zoals:

  • Doet het product wat het zou moeten doen?
  • Is het product bruikbaar?
  • Welke functionaliteit is verder nodig?
  • Wat kan er aan het product verbeterd worden?
Agile Retrospective


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

In de agile retrospective reflecteert het team op hun proces. In de retrospective geven teamleden feedback naar elkaar. Deze feedback geeft inzicht in de manier van werken en helpt om continu te verbeteren.

Een goede retrospective geeft inzicht in:

  • Wat ging er goed en wat heb je als team geleerd?
  • Welke problemen zijn er geweest, wat zou je willen veranderen?
  • Welke sterktes en kwaliteiten heeft het team?
  • Hoe kan het team zich verder ontwikkelen?

Cover Waardevolle Agile Retrospectives ManagementboekWaardevolle Agile Retrospectives is het 1e Nederlandstalige Agile boek voor het faciliteren van retrospectives. Met vele oefeningen, het “wat” en “waarom” van retrospectives, de business value en de voordelen die retrospectives brengen. Tevens practische tips en adviezen voor het introduceren en verbeteren van retrospectives. Aanbevolen voor agile coaches, Scrum masters, project managers, product managers en facilitators die al enige ervaring hebben met retrospectives. Andere feedback momenten

De demo en retrospective zijn de bekendste feedback momenten in Agile. Maar er zijn er nog meer. Tijdens de dagelijkse stand up kunnen team leden elkaar feedback geven. Bijvoorbeeld over hoe ze de samenwerking in het team ervaren en hoe een activiteit gegaan is. In de planning game geeft het team feedback op de user stories naar de product owner, samen stemmen ze de inhoud van de iteratie af. Wat levert feedback op

Feedback in agile helpt om te leren en continu te verbeteren. De voordelen die feedback in agile oplevert zijn:

  • Met frequente snelle feedback kun je eenvoudiger bijsturen
  • Concrete feedback die kort na een gebeurtenis gegeven wordt, maakt eenvoudiger om actie te ondernemen
  • Verbeteren in kleine stapjes is eenvoudiger, snelle feedback maakt het mogelijk.
  • Goede feedback verbeterd de relatie tussen mensen en helpt om effectiever samen te werken

Agile wordt je door agile te doen. Wil je met agile resultaten bereiken dan is goede feedback essentieel. De sprint review/demo en de agile retrospective zorgen voor continue product- en procesverbetering, waardoor teams efficiënt en effectief producten kunnen leveren.

Categories: Blogs

Gratis mini-workshop over Agile Retrospectives

Ben Linders - Wed, 08/10/2016 - 11:06

AgileHubNoordOp 21 september geef ik een gratis mini-workshop over agile retrospectives in Groningen. In deze mini-workshop gebruik ik oefeningen uit mijn succesvolle workshop Waardevolle Agile Retrospectives.

Retrospectives helpen je om agile effectief toe te passen continu te verbeteren. Je pakt ermee problemen aan en zorgt voor een goede werksfeer in je teams. Scrum masters en Agile coaches halen  meer uit teams met behulp van een toolbox met retrospective oefeningen.

In deze mini-workshop geeft Ben Linders, auteur van het boek Waardevolle Agile Retrospectives, een introductie van de “waarom” en “wat” van retrospectives. Je oefent verschillende manieren om retrospectives te doen en krijgt tips en adviezen voor het introduceren en verbeteren van retrospectives.

Deze mini-workshop wordt gegeven in samenwerking met AgileHubNoord, een onafhankelijke netwerkorganisatie die als doel heeft om Agile-professionals uit Noord-Nederland met elkaar te verbinden, kennis met elkaar te delen en om het Agile-gedachtegoed onder de aandacht te brengen.


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Er zijn helaas geen plaatsen meer beschikbaar voor deze workshop (hij was in enkele dagen volledig “uitverkocht”), maar er is een wachtlijst. Als mensen zich afmelden word je automatisch aangemeld voor de meetup.

De workshop workshop Waardevolle Agile Retrospectives geef ik zowel via open inschrijving als in-house, aangepast aan de specifieke wensen van jou bedrijf en situatie. Neem contact met mij op!

Categories: Blogs

Chapter on Visual Management added to What Drives Quality

Ben Linders - Wed, 08/10/2016 - 09:30

What Drive Quality coverA new chapter which explores how visual management can be used to improve quality of software products has been added to my second book What Drives Quality.

One of the principles from agile and lean software development is transparency. Making things visible helps teams to decide what to develop and to collaborate effectively with their stakeholders. It can also help to increase the quality of software. You can apply visual management to make potential quality issues visible early and prioritize solving them. The examples that I provide explain clearly why quality matters and how visualization can be used to establish, maintain and even increase the quality of software products.


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

What drives quality provides insight into the factors that drive the quality software products and services. Understanding what drives quality enables you to take action before problems actually occur, thus saving time and money.

The book What Drives Quality is available for a reduced price on Leanpub as long as it’s under development. If you buy the book now you will automatically get all chapters that are added in the future for free. So don’t wait too long, get your copy now!

Categories: Blogs

Why do you want to become agile?

Ben Linders - Mon, 08/08/2016 - 13:16

Why becoming agileBecoming agile can help to achieve organizational goals. But setting agile as a goal for an organization does not work. The goal for a software organization should be to achieve results by delivering valuable products and services, not to become agile. Hence my question: do you know why do you want to become agile?
Yes, seriously, why would you do agile? There are lot’s of good reasons (and also some less good ones), but what’s your reason to become agile? What do you expect from agile?

Agile transformations seriously impact organizations (they should!). It’s a reorganization of people, work, and authorities. Employees are asked to think about the way they want to do their work, and to take responsibility. Managers have to give room to their employees. There must be a good reason to do all of this. You should know the reason why you want to become agile, and let everyone involved know.


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

It is important to know why you want to increase the agility of your organization and what you expect to achieve with agile. To know why would you want to work in an agile way, why you want your culture to become agile.

Again, agile is not an goal or state that needs to be reached. It’s important that every manager and employee knows why the organization starts an agile journey and what is expected from agile. Reasons to become agile

If I ask people in organizations that I work with why they want to become agile they often look surprised at first. Of course they want agile! Everybody is doing agile, so it must be good. Agile is supposed to make them faster, cheaper and better. So let’s do it. If it only was that easy … every organization should be truly agile by now.

Does knowing the reason matter? Yes, it does! If you know the reason why you want to become agile, chances of success increase significantly. If people know why they have to chance, if they see the purpose, they are more willing to do it.

Some of the reasons that I have heard in organizations on why they want to become agile are:

  • Deliver the right products and services
  • Be able to deliver faster
  • Increase customer satisfaction and win new customers
  • Create innovative products with motivated employees
  • Reduce the cost of development and management
  • Improve the quality of goods and services
  • Effective cooperation between development and management
  • (your reason here)

My advice to companies is to think about why they want to become agile. Pick one reason, and one only. State very clearly in one sentence what your main objective to become agile. What would make your agile transformation successful. Going for one goal is hard enough. Also, the reason you choose impacts the way that agile will be applied (it should!), so choose your reason carefully. What is your goal with agile?

Do you want to deliver products with good quality? Or be able to better meet the needs of your customers? Lower your costs? Increase the motivation of your employees? Whatever your reason is to become agile, contact me, and I’ll help you to get results :-).

Categories: Blogs

Books by Ben Linders on Leanpub

Ben Linders - Mon, 08/08/2016 - 11:07

Books Ben Linders LeanpubAll of the books that I have published on Leanpub are now available in a bundle: Books by Ben Linders. You get a 30% discount when you buy my books with this bundle.

Currently this bundle contains three books:


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

With plenty of exercises for your personal retrospective toolbox, Getting Value out of Agile Retrospectives will help you to become more proficient in doing retrospectives and to get more out of them.

My book What Drives Quality helps you to prevent software problems from happening by building an shared understanding what drives software quality. It enables you to effectively take actions, saving time and money!

My book Continuous Improvement makes you aware of the importance of continuous improvement, explores how it is engrained in agile, and provides suggestions that Scrum masters, agile coaches, well everybody, can use in their daily work to improve continuously and increase team and organizational agility.

My 2nd and 3rd book are being written incrementally. Currently they are only sold via Leanpub. When you buy the book on Leanpub you will automatically receive new chapters when they become available, free of charge.

All books that I will publish in the future on leanpub will be added to this bundle.

Categories: Blogs

Masterclasses at Agile Tour Kaunas

Ben Linders - Mon, 08/01/2016 - 18:49

agiletour2016kaunas I’m giving two masterclasses at Agile Tour Kaunas on October 11 and 12 on Retrospectives and on Agile and Lean. Tickets for these agile workshops can be bought on the Agile Tour Lithuania courses webpage.

The two masterclasses are:


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

This is the first time that I’m giving my workshops in Lithuania. I’m grateful to Agile Lithuania for inviting me to their country.

The early bird price (till September 1st) for my masterclasses is 319 Eur (VAT not applicable). Regular price: is 379 Eur.

As an adviser, coach and trainer I helps organizations by deploying effective software development and management practices. I provide workshops and training sessions, public and private sessions. Here’s a list of my upcoming public sessions.

Categories: Blogs

A Summary of More Fearless Change in 15 Tweets

Ben Linders - Fri, 07/29/2016 - 11:58

More Fearless Change book coverThe book More Fearless Change by Mary Lynn Manns and Linda Rising provides ideas for driving change in organizations, using the format of patterns. This book is an new and extended version of their successful book Fearless Change.

I did an interview with Mary Lynn and Linda about how people are viewing change in organizations, the purpose of patterns and the benefits that organizations can get from using them, the new patterns that are described in More Fearless Change and the insights were added to the existing patterns, and their expectations about what the future will bring us in organizational change. You can read it on InfoQ: Q&A on the Book More Fearless Change. 15 Quotes from More Fearless Change


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Here’s a set of 15 quotes from the new patterns that have been added in More Fearless Change. I’m tweeting these quotes with #fearlesschange: No matter how great your new idea is and how well prepared you are, you are bound to meet some level of resistance Inspire people throughout the change initiative with a sense of optimism rather than fear When you feel discouraged, look for the bright spots among the challenges that surround you Displaying a warm smile and a willingness to be nice even when negativity surrounds you can go a long way To make progress toward your goal, state precisely what you will do as you take the next baby step To encourage adoption of a new idea, experiment with removing obstacles that might be standing in the way Change the environment in a way that will encourage people to adopt the new idea When you have a chance to introduce someone to your idea, you don’t want to stumble around for the right words to say Persuasion tactics must consider what people are logically thinking as well as what they are feeling By focusing on the future, individuals may be more motivated to let go of the past Your change initiative is a series of baby steps As you prepare to move forward, occasionally look for a quick and easy win that will have visible impact Stay in touch with your supporters—never assume that news of your progress is known across the organization Rumors need to be debunked before they take root and create significant concerns and anxieties during the change You can’t spend time and energy addressing every bit of resistance you meet Patterns can help you to drive change

If you want to truly change organizations, don’t try to plan it up front and don’t look for recipes. That won’t work (literally!). Patterns provide a useful format to convey ideas and to apply those ideas in a specific situation to do sustainable change.

Mary Lynn Manns and Linda Rising did a great job in this updated and extended version of Fearless Change. The experiences that they added to the existing patterns help you to get a deeper understanding, and the new patterns that they describe in this book are very valuable.

The patterns described in More Fearless Change help you to recognize situations and to come up with solutions for dealing with them. If you are dealing with change in organizations (and who isn’t nowadays) then I highly recommend to read this book and keep it close to you, as it will be useful at many times!

Categories: Blogs

Books with Agile Practices and Tips

Ben Linders - Thu, 07/28/2016 - 09:54

Agile Practices and Tips Books BundleA new bundle of books with agile practices and tips has been released on Leanpub. Buy these books with a 40% discount!

The bundle includes six great books from eleven authors, helping you to make your agile journey easier to travel, more successful, and fun!

  • With plenty of exercises for your personal retrospective toolbox, Getting Value out of Agile Retrospectives will help you to become more proficient in doing retrospectives and to get more out of them.
  • A Toolbox for the Agile Coach:  96 Visualization Examples showing how great teams visualize their work.
  • The tools and techniques provided in the Forming Agile Teams workbook offer an alternative-proven way to add more structure, transparency and visibility to the work that you do when Forming Agile Teams, by combining visual explanations with techniques and tips to support Scrum Masters crucial role within the organization.
  • The Scrum Master Workbook Part 1 provides 15 weeks of accelerated learning. It teaches you ways to deal with conflict, bugs, interruptions, meetings and many more topics.
  • Patterns of Agile Journeys shares stories and patterns to help you recognize situations you may find yourself in on your own journey. Use the tips in this book to reinforce or counteract the patterns you see.
  • The book Continuous Improvement makes you aware of the importance of continuous improvement, explores how it is engrained in agile, and provides suggestions that Scrum masters, agile coaches, well everybody, can use in their daily work to improve continuously and increase team and organizational agility.


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Together these books provide many useful tips and practices for your agile journey. Buy them for $40,77 (regular price is $67,95).

There’s also the Agile Retrospectives Books Bundle with six great books that will make your agile retrospectives rock, and the Valuable Agile Retrospectives – All Languages Bundle which contains all language editions of my successful book Getting Value out of Agile Retrospectives.

Categories: Blogs

Manifesto voor Agile Veranderen

Ben Linders - Tue, 07/26/2016 - 10:47

Manifesto Agile Veranderen Ben LindersHet manifesto voor agile veranderen helpt organisaties om hun agility te verhogen. Het zorgt voor blijvende verbetering van de resultaten, tevreden klanten, en blije medewerkers. Dit eerste artikel over Agile Veranderen beschijft de uitgangspunten en waarden met behulp van het manifesto voor agile veranderen.

Agile software ontwikkeling is gebaseerd op het Manifesto voor Agile Software Ontwikkeling. Dit manifesto bevat vier waarden en twaalf principes. Het manifesto voor agile veranderen is op een zelfde manier opgebouwd. Het beschrijft mijn visie en werkwijze in organisatieverandering, samengevat in vier waarden. Mijn verander “waarden”


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Dit zijn de waarden van mijn Manifesto voor Agile Veranderen:

  • Betrekken van professionals en ruimte geven voor ideeën over standaardisatie en voorschrijven van werkprocessen
  • Stapsgewijze evolutionaire verbetering van binnen uit over top down opleggen van veranderingen.
  • Resultaatgericht en intensief samenwerken over directieve doelen met “command & control” management.
  • Prioritiseren en flexibel inspelen op kansen over budgetteren en veranderplannen uitvoeren.

De waarden aan de rechterkant van bovenstaande statements zijn en blijven belangrijk, maar ik geef graag meer aandacht aan de waarden aan de linkerkant. Daarom geef ik bijvoorbeeld de voorkeur aan het in kaart brengen van de bestaande werkprocessen met de medewerkers en samen werken aan verbetering mbv retrospectives in plaats van organisatiebreede uitrol van Scrum met standaard trainingen. En werk ik liever met een veranderbacklog waarin de prioriteiten eenvoudig aan te passen zijn dan met een plan. Ook veranderen veranderd

Anders dan het Agile Manifesto wat al 15 jaar hetzelfde is verwacht ik dat dit manifesto wel zal veranderen. De eerste evolutie is al te zien als je het vergelijkt met het verander manifesto van veranderproject, een samenwerkingsverband van enkele jaren geleden. Bijvoorbeeld woorden als “verbinden” zijn verder uitgewerkt in “resultaatgericht en intensief samenwerken” en het manifesto voor agile veranderen benoemd de rol van de professional en een bottom up aanpak voor verandering.

In de nabije toekomst zal ik diverse artikelen publiceren waarin ik dieper in ga op de waarden van dit manifesto. Ik geef daarin o.a. voorbeelden van betrekken van professionals in verandertrajecten, top-down versus bottom up veranderen, evolutionaire versus revolutionaire verandering en resultaatgericht veranderen.

Categories: Blogs

All languages bundle for Valuable Agile Retrospectives

Ben Linders - Thu, 07/07/2016 - 16:00

Valuable agile retrospectives - all languages bundleThe successful book Getting Value out of Agile Retrospectives has been translated in many languages. The leanpub bundle Valuable Agile Retrospectives – All Languages contains all language editions, you can get 9 books for the reduced price of $24,99 (excluding VAT).

People from all over the world approach us for translating our book into their native language. We love to work together with local agile communities and agile practitioners to make our book available in their local language.


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

The normal price for the 9 books is $89,91, together these books are now available for the price of $24,99, a discount of more that 70%. When you buy the bundle you will get all translations that are released in the future for free. With this bundle you will always have the latest version of our book in every language.

Our mission is to help many teams all around the world to get more value out of agile retrospectives.

At this moment out book is available in these languages on leanpub:
[Nederlands]  [Español]  [Francais]  [Japanese]  [Italiano]  [Chinese]  [русский]  [Polish]

You can buy all local language editions of Getting Value out of Agile Retrospectives at Amazon.com (and all other Amazon shops), LeanpubiTunesSmashwordsLuluBarnes & NobleKoboScribd, Oyster and Blio. Paperback editions can be bought in my webshop and on bol.com and Managementbook.nl.

Categories: Blogs

The paradox of plenty

Indefinite Articles - John Brothers - Wed, 05/04/2016 - 18:07

My customer’s coffee area used to have three urns for coffee.   The standard practice was to make a new pot if you used up the last in the current pot.

The pots were big, holding probably between 10 and 15 normal cups-sizes worth of coffee.     Unsurprisingly, I had to make coffee about once every 10-15 days.

 

More recently, there was a change to the coffee room.  Now there are six urns – two for each of the three flavors (Dark roast, regular, decaf).

Now, I make coffee almost every day.    Because when I come in, one of the two dark-roast urns is empty, and the other is half empty.  And I feel obliged to make more, since one is empty.

 

Basically, the coffee room has turned into a big conscientiousness test..  I think I’m passing.

Categories: Blogs

Coherence Busting explained

Thought Nursery - Jeffrey Fredrick - Fri, 04/08/2016 - 19:59

In Action Science workshops I teach a technique I call Coherence Busting. To understand why it is useful I ask the audience to imagine themselves making a proposal: “While you are talking you notice the main stakeholder — the person in the audience you most hope to persuade — glance at their watch. What do you do?”

I ask this question to allow the audience to experience the decision-making heuristics that Daniel Kahneman describes in this book Thinking, Fast & Slow. Kahneman models our consciousness as being two systems, our fast, automatic, unconscious System 1 and our slow, deliberate, effortful System 2. Part of what makes System 1 fast are the shortcuts it uses. Two of these shortcuts consistently arise with the watch example. The first is that we  assume that a coherent story must be correct. The second is that we limit the facts to what we can immediately recall, a process Kahneman calls What You See Is All There Is (WYSIATI).

These two shortcuts are displayed in the watch scenario.

We unconsciously construct a coherent story for what the glance means — for instance “she has somewhere else to go”. This story is based on first thoughts of what the glance might mean (WYSIATI). The coherence in our story give us the sense that our story is true. We then design our actions in response to a story we made up. This is the key lesson of the watch example: We feel as though we are responding to the reality of the situation, because WYSIATI and coherence cause us to mistake our single plausible story for the truth.

This is why we need Coherence Busting.

With the watch example, I ask the audience to describe what they think the glance means. After I have harvested the normal stories from the audience (“they’re bored”, “their attention has drifted”, “they are running short of time”) I ask them to consider other possible meanings of the glance, all of the possible reasons, even wildly implausible ones (“they have their plan for world domination written on their hand”). Now the audience generates dozens of possible reasons: it is a nervous habit, they were admiring their new watch, there could have been an alert on a smartwatch, maybe an itch on their wrist, and lots more. What makes this Coherence Busting is not just that there are lots of options but that the options are mutually incompatible. Once we can imagine conflicting explanations we are not longer trapped by the original coherent story. These options were always there, but it requires invoking System 2, our conscious and effortful thought process, to bring them to the surface. That’s not something we do when we feel we already have a good explanation. So what would trigger us to use Coherence Busting?

I’ve found Coherence Busting a useful tool to reach for when I recognize that I’m frustrated. A common pattern for me is to get frustrated when I can’t come up with a justifiable explanation for the other person’s actions, when I don’t like the explanation that System 1 has suggested for me. When I recognize that pattern I try and think of at least three incompatible motivations for why they might be behaving the way they are. The technique of Coherence Busting is a way of reminding myself that there are infinitely more possibilities than I have considered. It allows me to let go of the story I’ve made up about the other person. It reminds me that if I want to understand what the other person is thinking, I’m going to have to get out of my head and into theirs — probably starting with asking them a genuine question about what they are thinking.

Much of my work with Action Science is learning the skill of asking good questions. Coherence Busting reminds me to use those skills.

(Thanks to Douglas Squirrel for helping develop Coherence Busting. See more of our work together at ActionScienceConversations.com and the London Action Science Meetup.)

Categories: Blogs

And we’re also back

Indefinite Articles - John Brothers - Tue, 03/15/2016 - 23:11

Just like what happened on www.picobusiness.com, this wordpress site was compromised.  And I was able to restore this one in about 5 minutes, which is pretty cool.  The old style wasn’t available anymore.  Which might be a blessing 🙂

Categories: Blogs

They're going to hate you anyway

Doc On Dev - Michael Norton - Wed, 02/17/2016 - 23:30
I read an article today that was posted on LinkedIn. I'm not going to link to the article. I'm not going to tell you who wrote it. I am only telling you about the article to set the stage for what I want to write about in this quick post.

In the article, along with "taking the best from Waterfall and Agile" and mixing them together into a "perfect methodology", the author, as a self-proclaimed change agent, suggested you should force implement all CMMI Level 5 developer practices at once. Can someone point me to the list of CMMI Level 5 Developer Practices? I looked for it, but couldn't find it. Perhaps there is a walled garden somewhere with this information tucked away therein? I may be mistaken, but I believe the CMMI practices are about tracking and improving the overall process, NOT about hands-on-keys activities or anything of the sort.

But let's pretend there is a prescribed list of development practices that are classified at CMMI Level 5 so that we may continue with the discussion. The author's reasoning for forcing a list of "best practices" on the team all at once is that "They're going to hate you anyway for changing things." You might as well change everything at once and get some good results fast.
What the what?If your change management plan is to force "best practices" on people without any thought for where they are today, it's no wonder they hate you. It doesn't matter if you force one poorly chosen and misunderstood practice on them or 100. You're creating a hostile environment. You are forcing people to adopt practices they are likely not familiar with. And these practices likely don't yet fit into their overall approach to work. They probably don't even fit into the common mental model for these people.

You're actually going to make things worse for everyone. This isn't about them not being able to accept change. This is about you not taking responsibility for having no idea how to implement a change.
Meet them where they are and lead them to a better place.Organizational change usually starts slowly and builds momentum with success. I don't care if Ward Cunningham himself wrote the list of developer "best practices", you don't shock and awe anyone with them if you want to be successful.

Listen and observe. Open your mind. Look at them not from the perspective of, "Here's what you should be doing, but aren't", look at them from the perspective of, "I'd really like to understand why you do things the way you do and the benefit you gain from it."

Find something they WANT to change. Something that is causing them pain. Help them come up with something different they could try. Maybe you think they should pair program 100% of the time (presumably because it is a "best practice" [gross]). It's possible a good first step is to start talking about shared code and our agreed standards. Maybe they won't ever get to pairing. But if they get better at the things pairing helps with, isn't that pretty great?
Categories: Blogs