Sunday, November 27, 2016

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

Sunday, November 13, 2016

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

Sunday, October 30, 2016

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

Sunday, October 16, 2016

Saving the product - will you row or bail?

I recently wrote about the widespread phenomenon of the evergrowing pseudo-committed backlog. In which case a backlog really becomes a backlog in the original meaning of the word: Unfinished stuff.

But having such a huge “accumulation of tasks unperformed” (as the Merriam-Webster online dictionary defines ‘backlog’) also often leads to another problem. Housekeeping gets postponed until later. Way later.

What’s the big problem?

Look at it this way - you’re sitting in an eight (the 8 person rowing boat with nine people in it) and your boat is taking on water. Slowly but constantly.
Actually the rate at which the boat is taking on water will lead to the sinking of the vessel about 500 feet before the finish-line. In the world of projects that would be the moment your product becomes unmaintainable.

What are the options?

There are some options to deal with the situation. Let’s look at a couple of them.

  1. You could just all stop rowing, start bailing and wait for a SAR-Team to pick you up.
  2. Part your team could continue rowing, while the rest starts bailing.
  3. You could designate one “bail person” and still try to reach the finish-line with the rest of you still rowing at maximum power
  4. ... [lots of other options]

Replace rowing with “creating new features” and bailing by “doing maintenance” and you have a pretty good analogy to the situation we sometimes find ourselves in with the zombie-backlog.

To decide what to do, you might also want to add some more ‘real-life’ rowing challenges. For example the boat might stay afloat long enough to reach the finish-line if only one person is rowing and the rest is bailing, but that person would not last the whole distance. So a rotating system has to be put into place. (see any applicability to your product's situation yet?)

Or take a thunderstorm (and the competition) coming up behind you. Depending on whether the rowers are also able swimmers you might put more people on the oars and risk the boat going under just behind the finish line to still win the race. If none of them are swimmers reaching the shore becomes more important.
Or you might invest more people at the bailing buckets and therefore not be able to outrun the competition, wich will cost you the race, but still get the boat out of the water before the thunderstorm which might otherwise cost you the season. (Depending on your funding and the availability of new boats)

The non-option

There is just one thing that you can’t reasonably do – keep on rowing like there’s no tomorrow. Because if you do, then –someday soon– there won’t be a tomorrow for the product.

Next time you look at the product and the backlog you might want to consider what to tackle – the oars or the bailers.

till next time
  Michael Mahlberg

Sunday, October 02, 2016

Legacy code can be made 'easy' - legacy requirements are hard. Welcome to the Zombie-Zone...

In several companies where I supported process improvement initiatives (often by setting up Kanban systems) I saw the same effect: hundreds – or even thousands – of tickets in the (pre-existing) system.

Everybody knows that most of these tickets can't be addressed. Especially with new tickets arriving in the system at a rate exceeding the speed with which tickets can be handled.

Is there a problem at all? After all we can't work faster than we already do, can we?

IMHO this question is really besides the point. Most of the time the answer is ‘yes’ by the way. Most teams with a high workload could go way faster than they do if the took the time to ‘sharpen the blade‘ which they think they can’t do because it seems more important to cut trees. But that is not point I‘m trying to make. Much more important is the question “What is the harm those requirements do, even if nobody is working on them?”

What’s the harm? Enter the Zombies

Comparing those old requirements to Zombies is closer to the truth than one should think. To my knowledge Zombies have never been proven to exist, but Zombie requirements seem to be a fact of life!

So how do they compare? Let’s see:

  • # One: They eat Brains!
    Whether you like it or not, these old requirements still consume brainpower.

    • Ever so often someone has to go through them and check if one of them is more important than a new one.
    • Each time a new requirement arrives someone has to check if it is not already in the system
  • # Two: They come back!
    Unfortunately people don't realize that those are dead, because they look so alive from afar.

    • Customers enquire on the current state and have to be answered. This usually takes time.
    • Service level agreements and maintenance plans (which your company sold to your clients) kick in and create a huge debt. (Think “fixed in the next major release”)
  • # Three You can not trust them

    • There is almost always at least one person who thinks someone else is working on ‘that’ (long dead) requirement and accordingly they rely on it being implemented ‘soon.’ Little do the know.
    • On the other hand there almost always one person who didn't get the memo and thinks it is a good idea to optimize for ‘that’ feature - which never comes.
  • # Four They grow, especially because they are dead
    Even though it may seem counterintuitive for people from outside the software-industry, software tends to rot and decay.

    • That requirement you priced at 2 days of effort two years ago – perhaps even in a binding offer – now might costs you three weeks because the software has evolved and the database-schema now includes another dimension that wasn't there when you wrote the offer.
    • That other requirement, which was a “excitement factor” when your sales representative first mentioned it to a customer has become a “dissatisfyer” in the meantime.

Kill your Zombies! Now! Just think Triage. And do it!

till next time
  Michael Mahlberg

Sunday, September 18, 2016

How about some Wiscy in product development?

Lean and Kanban (as in David Andersons Kanban) focus very much on value to the customer – but in practice a lot of software development efforts are not quite there yet.

A humoresque (I hope) approach to increasing the productivity of software development was put forward once by the webcomic xkcd: the so-called "Ballmer Peak" Ballmer Peak

But since product development does not only consist of developing software there is more to delivering value for the customer.

And ever since 2011 when my friend and esteemed colleague Tom Breur introduced me to the concept of wiscy (yes it is an acronym, not the drink) I am torn between my instinct to urge people to flee analysis paralysis and to find out, what it is the user really really wants

You wonder what wiscy is? It is the question Why Isn’t Somebody Coding Yet?

And even though I strongly encourage early feedback through early delivery of working software, you should always make sure that you don't overdue it as depicted in this cartoon.

Wiscy

As they say in Zen and in tightrope walking – it is important to find the right balance.

till next time
  Michael Mahlberg

Sunday, September 04, 2016

Self organizing teams: The bad news

TL;DR: Self-organizing teams still need to be one thing to deserve the designation: They have to be organized!

The problem with self organizing teams

They aren't. Self organizing teams are a great thing and work wonderfully. The only problem with this is that most teams are neither. They are neither a team, nor are they organized.

What's a team again?

According to Kevin Grigsby

A team is a group of persons linked together for a common purpose. For the most part, teams consist of persons with complementary skills organized to function cooperatively as a group. (Grigsby, 2008)

Many so-called teams I see nowadays are linked together by the fact that they work for the same company and were available when the project started. Or when the project needed more people-power. Team-members sometimes have complimentary skills in a technical way but rarely in a psychological way.

And the part of "organized to function cooperatively as a group" is more often than not contradicted by personalized rewards, too much work in progress (e.g. 7 people working in 5 different projects and are all present only in one of them) and other elements of corporate dysfunction.

How about organized?

David Allen, famous for his getting things done approach to organization, has written and talked a lot about this, and according to him, basically being organized means knowing what is going on with relevance to you, what are the desired outcomes and what are the next actions.

Yet organization takes time. And sometimes specific personality traits. A lot of the teams that are "self organized by decree" have neither. And very often they don't have any frameworks on how to self-organize.

Self organized is no anarchy

Just to make this abundantly clear: "Do whatever you like" does not make a team self organized! Being mutually accountable for example means that there are ways how team members know what to expect from their peers. Striving for a common goal implies that there is a shared understanding on what that goal is and how to reach it. And of course the teams has to be able to discuss things like schedules and dependent activities with outside parties. So there has to be some knowledge on how far the team has come so far and what is up ahead for the future.

Self organized means you have to do it yourself!

Remember where the whole "self organized teams" stuff came from. It was born out of the knowledge that decisions should be made, where the knowledge resides. And with regard to team organization this knowledge is within the team.
My main point is that we don't want line managers or process specialists who have no insight at all into the dynamics of the team in question. It does /not/ mean that there is no organization inside the team. On the contrary. It's right there in the name: "self organized teams!" And perhaps sometimes it is a smart idea to have people inside the team take care of some organization. According to Grigsby "[…] leadership moves from member to member based on the topic or task assigned and the member’s skills."

till next time
  Michael Mahlberg

Self organizing teams: The bad news

TL;DR: Self-organizing teams still need to be one thing to deserve the designation: They have to be organized!

The problem with self organizing teams

They aren't. Self organizing teams are a great thing and work wonderfully. The only problem with this is that most teams are neither. They are neither a team, nor are they organized.

What's a team again?

According to Kevin Grigsby

A team is a group of persons linked together for a common purpose. For the most part, teams consist of persons with complementary skills organized to function cooperatively as a group. (Grigsby, 2008)

Many so-called teams I see nowadays are linked together by the fact that they work for the same company and were available when the project started. Or when the project needed more people-power. Team-members sometimes have complimentary skills in a technical way but rarely in a psychological way.

And the part of "organized to function cooperatively as a group" is more often than not contradicted by personalized rewards, too much work in progress (e.g. 7 people working in 5 different projects and are all present only in one of them) and other elements of corporate dysfunction.

How about organized?

David Allen, famous for his [getting things done][gtd] approach to organization, has written and talked a lot about this, and according to him, basically being organized means knowing what is going on with relevance to you, what are the desired outcomes and what are the next actions.

Yet organization takes time. And sometimes specific personality traits. A lot of the teams that are "self organized by decree" have neither. And very often they don't have any frameworks on how to self-organize.

Self organized is no anarchy

Just to make this abundantly clear: "Do whatever you like" does not make a team self organized! Being mutually accountable for example means that there are ways how team members know what to expect from their peers. Striving for a common goal implies that there is a shared understanding on what that goal is and how to reach it. And of course the teams has to be able to discuss things like schedules and dependent activities with outside parties. So there has to be some knowledge on how far the team has come so far and what is up ahead for the future.

Self organized means you have to do it yourself!

Remember where the whole "self organized teams" stuff came from. It was born out of the knowledge that decisions should be made, where the knowledge resides. And with regard to team organization this knowledge is within the team.
My main point is that we don't want line managers or process specialists who have no insight at all into the dynamics of the team in question. It does /not/ mean that there is no organization inside the team. On the contrary. It's right there in the name: "self organized teams!" And perhaps sometimes it is a smart idea to have people inside the team take care of some organization. According to Grigsby "[…] leadership moves from member to member based on the topic or task assigned and the member’s skills."

till next time
  Michael Mahlberg

Sunday, August 21, 2016

Who likes to be measured? (And what is it you can get out of it?)

Fascinatingly, the issues of time tracking always brings up heated discussions – but is it really time-tracking itself, that is the issue?

Time tracking in the Pomodoro-Technique

In the Pomodoro-Technique – a very simple but efficient approach to time management that used to be freely available – time and behavior tracking are essential. (Unfortunately the free description is no longer easily available –even though you could search for “pomodoro technique cheat sheet”– and the wikipedia entry doesn't reflect on the different ways interruptions are measured and handled in the technique – but the book is well worth a read)

Time tracking in the Personal Software Process (PSP)

The PSP uses time-tracking on a personal basis to improve learning and get to know yourself better. And it also employs behavior tracking.

Time tracking in Sports

Sport – even for the amateur – would be almost unthinkable without tracking.
“How fast did he go?” – “I can‘t tell you, our company policy strictly rules out personal performance tracking” doesn’t make for a great conversation.

And even for people who don't do their sport competitively, measuring their data seems to be important – at least the huge number of tracking devices for speed, steps, heartbeat, cadence) etc. seems to imply that people do want to know how to get better.

When does time tracking fail?

  • When it is used to control people
  • When it is used to distribute budgets - especially after the fact

Time tracking as a way to get better

In my experience people who actually track how they spend their time for their own good tend to get better in a lot of ways.

How you personally use that information depends strongly on context. If it fits your needs, you might use the true handling times of an item to calculate your actual flow efficiency as a team. Or you could use the average time you spend in meetings to convince your boss that you should have less meetings. Some people like to use the delta between their personal estimates and the actual time they spent on the items to improve their estimates – just for themselves, without telling anybody. And if the Situation calls for it you could do something completely different with your data. But very often just having the data enables you to get better a what you're doing.

So – how about giving it a try? (this article was written at a speed of 425 word in 55 minutes, which comes down to an average of 7,7 words per minute)

till next time
  Michael Mahlberg

Sunday, August 07, 2016

What is a “must have”?

Language is important – almost always.

One of my pet peeves is the word “must.“

As in “We must have the feature «x»”, or in “We must do it in this manner.“

From my understanding these are incomplete statements. The missing part is about what happens if we don't.

Complete statements would include the consequences. And thus allow the discussion of the topic. When "We must have the feature «x» to avoid paying a £5 fine” we could easily decide that it is not worth the effort. Whereas if “We must do it in this manner to avoid paying a € 5.000.000 fine” the decision is likely to be different.

So, IMHO a “must” must have explicitly stated consequences in order to make it a helpful addition to a conversation.

till next time
  Michael Mahlberg

Sunday, July 24, 2016

‘Yes’ is always wrong

Words don‘t mean the same thing to everyone. This holds even more so when doing intercultural projects. There have been extensive studies into that – yielding some surprising tools along the way.

Often I found that the simple word ‘Yes’ is a cornerstone of misunderstandings.

And for me that is true not only in intercultural contexts.

While a ‘yes’ to the question "Do you know Oliver Twist?" may mean “I‘ve heard of the novel” to some, it could mean “I've written my Ph.D. thesis on that subject” to others. And somebody else may know a person called Oliver Twist.

Because I've fallen prey to the ’yes-trap’ way too often I nowadays try to clarify my answers each time I catch myself answering ‘yes.’ And I try to avoid questions that can be answered by a simple ‘yes’. Asking “How do you know Oliver Twist?" makes both for a clearer answer as well as for a more interesting conversation.

till next time
  Michael Mahlberg

Sunday, July 10, 2016

Why is there never enough time to do it right?

There is this adage “why is there never enough time to do it right, but always time to do it over?” depicting that in the long run it almost never pays of to try to do something quick and dirty. Once again my friend and esteemed colleague Tom Breur made an excellent point on this effect in his blog post.

The flip side

But there is a flip side to that. While I seriously loathe the “quick and dirty” approach so many people still try to make work I am also weary about “getting it right the first time.“
Because "getting it right the first time" just isn’t in the mindset of the scientific method. Nor PDSA/PDCA. Nor Inspect and adapt. Nor does it cater to the nature of knowledge work.

Can we ever get it right the first time?

Of course it is possible to get things right the first time. For example if we're talking about launching a product. Or if it is about adhering to our code of conduct. And – and that is especially important in my point of view – we can work in what we consider to be the right way. Using the right tools for the job. Sharpening the saw in between felling trees. Just generally being good craftsmen.
Take the iPhone for example. Taking into account that it factually redefined the market it was obviously "done right the first time." Unlike for example the newton, which had a solid follower-ship but just didn't get traction with the mainstream.
Or take electric light, the classic example. More than 1000 experiments until there was a working lightbulb. But when it went public, it seemingly was done “right” from the way cities look at night these days.

So what’s the trick?

I don’t know the trick to getting it right the first time, but in all the efforts I have seen that managed to “get it right the first time” there was a lot of learning through experimenting (which means a lot of failures) before things actually went ’live’.

If you want to get it right...

... remember that in most knowledge-work and especially in software development, it is necessary to do it wrong a couple of times in order to find out what right really means.

...and still be willing to do it over.

Because over time you will learn. And add funny things like Copy&Paste. What they did on the iPhone. After it broke all sales records for smartphones at that time.

So, yes: Take your time to get it right. And please do not expect everything to be right the first time!

till next time
  Michael Mahlberg

Sunday, June 26, 2016

Estimates are bad (and I mean it!)

Recently I wrote about my belief that it is a good thing to estimate. After all thats one of the differentiators that distinguishes us from other forms of life on this planet.

There is a huge number of quotes one can draw from to see the difference:

“Plans are nothing, planning is everything”

-- D. Eisenhower (maybe)

“In preparing for battle I found that Plans are almost useless, but planning is indispensable”

-- perhaps D. Eisenhower or Moltke

“No plan ever survives the first contact with the enemy, but no one survives the first contact with the enemy without a plan”

-- probably Moltke or Clausewitz

It's not so easy to find out who really is the originator of each quote – and I haven't found one yet from Sun Tsu, although I am sure there is one. But the important thing is that all those quotes make a very clear distinction between the act of planning and the actual plan. And there seems to be a common understanding, that the activity is important while the artifact itself –“The Plan”– is very brittle. And has to be adjusted accordingly. Often.

In my experience the same is true for estimates: don't hesitate to adjust them to adapt to a changing situation, but gather enough information and do enough planning to start with estimates that seem plausible to yourself.

Think about harvest planning in the middle ages – having leftovers at the end of winter didn't kill villages, stretching the food for the second half of the winter didn't kill villages. Not knowing how much demand for food there is and living in splendor until Christmas would have been disastrous.

So here the art of the possible would be to do “just enough” estimation.

How much effort would that be? :-)

till next time
  Michael Mahlberg

Estimation is good (and I mean it!)

I am a huge fan of Pavel Brodzinsky's estimation poker cards and the whole “#NoEstimates” movement. But then again I think at last the amount of estimation Pawel suggest is necessary. And as even the long time proponent J.B. Rainsberger said farewell to #NoEstimates I find it helpful to distinguish between “harmful estimation” (my esteemed friend and colleague Tom Breur recently wrote about these) and helpful estimation.

Harmful estimation

Estimation can become harmful for a lot of the reasons pointed out by the followers of the #NoEstimates movements or – for example – by the reasons Tom states in his article I mentioned above.

In my opinion estimation becomes especially harmful when

  • it is used to put pressure on people
  • an effort is made to get “exact estimates”
  • estimates are treated as “exactimates

Helpful estimation

But – and it is a very strong "but" – just because it can be misused (and often is), it doesn't mean that there is no good in estimation.

A little while ago I wrote about planning already – how planning is what made it possible to evolve from hunter-gatherers to modern men.

And for me the same holds true for estimation. If there is no estimation, then there is no way to know whether it makes sense to even invest the effort to work on something. Planning and estimation go hand in hand. Even in "predictable" environments things sometimes only go partially according to plan. We have estimation all the time:

  • estimated time of arrival
  • estimated miles on this tank
  • estimated payout
  • etc.

We couldn't possibly handle our world in all its complexity without “estimating.“ Estimating if the car will fit into the parking spot. Estimating the width of a creek to jump over (or not).

So yes, I think we do need estimates. We just have to make sure, that we know where we need them. And why.

till next time
  Michael Mahlberg

Sunday, June 12, 2016

The difference between a sprint-backlog and a product-backlog

Those who learned about scrum the old fashioned way might call me names for the title of this articles, but since I run into more and more people out there who mingle both terms I think a clarification might be beneficial.

A product backlog is about what you plan to accomplish

“The Product Backlog is an ordered list of everything that might be needed in the product[…]” (Scrumguide 2013)

And it is good practice to keep these things in the bounds of the INVEST properties. This implies that the product-backlog does not prescribe how the requirements are met, but what should be achieved.

A sprint backlog is about what you plan to do

“The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.“ (ibid, emphasis added)

Big difference!

So yes, sorry mates, if you want to do scrum (and not scrum but) you'll have to do what used to be called ”Sprint planning 2“: Sit down and plan your work.
There are some options to handle things differently – like breaking down the board and “kanbanizing” that part of the workflow – but then these approaches might no longer be exactly what should be called scrum.

Cheers
Michael