Sunday, May 31, 2015

Whose job? On self-organized teams and responsibility

Basically this boils down to the statement that in my opinion there is a big difference between everybody being responsible for everything and everybody being responsible for the whole thing – and only the latter works.

The old story of four people

I once read a story about some people called Somebody, Anybody, Everybody and Nobody.

They where supposed to complete some Job that had to be completed somehow – let's not worry about details here.

It was a Job Anybody could have done – but Everybody thought Somebody would do while in the end Nobody did it.

While this is a cute little play on words, it –unfortunately– is also a phenomenon observable in peoples behavior. In his book „The Tipping Point“ Malcolm Gladwell quotes an experiment where a person in distress called out for help in two different environments. A densely populated area and a sparsely populated area.
The alarming –but understandable– result was that in the densely populated area everybody thought that somebody else would do something and so nothing happened for quite a while. In the sparsely populated are the reaction was quite different. This phenomenon has been dubbed the “bystander effect” a long time ago.

Who is responsible in a team?

Recently this question has been brought up in the context of Scrum teams, but it really applies to all kinds of teams.

You are not responsible for everything

The notion, that everybody on the team should be able to do everything and whenever a problem arises every team member should be able to fix it is not only unrealistic, the whole idea is counterproductive to the overall performance of the team. A team –as described for example in an article by R. K. Grigsby– is a group of people with complementary skills [who are mutually accountable and share a common goal].
Now, can you imagine a soccer team with all players being equally well suited for all positions? How high is the probability that such a team would have the worlds best goalie? Or the worlds best offensive? So clearly there have to be some areas of specialization –while still maintaining some skills in all the other areas– if you want to have the best team possible. But when the skills are not evenly distributed, neither can the responsibility.

You are responsible for the whole thing

But every team-member should be responsible for the whole. That is quite a difference. While I might not be able to perform a database change that is necessary for my new code I can still try a number of options to make sure that the system stays in good shape. I might track down a team member with the prerequisite knowledge. I might hold back my changes until I find some database genius on the team to pair with. I might find another design. If all else fails I might try to stop the line.
But I don't just do my part and move on and rely on the team to fix it because "the team is responsible to fix whatever goes wrong."

Let's not confuse self-organization with anarchy – self-organized on a team level means that the organization comes from within the team. Not from the outside. But this does not mean that everybody just does what they feel like. If the agreement is that Scott has the final say on database decisions, and whenever there is a decision about cryptography either Alice or Bob have to agree with it, then that may be the choice of the team, but it still is an organization that applies. And if anybody strays from those agreements –without negotiating them new– this betrays the mutual accountability within the team.

Therefore, in teams everybody is responsible. Yes. But for the whole, according to their specific capabilities. And it is a question of team organization how the team members act on this shared responsibility.

And remember "responsibility can never be assigned, it can only be assumed".

till next time
  Michael Mahlberg

Sunday, May 17, 2015

Boards: Paper vs. Digital – when, how and why

There are all kinds of boards around – Scrum Boards, Task Boards, Personal Kanban Boards, Story Boards, Portfolio Boards, Kanban Boards etc. – and all of them can come in different flavors. Two of the most distinctive flavors are “physical“ and “digital” and the difference is huge!

Even though the names differ, all the boards are in some way descendants of the kanban boards used in manufacturing, notably at Toyota.

(Of course there is a huge difference between kanban systems in manufacturing and virtual Kanban systems, therefor in Kanban the kanban is not the kanban, but that is another story)

Why use a board at all?

The first rule of Kanban is not ”You do not talk about it”.
Instead it is “Make it visible” or, to quote the correct words “Visualize the workflow” – and that is what a board is good at. In my early days with agile we called all kinds of boards “information radiators.” That term also referred to burndown charts, and burnup charts, and earned value visualizations, and defect maps, etc. – whatever was helpful, but never all of them at the same time.
The point is: information should be radiated. Made visible to everyone. And it should be the relevant information at the point where it is relevant.


Okay, so that is one part of it. But is there anything else, besides visibility?
Yes there is – such boards can also be a great way to communicate!
When they are located at places where everyone on the team notices when somebody else updates the board a lot of information is conveyed implicitly. Not to mention that the boards can serve as a culmination point for standup meetings and as a tangible way to discuss the current state of flow.

Create bite size chunks

Even if there are no WIP-Limits on the board, as long as they are physical there also is a physical limit on what can be put on the board. Just realizing – for example – that you can't put any more cards in “quality assurance” without calling some brick-layers to remodel the rooms can persuade teams to shift their work-focus.

Model your process

In Kanban for knowledge workers (the one with the capital K) the board also is a physical representation of the actual process – including process policies like WIP-Limits or cadences and such.

Electronic boards make change harder

No, of course not – at least as long as you're the administrator of that electronic board. And you don't have too many reports that rely on the boards layout. And nobody shares basic definitions like stations (a.k.a. columns or status-values) or classes of service. And you have a way to remove stations that are not empty. And you can easily inform everybody about the new process policies that go with the new board layout.
As long as all of these preconditions are met, electronic boards don’t make change harder. But as soon as you introduce central administration, create elaborate dependencies, share basic assets etc. change becomes a lot harder.
After all agile software development was meant to be adaptable and one of the most important parts is that there are retrospectives (or operations-reviews). But what good are those retrospectives if it is not possible to easily (!) adjust the process accordingly?
Where is the empowerment of the team if some tool-administrator hast to edit status values, so that the so-called self-organizing team can get their new buffer column (or something like that) on the board?

Electronic boards reduce visibility

There used to be a saying "DOORS - where requirements go to die!". Lately DOORS in this quip has been replaced by the names of more modern tools, but still there is a bit of truth in that saying.
Requirements that are stacking up in a tool (usually) don't make you feel uncomfortable. Unlike walls, tools have almost no limitations and the difference between, lets say, 350 and 850 un-reviewed requirements is quite easy to miss.

It’s about learning!

One of the great effects that can be experienced by going through the pain of really modeling the actual work we do is that we learn a lot about our processes. And adjusting the visualization over and over again is what reflects this learning. We might start with a five station (column) board and end up with a five station board. But if our board really reflects the learning it will probably have experienced times with a lot more columns in between.

(Try to) always start physical

And since everyone can break the rules on a physical board (hang a card sideways to indicate an improvised class of service, write a new rule, suggest a new cadence etc.) which is immediately visible to everybody who comes along to interact with the board, physical boards facilitate the willingness to experiment. And there is a much smaller risk to break anything (which is just not the same with electronic boards) which also contributes to a more relaxed stance to experimentation.

So – there are some good reasons to use an electronic board and even if you do use a physical board you still have to find a way to process the data electronically. But the power of a physical board, especially due to its limitations should never be underestimated.

Until next time
  Michael Mahlberg

Sunday, May 03, 2015

Why “the iron triangle” (of project management) isn’t

Over and over, people quote the iron triangle of project management - relating verbatim to the elements time, scope and cost from the wikipedia article or by the slightly less formal adage “Cheap, Fast, Good – pick any two”.

Surprise: It is not a triangle

Anyone who looks closely at the concept – or just reads the first paragraph on wikipedia – quickly realizes that the “triangle” has at least a fourth side: quality!
(But the term “devil’s quadrangle” has not yet found it‘s way into wikipedia)

And as handy as the tool “iron triangle” may seem in arguments, it really should be used with caution. Especially arguing about the quality constraint is very common in my experience. By relating to the “pick any two” adage people try to argue that “with the new time constraints we have to compromise on quality.“ And apart from the fact that “quick and dirty is very un-agile” this approach completely ignores the fact that compromising on quality usually does not get the job done more quickly but generates severe issues for the ensuing product.
The agile answer to this conundrum is to negotiate on scope instead of quality. That is what most sane people would do with tangible objects as well. I might go with a motorcycle (smaller scope) when developing a car isn’t feasible under existing time and budget constraints. But I definitely would not go with a car where “somewhere between 20 and 40 percent of the nuts and bolts are not tightened correctly” (less quality).

To me it seems much more rewarding to manage scope than to try to compromise on quality.

till next time
  Michael Mahlberg