Organisational change and responsibility

I gave a talk about organisational change responsibility at Agile Islands 2018. Here are the slides.

Responsibility - from drama to results from Ari Tanninen

Self-organising to a pub?

I have seen managers struggling with self-organisation, to the point of hesitating to lead, because “it would not be self-organising”. As much as I hope for a replacement to prevailing tayloristic / Theory X management, this goes too far and is throwing the baby out with the bathwater.

Introduction to The Responsibility Process

I gave a talk about Christopher Avery's Responsibility Process today in Agile Finland's Helsinki Coaching Circle.

Introduction to the responsibility process from Ari Tanninen

Once again thanks for all attendees for the opportunity to gather and clarify my thoughts, get some practice talking, and always for the laughs. :)

The double diamond process

A nifty depiction of a design process is the double diamond. I have found it useful for clarifying the intent of product development activities, and the purpose of various design tools. The process was originally developed in 2005 by The Design Council in UK (sources one and two), but many design companies have their own version of it (examples one, two, three, and four).

Process Design Game

Last year I designed a simple design game for co-designing business processes and/or use cases. Since it has been used commercially in at least two companies, I decided to publish it under Creative Commons just to avoid any confusion with copyrights.

User experience in B2B - meh

The other week I was discussing the all-too-common difficulty of selling user experience design to executives and bigger companies in general. Startups seem to get the importance of user experience, and certainly companies whose customers are consumers. But why is this so difficult for big companies who are in B2B biz?

Definition of "high-level"

high-level

[hahy-lev-uh l]

adjective, adverb

1. A management speak qualifier that removes the demand to be fact-based, coherent and cosmologically feasible from the following presentation, concept or idea.
2. Warning flag for implementors and other people connected to the real world, such as engineers and customer service personnel.
3. Indication of abstraction that is just a little bit too high
4. A warning sign for imminent constraint-free hand-waving and concepting

Update Feb 6th 2015:

See also: High-level overview.

Management void

Too many companies are in trouble because no one is managing them. In the scope of this blog entry, management means managing work so that it works, and looking after the organization so that it is functional (and I really don’t care to get into the difference between management and leadership, or their various different flavours).

Function of design in new business development

Yet another take on using user-centered design methods in not only software but product and business development in general. The examples are mostly the same as in my previous talks, but the angle is different, and combines Customer Development / Business-Model Generation / Lean Startup as done by Marko Taipale with User-Centered Design.

This talk was in Estonia at Agile Saturday X.

Design up front is back! v2 from Ari Tanninen

Design up front is back!

I gave a fifteen minute talk about using design methods to boost software product development at Tampere Goes Agile 2013. This is probably the best talk I have ever given, I really like the fifteen-minute format. Here are the slides. The core message of the talk is:

Working software is an expensive way of getting user feedback when compared with role-play or design prototypes.

 

Design up front is back! from Ari Tanninen

Everything is interconnected

Everything in life is interconnected. People are connected via social networks, family ties, organizations, and their employers. The economy is a global net that reverbrates with the slightest of changes. We are connected to the same economy as consumers and through corporations as employees. We share the same ecology, and keep using and re-using the same ingredients through the carbon and nitrogen cycles. And after all, we are all star stuff.

But most importantly, everything effects everything sooner or later, and for every action there is a consequence. Kall it karma, or TANSTAAFL, or cause and effect. Regardless, this forms an interesting basis for morality. As human beings everything we do has consequences and we should keep those in mind. Because sooner or later there will be payback for all of our actions to either ourselves, or to someone else. And since everything is interconnected, the consequences of our actions impacting ourselves is just a matter of time. It is easy to miss this though, since feedback loops can be long.

The missing link between business need and software development: product design

I gave a talk about improving IT systems with participatory and user-centered design at the Wildcard 2013 conference in Latvia the other day. Here are the slides and video.

What's in a value?

I've been meaning to write this blog post for a long while now. I don't really know why, but it's about a realization of some importance to me. And by value I don't mean the usual "our company's values are openness, honesty and integrity" bollocks. You know, the part of the holy mission-vision-strategy-values quad that companies use as repairkit when they have lost one or - more often - all of the four.

So what is a value, for a person? Here is my definition:

A value is something a person values in her or his head that cannot, and should not, be justified or rationalized.

Now what?

For all intents and purposes I've abandoned my blog years ago. I've been thinking about starting to write again, but in the past three years my interests and aspirations have changed dramatically.

Things that have changed:

• I finally understand my values and the kind of work I want to do
• I finally understand why I've been miserable as software engineer
• I've decided to change careers, I don't want to write software anymore
• This Agile and Lean thing I had going on? Forget it. Not going to save the world.
• What will? Human creativity, leadership, and the bloody Deming Transformation. And as long as we're operating in a capitalistic context the primary tool for change must be business.
• I am almost finished with my MBA
• Current interests: user-centered methods, philosophy, coaching, business & organizations, zen

Should I delete this blog and start a new one, or change this blog's direction, I wonder? Once again, I am thinking too much and doing too little.

So I decided to write this post and just get on with it.

Have to do something about this ancient butt-ugly layout for sure.

Agile Saturday talk: Scrum is Not Enough 2.0

I gave a talk in Agile Saturday organized by the good people of Agile Estonia. It was about how Scrum is not enough for solving the problems that a good Scrum implementation surfaces. Here are the slides.

Scrum is not enough v2.0 from Ari Tanninen

Thanks to all organizes and especially Stan and Heiti who took such good care of us! It was a fun day with lots of excitement and good energy. :o)

I would love to hear your comments on my presentation! And if you are one of the people I shared a meter of beer with yesterday evening, drop a comment, too!

Update: I am on video, too!


Scrum Is Not Enough v2.0 from devtraining.ee on Vimeo.

OO Day 2009 presentation: Scrum Is Not Enough

Here are the slides for a presentation I gave with Marko today at OO Day 2009 in Tampere, Finland. We had around 400 people in the audience - more than there were attendees in Scan-Agile 2009!



Since the presentation was in Finnish so are the slides. I might write more on the subject later on.

Scrum Is Not Enough from Ari Tanninen

Paper on TDD and architecture

Couple of years ago me and Marko Taipale wrote an experience report on our experiment in using TDD (in the strict, XP definition) to build a game platform. The idea was to try and see if an architecture would emerge like XP claims (it did not).

Originally the paper was intended as an experience report for the XP2008 conference but was rejected due to insufficient research data. It is fair to say that the paper is our take on the TDD controversy that raged at that time, and we did write it at Jim Coplien's suggestion.

The paper is a couple of years old but since at least two people asked for a copy I decided to put the paper online. Perhaps you will find it interesting.

xp2008_experience_report_marko_taipale_ari_tanninen.pdf

Testing In Agile presentation

I gave a thirty-minute talk about testing in agile projects in December's Agile Dinner in Helsinki. Here are the slides.

Testing In Agile from Ari Tanninen

It was nice to have so many participants from TestausOSY visiting our dinner! Too bad not many stayed for the beers (read: actual conversation) afterwards.

Dr. Deming's Management's Five Deadly Diseases

Here is an Encyclopaedia Britannica Film from 1984 featuring Dr. Deming himself: Management's Five Deadly Diseases. Awesome.

Open Space Session: Think!

Intro & thinking principles

This blog entry is about the open space session with similar title I held at Scan-Agile 2009. It took me a while to write since I have never actually organized my thoughts on this. My intention was not to host a session but after hearing fifteen sessions announced about tools and methods I felt compelled to since a very important ingredient was missing: thinking and the principles that guide thinking.


Photo courtesy my fellow conference organizer Ari Tikka.

I will start this blog like I started my open space session: let me share with you the three principles of the most productive Scrum team I have ever been in. These principles guided our everyday life from choosing technologies to improving our ways of working. Agile architecture absolutely requires them. But even though these principles have arisen from agile software development, they are valid for most aspects of life. I exercise them daily in my personal life.

The thinking principles are:
1) Do only what is needed
2) First the problem, then the solution
3) Challenge everything