We don't use a “process” we have working agreements...

“Yeah, well, I had to work around the process to get this stuff done for the customer.”
Doesn't that sound familiar? And more often than not people on the same team nod in agreement and work on like nothing happened. And soon somebody else says “Yeah, well, I had to work around the process ...”

But how about “Yeah, well, I had to violate what I agreed to upon how we work together to get the stuff done for the customer?”
In my experience people tend to be more easily annoyed or even upset by this latter violation of trust. But even more importantly the likelihood that people will re-negotiate their working agreements is also significantly higher.

That's why I try to convince my clients not to talk about “the process” but rather about working agreements.

Enter Scrum and Kanban

Now this is where approaches like Scrum, XP, FDD, SDSM or Kanban, to name a few, can hugely differ. Take Kanban and Scrum for example.
While Scrum is a Process Framework with very strict roles (at least for the Product Owner and the Scrum Master) Kanban is an approach for process control and process improvement. In many Scrum implementations I have seen, people have to “work around” things from the book. When –to name an example– was the last time you saw a person acting as Product Owner really having the final say on priorities?

Kanban on the other hand explicitly requires that we “Make process policies explicit” (4th General Practice of Kanban) – I like to restate that as “make our working agreements explicit.”

And once we start negotiating these agreements we actually start to “Improve collaboratively, [and] evolve experimentally,” as the 6th General Practice of Kanban describes.

I suggest dropping the chase for the perfect process in favor of finding the best working agreements (aka process policies) for the current situation.

till next time
  Michael Mahlberg

P.S.: The "General Practices" used to be called "Core Properties", but since the Kanban Condensed Guide, "General Practices" seems to be canonical.

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

Sustain! The fifth S of the 5S

(Shitsuke, 躾, according to Wikipedia)

Whether you look at Hirano or the Wikipedia article on the 5S Approach, the last pillar or practice is the hardest Shitsuke, 躾 which the Wikipedia article translates as Sustain, while Hirano translates it as Discipline.

Let‘s once again have a look at the implementations that are listed in the Wikipedia article:

• To keep in working order
• Also translates to "meaning to do without being told"
• Perform regular audits

These factory related implementations seem to translate quite easily into practices that are also known from agile software development processes or the teachings of clean code development or pragmatic programming, but are they really?

To keep in working order for example can be nicely mapped to practices like continuous integration (the practice, not the tooling) or the "no broken window rule.
Performing regular audits is at the heart of almost every agile method – be it as a retrospective or as a operations review- (as long as you don‘t call it a post-mortem).

But in my opinion and experience this is only part of it. The hardest thing about this pillar is that it is about discipline. About cleaning up even if I already worked late. About sorting things even when there is time pressure. About removing the mess I created while working while the sun is shining and the waves are luring. Agreeing on standards even though everybody seems to do it "almost the same way".
About just really following through on the other four Ss.

And for me this is the most important yet hardest to master of the five "S".

Till next time
  Michael Mahlberg

Shine! The third S of the 5S

(Seiso, 清掃, according to Wikipedia)

Other parts of this series

• Introduction to the “5S” philosophy
• The first ‘S’ – sort or organize
• The second ‘S’ – straighten or orderliness
• this article

Cleanliness or shine?

According to Hirano the third pillar is called “cleanliness”, a term which doesn't help very much in clarifying the implications for the knowledge-worker or software-development organization.

Let's have another look at the article from Wikipedia.

• Clean your workplace completely
• Use cleaning as inspection
• Prevent machinery and equipment deterioration
• Keep workplace safe and easy to work
• Can also be translated as "sweep"

Once again this seems easy – or at least obvious – when the workplace is a workbench, a car pit or any other environment where ‘real’ or physical dirt accumulates. But how do you attain cleanliness at the workplace of a knowledge-worker?

In my opinion, when your knowledge work involves computers, the sweeping might include:

• Checking the local working copy of your source code control system for orphaned files
• Removing temporary files
• Removing unused build and configuration files
• Deleting invalid contacts and obsolete phone numbers or addresses
• Or even such mundane tasks as running anti-virus software regularly
• Keeping you synced folders (e.g. Dropbox) synced
• Keeping Backups
• Removing unused branches in the source code control system

If your work also includes actual creation of code there usually is a lot of cleaning up to do at the end of a coding session. That cleaning up could include (but is not limited to) things like

• Removing duplications
• Removing experiments
• Removing trace and debug statements that are no longer needed
• Adding trace and debug statements for maintenance purposes

Even apart from work directly related to computers there is a lot of ‘sweeping’ possible:

• Re-evaluting your planned work (e.g. backlog grooming in many scrum-inspired environments) – weed out the stuff you don't need anymore
• Removing old versions of documents
• Removing outdated links from the documentation (e.g. Wiki-pages)

And so on – just get rid of stuff that doesn't add value any more or is outdated. Having superfluous ‘things’ usually confuses people more than it helps.

What are your suggestions for sweeping the workplace of knowledge-workers?

Till next time
  Michael Mahlberg

Remember: to backlog (verb) means ‘to pile up’…

And the noun means

“2. an accumulation of tasks unperformed []…“ – Merriam-Webster online dictionary

Translating the word to German makes it even worse: According to dict.cc amongst the German translations there are:

• Rückstand (lag, deficit, handicap)
• Nachhohbedarf (a need to catch up)

So clearly there are some negative connotation with regard to the term backlog. Still it has become a term with positive connotations in the software development community within less than two decades.

Yet –regardless of the positive connotations–, time and time again I see backlogs used in a way that seems counterproductive to me, Accumulating more and more “undone work” in the “backlog” - whether it is called backlog or feature-list or ticket-store or any other name.

In these cases, the items in that list really become a “Rückstand” as we would say in Germany - a lag with a need to catch up!

Of course there are several countermeasures to this – Backlog Grooming probably being the best known. But lean approaches also point to another idea on how to handle this: be very well aware of what your backlog really is and what you commit to!

Backlog vs. Ready-Column

Little’s law tells us that the average time an item spends in the system is determined by the work in progress divided by the time it takes to work on one item.

If we trust in this formula, basic mathematics tell us that if we put infinity in the numerator the result will also be infinite.

Thus, if we don’t put a limit on our backlog, we do not have a predictable time to completion.

Let‘s draw a picture of that:

Very often task-boards, scrum-boards, informal kanban-boards etc. are organized like this:

An unlimited input column (in Scrum for example it is the product-owner‘s job to keep the backlog prioritized the right way, resulting in an ample amount of preselected work for the next iteration), followed by some columns for the different stations in the process and finally an unlimited column for the finished work. While one might argue about the last one – which would make a good topic for a post on it‘s own – in general there is nothing wrong with this setup.

The problem arises when people forget that they can‘t make predictions about the whole board. Since the first column is endless (i.e. not limited) the average time any item spends in the system implicitly also goes towards infinity.

Now for the simple solution:

Only promise what you can control!

Without changing even one stroke on your board, just by communicating clearly that the predictability begins where the control begins, a significant change in expectation management might occur.

(Of course this was originally part of most agile approaches - it just happens that nowadays it seems to be forgotten from time to time…)

Shifting to an input queue

While we‘re at it: Why not change the wording to reflect the difference? While a _‘backlog’_ is a – potentially endless – list of things ‘not yet done‘ what we really want to talk about is a list of thing ‘to be done in a foreseeable, defined future‘. For me, one term that captures this concept nicely is the _‘input queue’_ – a term frequently in use in the lean community. And while I‘ve seen many (product-) backlogs without a limit, I have not yet come across an input-queue without a limit.

’till next time
  Michael Mahlberg

Busy Products - Idle Workers

Once you start investigating workflows from the point of view of the work-items instead of from the workers perspective interesting things start to show. One tool to do this is the "value stream analysis" – one of the tools in the lean approach.

One of the fascinating things that came up again when Tom did that in a simulation at the Agile BI-Conference in December '13 was this same fact, that is often the root-cause of a certain kind of workplace unhappiness: the difference between the idle-time of the person doing the job (nearly no idle time at all) and the idle-time of the ‘item under construction’ – or product – which might easily approach or even exceed 80%.

If we take one requirement as the work item and map out its way through two weeks of development in a simple two-state graph we see that there are only small peaks of work while the work-item itself is idle most of the time.

The workers on the other hand – who try to fit as many requirements as possible in their time-box – are always in a busy state!

So, if it takes forty days to deliver a net worth of one workday it is no wonder that perceptions of workload might differ 'a bit' depending on your vantage point.

After all: however busy I may feel, as soon as I try to do five things in parallel, this also means that whenever I work on one of them, four of them must lie around idling. Totaling an average of 80% idle-time per Item. When I think about this it makes me want to introduce more measures to limit my work in progress every time!

So, have a good time mapping out the value-streams of the work-items that are most important to you – you never know what you might find out.

Cheers,
   Michael