Sunday, April 16, 2017

Do we have a Definition of Ready (DoR) and Defintion of Done in Kanban?

Funny you should ask – this ties in nicely with the topic of explicit policies.

Here is a short answer regarding DoR and DoD

Conceptually speaking, every station in a workflow has either implicit or explicit entry and exit criteria. The notion of a DoR and a DoD (as they have become widespread in the Scrum community) is modeling exactly this: having explicit entry and exit criteria for a system with one station.

When modeling a system with Kanban, those definitions for ready and done really need to become part of the often mentioned explicit process policies.

An Example

Let’s take a look at a simple example.
Assuming we have two stations A and B –where work flows from A to B– we look at B first, honoring the principle that we work on Kanban boards starting at the point closest to the value generation: the customer facing side.

|    station A   |    station B     |
|  doing | done  |  doing  |  done  |
|        |       |         |        |
|       / \      |        / \       |
|      /   \     |       /   \      |
|     /DoR B\    |      /     \     |
|    (   ⊆   )   |     ( DoD B )    |
|     \DoD A/    |      \     /     |
|      \   /     |       \   /      |
|       \ /      |        \ /       |
|        |       |         |        |
|        |       |         |        |

In this scenario the “Definition of Ready” (the entry criteria) for station B has to be part of the “Definition of Done” for station A. Why? Well, the “Definition of Done” for station A is the DoD for the Doing column of station A. Once a work-item leaves the “Doing” column nothing should be done with it – after all it has left one Doing column and not yet entered another Doing column.

Therefore when B pulls an item it will – or at least should – be exactly in the state it was when it left the Doing column of station A. That being said, there may of course be additional rules governing the entrance to station B (e.g. if the item is part of a multi-part workflow).

For the topic under consideration “Do we have a DoR and DoD in Kanban?” the short answer would be “yes”.

Scaling up

In any life-size system, where we have more that two stations, multiple sets of entry and exit criteria make sense – one set per station (column). Whether we focus on the DoR or on the DoD first, is a matter of focus. Both approaches might be appropriate.

Taking this further, beyond A and B we get something like:

|    station A   |    station B     |   Station C    |…
|  doing | done  |  doing  |  done  |                |
|        |       |         |        |                |
|       / \      |        / \       |                |
|      /   \     |       /   \      |                |
|     /DoR B\    |      /DoR C\     |
|    (   ⊆   )   |     (   ⊆   )    |     . . .
|     \DoD A/    |      \DoD B/     |
|      \   /     |       \   /      |
|       \ /      |        \ /       |
|        |       |         |        |
|        |       |         |        |

From my experience, it is helpful to start thinking this through from the right hand side and consider the DoRs first. But then again life is complex and depending on your actual situation there may be other approaches that make sense.

Ceterum censeo: Of course we can model everything we have in a Scrum process with a Kanban system. Both operate at different levels and Kanban is meant to be able to model existing processes. The question whether you should move from one to the other is non-sensical by definition but conversely adding Kanban to Scrum actually makes a lot of sense.

Cheers
Michael

Sunday, April 02, 2017

Todo – doing – done is not “Starting with what you do now”

A couple of weeks ago I had this discussion about the Kanban principle “Start with what you do now” and whether or not that is the same as the “todo - doing - done”-value stream we know from personal Kanban.

Thinking that the two are the same is actually a very common misunderstanding.
”Start with what you do” now has nothing to do with “todo - doing – done” and actually predates personal Kanban by a couple of years. Todo-doing-done is a simplified concept that Jim Benson introduced to use the Kanban Method on a personal level. In Kanban terminology those boards are referred to as "proto kanban" – systems that might evolve into kanban systems.

"Start with what you do now" refers to the big difference in the approach. While in approaches like XP, FDD, DSDM or Scrum, you implement a whole new process, the Kanban Method’s approach is to model what you do now. In the Kanban system.

By simply stating todo-doing-done one does not yet model the way the actual team works.
Since the general workflow "todo – doing – done" is always true, there is not yet the connection to the way your team has agreed to work and no way to discuss specific process policies.

Facilitating the evolution of this very general approach to a system that captures how your team wants to work, and building the peer-accountability that is necessary, is one of the challenges for everyone guiding or coaching evolutionary improvement processes.

till next time
  Michael Mahlberg

Sunday, March 19, 2017

Going fast without a fast-lane or an expedite lane

Does an expedite lane make you faster? And if so, why not put everything in the expedite lane?
Well, for an expedite lane to work several things have come together – Work In Progress Limits (WIP-Limits) and explicit policies, just to name the two most important ones.

When should we implement a "fast-lane" and what does "fast-lane" or "expedite-lane" really mean?

People have started to use expedite lanes in Kanban-Systems quite a while ago to handle the fact that no rule is ever without exception. If a Kanban system’s WIP-Limits do not allow for any more work to be started, there occasionally can be exceptions to the rule – production issues, "boss-tickets" and the like. To avoid having individually negotiated policies per ticket (which would rather invalidate the whole "make process policies explicit" idea) one way is to have an open discussion about handling exceptions and the rules governing those exceptions. For example: an exception like "We allow one ticket at a time to exceed the WIP-Limit of the system, but it still counts as WIP for other tickets" would be expressed by having a separate lane for exactly this ticket. Obviously this only makes sense, once we have WIP-Limits (that’s what the word kanban in the term “Kanban System” refers to) in place.
("In place" means that the limits are not only written down, but actually honored.)

What should we do if there are no WIP limits (yet)?

So what to do if you don't have WIP-limits in place and still want to negotiate some kind of special treatment for some tickets? Let's assume we want to make tickets visible that are of a higher priority than others or that are in a volatile state because of environmental issues? (As it was in the case in question: Developers already started while the ticket is still in the discovery Kanban)

Clearly in this case an "expedite" lane would not really give the same leverage it would do on a Kanban board with WIP-limits. Still I would consider those tickets to be of a different class of service which could – depending on the maturity level of the system – call for a separate swim lane or just for a different color coding of those tickets.

The other idea that might be spurred is to use a special work item type to achieve the same result. From a practical point of view this would taint statistics and metrics since there is no different way of handling those tickets. Therefore it might actually harm the system and make its future evolution more difficult.

Most importantly I would explicitly mark those tickets blocked – with a dedicated blocker type – that have to wait while these high-priority tickets are handled. And I would run statistics on those blockers afterwards. And publish those statistics!

Without giving the false pretense of having a high maturity Kanban system with an expedite lane this approach allows for explicit negotiation of the policies for this class of service that can be changed and re-negotiated over time.

And you can always move forward to a real Kanban system (one that has WIP-Limits) later.

So, how are you going to speed up

Sunday, March 05, 2017

The "definition of done" for life...

...would be a scary thing, wouldn’t it?

Yet people often ask me “When will we be done with the change?” or “When will our working agreements (sometimes also called processes) be finished?”

But that’s just the thing. In an ever changing world neither working agreements nor processes nor environments can ever be finished. In our lives we don’t try to get to the finish – I, for one, actively try to avoid that for as long as possible. Most of us just have a life. One that is well suited to whatever the environment throws at us.

For me the question is not “When will the change be over?” but “which change do we need right now?”.

till next time
  Michael Mahlberg

P.S. It’s not the finish it’s the journey. Or, to quote somebody else:

Life is not a journey to the grave with the intention of arriving safely in one pretty and well preserved piece, but to skid across the line broadside, thoroughly used up, worn out and loudly proclaiming -- WOW-- What a Ride!
~ Paraphrased after Bill McKenna, professional motorcycle racer

Sunday, February 19, 2017

If you talk about "Moving from Scrum to Kanban" you have misunderstood at least one of them!

Scrum is defined by a specific set of roles, events, artifacts and rules that can make up a software development process when the specifics for your given context are resolved and defined.

Kanban on the other hand, provides mechanisms for controlling your work and improving the way you work together with a set of principles and practices like visualization, limiting work in progress, managing flow making policies explicit and a couple more.

Kanban does not provide counterparts to the things Scrum provides – rather, it is a complementary approach to any product development approach.

You can easily build a Kanban system for any given Scrum implementation - most of the time you just have to model four or five states, identify one to three capacities and define the cadence for the input queue and the output queue. A very simple approach here is to define the

  • Stations as "Backlog", "Selected", "Implementation", "Review" and "in production" (and make them visible)
  • (bracket) capacity of "Selected" through "Review" := throughput of last iteration
  • input cadence := output cadence := iteration size
  • iteration size := your sprint size

Of course the real power of the Kanban approach only begins after this stage, when you start to improve the way you work together collaboratively. But that would be another post...

Most of the time the processes inspired by the Kanban approach end up with a much more flow-based solution than typical scrum processes, and that is what a lot of people seem to mean when they talk about their evolution.

But please don't talk about "moving from Scrum to Kanban" – that would be like saying "I don't use a car anymore, I now use a GPS" – and you wouldn't say that, would you?

till next time
  Michael Mahlberg

Sunday, February 05, 2017

We don't need 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.

Sunday, January 22, 2017

Addressing risk does not mean eliminating it

"If a project has no risks don't do it" - that's what Tom DeMarco and Timothy Lister state on the very first page of chapter one of "Waltzing with Bears", one of the best books written on risk management.

The last time I wrote about risk I focused mainly on the project level of things. Recent discussions led me to revisit thins topic within the context of the risks themselves.

Eliminating risks also takes away opportunities. Big time.

Depending on the source there are many different definitions of the term "risk." Mmost of the time it comes down to the severity of an unwanted outcome multiplied by the probability of that scenario. The names for “unwanted outcome” and “probability” differ from field to field, but the gist stays the same.
There are so many things one can do with risks.

  • risks can be mitigated (seatbealts mitigate the risk of a crash)
  • risks can be avoided (staying at home avoids the risk of a car crash)
  • risks can be compensated (first aid at the scene of a crash compensates –a little bit– for the risk of the crash)
  • risks can be reduced (distance sensors and assisted driving reduce the risk of a crash. So do speed limits)

Obviously (?) the option that avoids the risk is also the option that takes away the possibilities, the upside potential. You'd basically be going nowhere.

So when you look at your risk list and try to “eliminate them all” you might want think about other ways of addressing risk than just eliminating them altogether.

till next time
  Michael Mahlberg

Sunday, January 08, 2017

The “Pay to Learn” phase of projects

We should try to avoid waste. (Really?)

Nobody wants to create something just so it can be thrown away. (Really?)

Since “all universal quantifiers are always wrong”, those statements are probably not the whole story.

Even in lean eliminating waste is not as high a priority as one might think

In new product development – and re-implementing things in a different environment is new product development as well – a lot of effort goes into determining what the product actually is. And how to best build it.

Therefore some efforts are not waste at all, even if their results never go into production. In manufacturing and construction this is obvious for things like molds or scaffolding, but the same is true in knowledge-work as well.

Sometimes it makes a lot of sense to build something that will be thrown away, just to learn the right way to do it. Or at least a good way to do it.

Let’s have a look at Twitter for example. Twitter initially was build in Ruby (Ruby on rails to be exact). After a while it was rebuilt using different tools and techniques. So “obviously” the original implementation had to be “thrown away” at that time.
Does that mean that they shouldn‘t have started with Ruby? On the contrary – they ran with it for a couple of years. And they learned what they wanted to do with it.

But there are other things that you might not need in the later stages of product development – like dummy implementations of surrounding systems, paper mock-ups of user interaction, simulated server-roundtrips and a gazzilion more – but all of those help you learn.

And this "pay-to-learn" phase (with the willingness to throw away stuff that no longer is needed) is what often differentiates a really good product from a mediocre one.

till next time
  Michael Mahlberg

Sunday, December 25, 2016

It's a Task-Board, not a Kanban-Board (and oftentimes that is fine)

In years gone by – in the high times of eXtreme Programming for example – people used to have task boards.

Along came Scrum and for a while we used to see Scrum boards all around.

Nowadays we see Kanban-Boards all around.

Or don't we?

Without the Kanban it's not a Kanban-Board

In virtual Kanban systems (and that is what we're talking about here) the “Kanban” is the difference between the capacity of a column (the WIP-Limit of the station) and the actual work in progress.
Even though the first step of the Kanban Method is simply to “visualize work” the very thing that gives the method it's name – the Kanban – can not be present in boards that don't have a WIP-Limit.

Kanban focuses on value to the user - not on tasks

It's fine if you conclude that you have to complete a couple of tasks to create a thing that is of value to the customer, but not necessarily the most “Kanban-like” way to approach the situation. If you take the approach to it's extremes you end up with all tasks being just columns on your board
And no I don't recommend building db-, ui-, and logic-silos. But if you have them, be honest and acknowledge the fact. Change it afterwards. Start with what you do now as they say in Kanban.

So while on a task-board cards typically contain things like "Implement the FizzBuz", "Install the FizzBuzz" or "Deploy the FizzBuzz to production" on a Kanban board you would just have a card (representing a system capability) "FizzBuzz functionality" that flows through the value stream.

Sometimes a Task-Board is enough

Implementing a Kanban system is a great thing (IMHO) - especially if you want to improve the way you work together (formerly called “the process”) in a scientific way, manage flow etc. But just omitting Sprint-Plannings reviews and retrospectives and putting cards in todo-doing-done columns doesn't mean your board has become a Kanban board. But it's still a good start.

Often Task-Boards evolve to Kanban-Boards

When you start with todo-doing-done you might find that your discussions around the ‘real’ status of the tasks help you finding out how you really work together. Don't be afraid to adjust your Board accordingly. And perhaps after a while you'll be able to switch from tasks that get pushed over the board to system capabilities that get pulled.

Be honest about where you are so that you can improve to where you want to be.

till next time
  Michael Mahlberg

Sunday, December 11, 2016

Agile Documentation – a Reality Check

Working software over comprehensive documentation.

That's one of the value pairs a lot of people see (in the sense of really recognizing it) when they think about agile software development.

I don't want to re-iterate the simple fact that the manifesto just talks about valuing software over documentation and not instead. I also don't want to stress the old "While there is value in documentation we value working software more".
I don't even want to point out that the manifesto doesn't speak about all documentation, but only about comprehensive documentation.

Nowadays – where almost every software development effort is said to be "agile" – so many more questions arise.

"The code is the documentation" is sometimes true. Not so much if – for example – corporate standards enforce a development style that is far from SOLID. (You have heard about “corporate agile”, haven't you?)

"The tests are the documentation" is also sometimes true – but what part of the system do they describe?

Where is the business side?

To me, the currently worst idea in this context is the notion that user stories alone can describe the whole system. While there are many good approaches that contradict this notion (like user story mapping, impact mapping, product discovery etc.) there still is a lot of this mindset present in the wild. Especially when people use Jira and think that merely putting user stories in Jira tickets will leave the party who actually owns the product with a documentation that helps them in a year from now.

It does not. For one thing, often the level of abstraction is not suitable for everyone (how could it be – people work on different levels of abstraction). Another thing is that you can't describe a system by only listing the user stories without documenting the resulting decisions in some way. In this sense, having the user stories is necessary but not sufficient.

Think about creating a documentation around the other artifacts of your product as well. In an agile manner. When you create them. In a way that is lightweight, but strong.

And remember to refactor your documentation as well.

till next time
  Michael Mahlberg

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