How to capture knowledge

Very simple: Don't!

In my Opinion you shouldn't capture knowledge – you should set it free!

Why are so many people keen on capturing knowledge? I spend most of my time trying to set knowledge free. That’s what my clients pay me to do.

To take an example (once again) from software development: what's the use in writing a local guide to unit testing, when there are literally thousands of well-crafted pages on that topic out there?

This is somewhat related to the question of whether you try to control circumstances or build capabilities – having a few specialists make the organization as a whole more fragile. And documentation doesn't create value when it is written – documentation creates value when it is read and understood.

There is this dialogue I witness every now an then which illustrates one of the bigger problems with the idea that information has to be captured - it goes something like this:

"Spreading knowledge" 1985

• A: Why didn't you use the new approach?
• B: There is a new approach? I didn't know!
• A: But there's an article on it in the newest loose leaf update to the SOP (standard operating procedures)!
• B: *rolls eyes*

"Spreading knowledge" 2016

• A: Why didn't you use the new approach?
• B: There is a new approach? I didn't know!
• A: But I wrote an article about it on the wiki!
• B: *rolls eyes*

Back in the days putting three ring binders with standard operation procedures in all offices and sending out monthly updates didn't do the trick of disseminating information.

And while I really love what Ward did for the empowerment of the people trying to collaborate on making information accessible, having a wiki alone doesn't help in the distribution of information either.

Does documenting really help? Especially documenting the result of a lengthy thought process? Do we understand the nature of relativity, just because we “know” that E = mc² ?

Sometimes I see people pondering over the creation of some documentation for hours. If it takes hours for people to create the documentation, then how much time should one allocate for people who read this documentation to understand it’s authors intents? About the same time it took to write it down? Half the time? A quarter of it?
Or maybe it takes twice the time of writing the documentation, because really understanding it requires at least a modicum of application.

So here’s my suggestion:

Each time something important is published in your project (e.g. on the Wiki) consider the time it would take people to understand it and – gasp – hold a session of that time and explain it to them. Keep the article. Keep it as a reference and make sure it is accurate, but don't expect people to know something just because it has been written.

In my mind I hear you argue: “But we can't afford that much time!” – Well, if you can't afford that much time, then how can you expect people to have taken it?

till next time
  Michael Mahlberg

A very simple risk-mitigation approach to tackle the truck-factor

If you have heard of the Truck-Factor you might assume that it is a good idea to have everyone on the team capable to do everything equally well. There are just a couple of issues with this idea. For one thing, you can't have the world’s best goal keeper in such a team. And –especially when the goal is to build something that hasn’t been built before– training and educating all people in all areas of expertise equally well takes a lot of time.
Furthermore, since it’s desirable to run a lot of safe to fail experiments some of the options we explore will be discarded and thus spreading the (in depth) knowledge about them through the whole team could be considered waste.

I personally like the approach of the three ”bricks” as a rule of thumb for the distribution of knowledge about “special” areas of expertise:

    /------\          \
    |      |           | 
    |  1   |           |
    |      |           |
    \______/            \  Capacity between
/------\/------\        /  0,5 and 2 "expert equivalents"
|      ||      |       |
| 0,5  ||  0,5 |       |
|      ||      |       |
\------/\------/      /

\______  ______/
       \/
 Risk-mitigation
    3 people

Where the numbers in the ‘bricks’ indicate a subjective competence that has to be negotiated on a per case basis.

This is by no means all you need to do a full capacity planning or full fledged risk management, but the “three bricks approach” is a very handy way think about managing expertise on new technologies, tools or techniques.

till next time
  Michael Mahlberg

P.S.: If you want to do in depth capacity planning you might want to look at Troy Magennis’ Excel sheet for portfolio planning for that and when it comes to risk management the classic Waltzing With Bears provides a great introduction.

The round table - or how to make remote meetings (more) fair

Don’t single people out

In my opinion the worst way to have a remote meeting (aka conference call) is to have a bunch of people sitting around a phone while one person is sitting somewhere else alone in front of the phone. Even though the “80% of communication is non-verbal” theory from 1972 is mostly misinterpreted, a large amount of communication is not in the words alone. So this dysfunctional teleconference scenario deprives the single person of all the nodding, pointing, smiling, looking at the mobile, doodling on a notepad etc. of the communication.

Even a singe camera on the side of the many and a display on the side of the one person makes it way more balanced.

Two way video isn’t a bad idea either.

Don’t use huge video conferencing rooms

In theory, it is a nice idea to have two rooms equipped with high quality video gear and really large screens, so that it almost seems as if people sit in only one room.
In the real world this doesn’t work most of the time. Foremost because the two video conferencing rooms very often are reduced to two laptops at the ends of two conference tables.

Level the playing field

Yes, we all know that in person meetings are better than remote meetings, but if we have to do them, why not ornanize them in a truly balanced manner with equal rights to all attendees?

We live in a time where bandwidth doesn’t seem to be a problem anymore in most areas. The average TV nowadays sports a resolution of 4K. Even most office displays are capable of HD or better. So why don’t we go the easy way and instead of congregating in locations where we skew the communication channels, just use state of the art video conferencing software that allows for a gallery view of a dozen or so participants from our workstations so that all the participants have the same environmental conditions?

But I don’t like to be on video

Why not?
What is really worse when you’re on video compared to a real live meeting?
Of course you can’t (or shouldn’t) be in front of the camera in pyjamas and you probably can’t play World of Warcraft while on the call, but then again: would you do that in a live meeting? And if the virtual meeting is not that important, then it’s probably a good idea to say so and find better ways to make use of the time for all parties concerned.

But our company policy doesn’t allow for it

Bummer.
But hey, the upside is that you just identified a really huge cultural problem, that you and your colleagues can work on.

till next time

  Michael Mahlberg

Finally, once we become agile, all the planning goes away, doesn’t it?

No, it does not.

To quote a few things

“Responding to change over following a plan” -- http://agilemanifesto.org

The manifesto does not say “don't plan!”

“In preparing for battle I have always found that plans are useless, but planning is indispensable.” - attributed to Dwight D. Eisenhower

The major difference between agile planning and old style planning is that agile planning doesn’t happen up front, but just in time.

In mathematics there is a concept of an inherent complexity of a term that remains constant. A friend of mine explained it to me many years ago, but I can’t find the “law” related to this topic on the net. The basic idea is that it is quite easy to make a formula more simple by –for example– introducing a formula sign for the integral, but the overall complexity of the term remains the same. Introducing the integral sign only moves the complexity to a different place.

What kind of planning

Something similar seems to be true for planning. Without having at least some kind of plan it is hard to keep a group of people marching in the same direction, so you have to plan at least a little bit. If you ever hiked in an area without roads and pathways you probably noticed that it is only possible to plan in detail for the stretch of the way that you can actually overlook, but without having an idea about your next major destination you might end up spending the night in the open without anything to eat or drink.
So there seem to be at least two kinds of planning going on. Whether you relate those two types of planning to ideas like release planning, iteration planning, and task planning or not is of course up to you. (Some people might also think about release planning, sprint planning 1, and sprint planning part 2. But please remember that not all agile is Scrum)

Now for the big question:

Who’s doing all this planning in agile?

Most of the time when adopting agile you get rid of the fact that other people plan your work. But the flipside is, that –most of the time– the whole team has to take on the responsibility for planning. All of them. So don’t think that getting rid of other people planning your work also means getting rid of planning itself. Agile is very much about common sense, but that doesn't make it easy. Inherently tough things stay tough.

So, what are your plans?

till next time
  Michael Mahlberg

Let’s be Pirates... or Privateers

I've written a lot about self-organization lately and how difficult it is to garner the right ‘amount’ of self organization.

An interesting side-note was brought to me at a dinner conversation in a dark and shady tavern by sea, illuminated by the flickering light of the candles while the sea roared on the cliffs and a chilly wind... oops ... sorry... I got carried away.

The side-note has to with pirates though. Or, more to the point, with privateers and how self-motivation and extrinsic motivation can go hand in hand.

It has often be quoted that the real pirates of the Caribbean where amongst the first in modern times to have democratic organizations. For example the captain - although master over life and death during his tenure – was actually elected and the loot – pardon me, the prize) – was divided fairly (not evenly!) amongs those who participated in the venture.

But there is another aspect that I failed to see earlier. From what my friend told me, one of the reasons for the demise of the once great armada was the utilization of small independent, autonomously acting, self-motivated units. Privateers. Though historically this was certainly not the only reason the idea has a strong resonance with me and it nicely ties in with a lot of modern management approaches.

• The privateers did what they loved to do. (The love for the seas amongst sailors is proverbial. And privateers – unlike the official Navy – were not in the habit of pressing people to service) => Purpose
• The better they were, the more rewarding hires were available and the higher the compensations were => Mastery
• If the results of their actions fitted within the Letter of marque the privateers were at liberty to do whatever they deemed necessary or helpful. (No dress-code, no imposed rules on how to change the guard etc.) => Autonomy

When I look at Privateers this way, they really have a lot in common with modern teams – although they usually had a way more grim work than our teams have nowadays.

Nonetheless the autonomous teams overthrew their centrally organized counterpart by a huge margin. Despite the fact that they were heavily outnumbered. I see some similarities with modern organizations.

till next time
  Michael Mahlberg

Why self-organization is not like ’60 paces’ ::spoiler alert::

There is this game that people play during agile trainings called ‘60 paces’.

It is well known and shows how much more efficient self-organization is compared to a command and control environment.

I'll leave out the details of the game here. You can look them up on tastycupcakes.org via the link above, but if you haven't played the game yet, you would be depriving yourself of a great learning opportunity by looking it up. Allow yourself to be surprised, I think you will get much more out of it that way.

So this is more like an inside blogpost for people who have either played or conducted the game in the past.

In my opinion there is one thing missing in the game – a round zero. Where you just let people do whatever they want for two minutes. And ask the control questions (see game description) afterwards.

Then continue playing as described in the original description.

From my point of view this approach illustrates one aspect that is not addressed by the original simulation and which is also very often forgotten in naive lean and agile implementations:

Without a known and clear unifying goal there will be no progress towards any goal.

till next time
  Michael Mahlberg

Self-organization does mean anarchy

From the “I don’t think that word means what you think it does” department.

<rant>
Ever so often I hear people argue that self organization does not mean anarchy. (Especially if the team wants to use non-corporate software, hardware, tool, etc.)

To me this seems quite strange because the opposite is clearly true.

Anarchy does mean without (an) rulers (archos) - or so wikipedia and my history books tell me.

Of course Anarchy (with a capital A) has so many connotations nowadays that most of them are not appropriate for self-organizing teams and I would strongly advise all self organizing teams not to take on the negative traits that have nowadays become associated with anarchy.

But stretch the boundaries – if the team is self organized, who is to tell that they have to work from their assigned workstations? Why shouldn't they put graffiti – sorry, architectural diagrams – on the walls?

We all live in a social system where we can only flourish to our fullest potential if we do not harm other people, but we have to question our rules relentlessly.

In my opinion it is a contradictio in adjecto if you tell a team to “... be self organized, but follow corporate policy to the letter ...”.

</rant>

till next time
  Michael Mahlberg