Please, no more care-bear Retrospectives

I was stumbling over an article that presented a way to hold a part of a special kind of retrospective:

The purpose of this retrospective is to get only positive cards!

The Basic Idea is to find a positive thing about the things that went bad during a sprint, and this in the phase where we try to gather data.

• Ask each team member to write cards with things that happened good during the sprint and things that went bad.
• For each negative card, ask people to find a positive thing about it, and make it a new card
• Ask people to present only positive cards!

I feel alarmed and troubled when I hear this. This results out of my need of being authentic to people and let them have an autonomous decision on how they feel something went in a sprint/life/job whatever. As a result of this I expect openness and total/brutal honesty when it comes to naming the facts from the teams that enter a room for a retro with me.

I mean this is a pattern we see in parental-ship (Oh little doggy pet died! don’t cry, he is in doggy heaven now) and even in modern communication methods where the hard facts of a “Story” (for example the Drone-war in Afghanistan/Pakistan) are understated to a level of degree that we don’t get the real situation anymore (this is called Meiosis). In full effect I would go as fas as calling it a variant of Orwell’s “Newspeak”. Quote from 1984:

“It’s a beautiful thing, the destruction of words.”

We are neither a nation of suppressed people nor little children. There are so many natural safeguards and barriers that people have to overcome when they have to speak up in a retro that I do not want to risk this willingness by not allowing a certain way to take part in a this event.

Let’s see what Esther Derby has to say about the purpose of this 2nd phase:

• create a shared pool of data
• ground the retrospective on facts, not opinion
• consider the objective experience

I find this already very hard to achieve and must admit I find the goals a little hard: Especially the facts, not opinion part. I don’t go for it in every retrospective, especially not the Phase 2 ;). Why? The separation of observations and so called facts is a very hard thing. I tend to do a mad/sad/glad after the team put some observations to the wall, most times in form of a timeline. What happened when, free from judgements and so called facts. These facts are most times hard to dissect from opinion. Mad/Sad/Glad is based on Feelings aka can be pure opinion as well.

This shared thought thing contains the danger that only popular opinions will be accepted. This is not what I want from a retro. I want disagreement, discussion and a group of people trying to work out one or two ideas on how things can be done better the next sprint.

It’s just my opinion that care-bearing won’t help. True, honest communication will. This is hard to do, we are constantly getting fed other types of communication, far from honest, most times not true.

My retrospective, my rules. So in case you are trapped in any of those events with me and think of something as negative, please say so, any moment with your words whatever they are.

Whenever a theory appears to you as the only possible one, take this as a sign that you have neither understood the theory nor the problem which it was intended to solve. Karl Popper

Service Design Thinking, I haz problemz with you

Lately, I have been reading up a lot of stuff on the design thinking movement, style of work and community. All this seems to be a big pool of old and new ideas combined, in order to find the perfect product for the customer. The most important books are “This is Service Design Thinking” and “Change by Design”; the first to be written by a group of industry experts, the later written by Tim Brown (CEO of IDEO – A big international design company). Let me be clear: I love most of the ideas in Service Design Thinking: Multilateral thinking, cross-functional teams up to “transdisciplinary” work, agile fitting in quite well and a lot of solutions to problems I encounter in daily work.

The Problem

However I have observed a issue that heavily disturbs me and that I never sawit discussed in the service design community meetups where I showed up: Ethics.

Two examples to make my point clear:

“Change by Design”

The Book describes a project for the american TSA in order to optimize the (post 9/11?) changes to processes on airports. People, aware of the changes in procedure at american airports, warn regularly about the very open attacks on civil liberties that were introduced with these new procedures. (Damage to health from untested scanners and sexual harassment of kids being 2 of them). Another one was a project for the “Bank of America” in order to create a new product for people to make personal bank accounts more modern. Personally, I would never work for any of these customers:

• TSA: Airport Security ever was (and maybe ever will be) security theater at best. Just Google the stuff and maybe don’t read state sponsored research on that subject. After you did this Google “Project Censored TSA” and be amazed on how the USA has privatized sovereign efforts to TSA and this company is used, in a very similar way military contractors by Companies like Xi, to outsource and undermine basic freedoms of citizens.
• Bank Of America: Just Google “Bank of America Scandal YEAR”. Dear IDEO’s you could have known this before. Where is the research on your customers?

Yes, “Change by Design” has a part on more philanthropic projects in later chapters of the Book, but it’s to late there. I think this is covering up for the more dark aspects of the earlier jobs. Yes, it helps clearing the conscience of the companies and people working there but it is to late by then. You can not make up with a philanthropic project for the damage done in another project.

“This is Service Design Thinking”

In the Chapter “Operations Management – The Quest for Efficiency” the Author Kate Blackmon uses McDonalds as a good example of the combination of elements from “Taylorism” (work analysis and job specification) and “Fordism” (standardization of the inputs and outputs). This was where I went OMGWTFNERDRAGE. Yes, McDonalds might be a heavily optimized workplace, but ask a Burger-flipper of your choice how much he loves that job, a animal rights group of your choice about the conditions the animals live in which land on your dish (ask chicken if you got a good stomach), ask people who know about healthy food ingredients on McDonalds meals and I could go on. I should be thanking for this Example, there is no better explanation for the bad Side-effects if you apply the thinking of Taylor and Ford without additional ethical safeguard. I don’t oppose standardization and job specification at all, but I must insist that you, dear reader, think about a moment what happens when these principles are used without any consideration for the human being part of the whole process. I mjst be addin that we seem to live in th “Post Fordist” age, and hereby the reference to Taylor and Ford seems to be a bit outdated. It’s not the 80ies anymore.

Why so angry?

The lack of critical thinking towards the own behavior was very evident to me when I visited some “Service Design Thinking” events in 2012 and this impression hasn’t got any better through the two books I had read. There is so much communication about sustainability et al. on these events that I feel like listening to the person leading the department for “Corporate Social Responsibility” of a Blue Chip company – I simply feel lied to.

• Someone explaining me why he created this new Headphone and I am thinking: Why the F**K would the world really need a new headphone? Aren’t there a Quadrillion models out there?
• Someone explaining the “Design Challenge” they had at the University, about to create a future sustainable car .. DAFUQ … NO car is the car of the future, with a simple equitation the damn challenge can be solved, if like 80% of the world would have access to own cars the world would be sucked dry of raw materials relatively fast. Let alone whatever kind of fuel is needed. Have fun inventing the “Flux Compensator” first.
• Designing the “Hair Dryer of the Future” – RAGE … The hair dryer of the future will be a refurbished one with remade electronics, because in 50 or 100 years it will be very hard to get the resources for what we are producing today.

As long as we use Methods that potent like “Service Design Thinking” with Ethics that seem to be void of the learnings of the “Enlightenment” and “Post-Industralization” Phases brought, I fear the danger coming from it. The chance of leaps in product development is is there, that is a result of the amazing way to work, but as long as this movement seems to be avoiding basic Ethics it’s a loaded gun on a child-yard. The lack of critical thinking and the fueling of a pure desire based economy with new products is diminishing the Method of “Service Design Thinking” to a simple Tool to add to blind consumption at best and not to a thing that “Changes the World” like the Design Thinking Community tries to imply whenever it can.

References

• Goals of the Enlightenment
• CSR – Corporate Social Responsibility
• Taylorism
• Post Fordism

Bootstrap your Express Project – A agile toolbox

When starting with a new node/express project there is a variety of tools available that help your development effort. I have started a new project and want to write down my recommendations for the tools to use.

TL;TR; You can clone a github repo here and start right away.And see the build status on travis

 NPM and package.json

Since you will have to manage dependencies in your node project, i advise you to start up with a package.json. This file contains the node modules you are using in your application. You might wanna exclude node_modules via the .gitignore file to avoid external node modules beeing checkied into git. You should now have a basic package.json file and a .gitignore file. Both need to be pushed to master right now.

A Blog Post about NPM and package.json

Express.js

After you installed express.js via npm and your package JSON  you simply generate a Application Skeleton via the express command line tool. Now you have the skeleton application and push this to git. You might wanna add jade to your dependencies.

Express.js starter tutorial

Grunt.js

Grunt helps you with linting your javascript files and orchestrate your general build. A grunt.js file in your projects root contains all the information that it needs to validate your project. To integrate it with npm aka npm test you can add a scripts.test property to your package json. Note that the npm grunt package is listed under the devDependencies property.

grunt.js docs

Mocha

Mocha is a nice Unit Test framework. You want to use it for your TDD efforts. You can integrate this nicely into your grunt.js file to combine linting of js files and unit tests. Mocha and its commandos need a little tuning in the grunt.js template in order to make it stop complaining about unknown globals

Mocha docs

Supertest

You mioght wanna test HTTP calls to your apps in a isolated way to check if not only your library code is working but your Webserver anwers with the right HTTP status codes etc.

Supertest Github repo

Travis CI

In order to let all your tests run as soon as you have pushed to your git you might wanna setup a travis ci build. Just connect travis to your repo and add .travis.yml file.

This is a superfast development chain that will help you to get superfast at implementing features into your app. The Setup time of ca. 20 Minutes will help a lot of time.

Travis setup docs for node.

You can clone a github repo here and start right away.

The seven Lamps of (Software)Architecture

I am still reading “The Craftsman” by Richard Sennet, a book that was given to me by a very smart Product-Designer/UX-Guy/Carpenter because we talked a lot about the merits on the crafty part of software-development and web-architecture. Amazon describes it as:

Why do people work hard, and take pride in what they do? This book, a philosophically-minded enquiry into practical activity of many different kinds past and present, is about what happens when people try to do a good job. It asks us to think about the true meaning of skill in the ‘skills society’ and argues that pure competition is a poor way to achieve quality work. Sennett suggests, instead, that there is a craftsman in every human being, which can sometimes be enormously motivating and inspiring – and can also in other circumstances make individuals obsessive and frustrated.“The Craftsman” shows how history has drawn fault-lines between craftsman and artist, maker and user, technique and expression, practice and theory, and that individuals’ pride in their work, as well as modern society in general, suffers from these historical divisions. But the past lives of crafts and craftsmen show us ways of working (using tools, acquiring skills, thinking about materials) which provide rewarding alternative ways for people to utilize their talents. We need to recognize this if motivations are to be understood and lives made as fulfilling as possible.

In the Book is a whole chapter about John Ruskin, a art critic in the Victorian era who had interest environmentalism, sustainability, craft and his “7 Lamps of Architecture”. These are a part of an essay that was a (slightly polemic) critic on the architectural style of that time. The “7 Lamps of Architecture” represent a take on the “good deeds” of construction things, in this case architecture for buildings. Long story short, I find these 7 principles apply to the construction of software architectures as well and I want to outline the connection here.

The Pairing Workshop v0.1

The guys at jimdo were the first ones to invite me over for a workshop. We agreed on a training about Pair programming, a practice known from Extreme Programming. Jimdo really is drinking the agile cool aid (Kanban, Visual Management etc.) and the team seemed to be fond of a training on this very specific topic.

The thing with the traffic light – stick to the rules?

Back then I  had some discussions about agreed upon rules I wanted the team  to follow (me was coaching) with a manager.  In that situation the manager wanted to do things that were against the rules or simply breaking them. It seemed more easy that way for him, the rules felt to strict in that situation. He told me the following metaphor:

“You know, when you are at a traffic light at night, it’s red, in a small street with no traffic,  and no one is around. Would you stop there for the red light phase?”

Obviously he was pointing out that sticking to the agreed  ruleset in situations where they “obviously” are not making sense is stupid or a waste of time.

Agile Waltz – Brainstorming at #p4a12 – play4agile

While visiting the play4agile conference in Rückersbach, now for the second time in a row, a lot of great feedback was given to me by the participants regarding my journeyman’s year project. A lot of different people visit this conference: From agile coaches to project managers to coding craftsmen, all types of Agilists can be found there. It turned out to be a perfect mixture of people helping me with new input on the idea.

The journeyman’s travel is an adventure in creative commons

A lot of materials need to be generated in order to organise a workshop on agile. Especially when you involve activities and do not do a frontal style powerpoint thingie. I did this the first time for the dutch PHP Conference and people really liked my new setup. A lot of Stuff is based on “Training from Back of the Room” mixed up with my knowhow.

Since I am not a professional trainer/consultant,  I do not plan to open a own consultancy in the near future and had several experiences with Open Source Software as a developer and user, I came to the conclusion that re-sharing my ideas in a format that other can use to easily build workshops is more of an obligation than an option.

A journeyman’s travel

 If you like this post, please share it on a social medium of your choice with the buttons below.

Some ups and downs brought me into the situation that I am actually without a job or contract and I have  some spare time at hand that I am going to spend with a journeyman’s travel or so called waltz.

The journeyman years refer to the tradition of setting out on travel for several years after completing apprenticeship as a craftsman. The tradition dates back to medieval times and is still alive in German-speaking countries. In the British Isles the tradition is lost and only the title journeyman itself remains as a reminder of the custom of young men traveling throughout the country. (wikipedia)

It’s a team thang

Ordering people to adopt agile is a mistake in the first place. There is no guarantee that teams will adopt the required discipline and level of cooperation in the long term withou new “enforcement” by coaches, team leads or the management if ordered to do it in the first place.

In the end all boils down to adopt new ways of working, combine it with what already is there, analyze the results and make a choice to adopt it and then further improve on the specific topic.  You could argue that a new meme is inhabiting the mind or mutating.