Showing posts sorted by relevance for query most important. Sort by date Show all posts
Showing posts sorted by relevance for query most important. Sort by date Show all posts

Sunday, March 31, 2019

How to visualize the (IMHO) most important metric of the Kanban method

In my humble opinion the Lead Time Distribution is the most important metric in the context of the Kanban method.

Your mileage may vary, but that would be the topic for another post.

A brief mailing list discussion about ways to get this in Excel triggered me to make a list of some of the approaches I use to get to that metric. (Only some of them with Excel)

Content:

  • Google Spreadsheet approach
  • Hand-rolled Excel
    • Percentiles for given durations
    • Dates for given percentiles
  • More versatile hand-rolled approach w/o Excel
  • Closing thoughts

Plot and percentiles in Google Spread-Sheet

I would feel remiss not to mention the works of Emily Webber: https://emilywebber.co.uk/a-tool-for-tracking-kanban-projects-that-you-can-cut-out-and-keep/

This gives most of one could want for the evaluation of a physical board.

Unfortunately, it isn't Excel yet, but "only" google-docs. Exporting to Excel "kind of" works, but the most important formatting is rather distorted, so I wouldn't exactly recommend that route to get to Excel.

Maybe it is right for you, maybe not. Give it a shot.

Percentiles per given durations in Excel

I used Excel quite often to generate percentages (not yet percentiles), usually inversely by pointing out the percentile that a given duration falls into.

This leads to heat-maps like the one on the right (from my talk at the 2018 LKCE ) but you don't necessarily get the exact numbers for the percentiles – and it is achieved by a concatenation of manual bin sorting, Summing up the results for each bin and comparing that to the maximum number of occurrences for this type of work.

You can find a simplified example (for only on type of work) in [this Excel-Sheet.](http://www.consulting-guild.de/files/ExampleHeatMap-GeneratedData.xlsx) The raw data is in the first tab, the bin definition in the second and the evaluation in the third. All tabs are named accordingly.

Durations for given percentiles in Excel

Excel already has a built in function called PERCENTILE which yields the mathematically correct percentile over an array of numbers (e.g. lead-times)

For the Emily Webber Data this looks like this: (In the German Version of Excel they translated the names of the functions and hence PERCENTILE is called QUANTIL)

The more flexible approach (without Excel)

Still, sometimes this is not quite what you need and the whole structure of the "chains of Excel spreadsheets" which tends to arise from the Excel-based approach tends to become too brittle (or too solid) after the first two or three improvements-loops.

Nowadays I recommend evaluating Jupyter Notebooks for this kind of scenario. It seems to require programmings skills, since the statistics approach is based on (amongst others) Python, but actually it is quite approachable and most people who are comfortable with complex Excel sheets tend to fall in love with it quickly.

My colleague Martin for example is using this approach for a very flexible evaluation of data collected from physical boards.

It can look like this, but can be easily extended if you need more complex statistics or shapes.

Closing thoughts

IMHO – provided the work-items are coarse grained and the time you want to inspect is not too long – oftentimes it pays to ditch electronic tools in favor of more mechanical approaches as outlined in the talk I mentioned above. (Unfortunately in German)

And for more elaborate mathematical elaborations while still working in Excel I find Troy Magennis Excel-Sheets an extremely helpful ressource.

till next time
  Michael Mahlberg

Sunday, September 30, 2018

The Product-Owner as an antipattern

Do you know a project with a real product owner?

The clue is in the name. It actually consist of two parts. ‘Product’ and ‘Owner’. Most POs (as product owners in my neck of the woods tend to be abbreviated) neither have a product nor do they own it.

Recently the PO topic came up in a discussion about The Rules of The Scrum Process. (FWIW: Scrum is not a process but a process framework and thus the ‘rules of the game’ apply to the meta-level and transcend only transitionally to the implementations)

Case in point: Does Scrum allow the PO to be present at the Daily Scrum? Notwithstanding the endless options to find the right answer (see sidebar),

e.g. due to the different possibilities to emphasize todays scrum guide’s “The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.” –one could either stress the internal meeting part or the others are present part, or the multitude of possible interpretations for the quote “Anyone who needs to know what’s going on with the project can come to the daily scrum and listen”[emphasis added] from Ken Schwabers original book, [p40].

the most important question for me was:
“Why is it so important to answer that question?”

It turned out that the developers in that team where afraid that the PO would be worried by what he would hear in the daily scrum, the scrum master was afraid that the developers would not speak as openly as necessary if the PO were to be present.

For me this situation contains an alarming amount of alarm signals with regard to the scrum values of openness, courage, and respect as well as for the scrum pillar of transparency.

If Product Owners are frightened by the things they hear in the daily scrum –and worse: take action based on the information they gather from the daily scrum- the Scrum Master has a lot of work on her –or his– hands to establish transparency and foster courage. (But please keep in mind that it’s not yet possible to install values.)

A tangent on this topic was that the Product Owner doesn’t understand the developers and thus should not hear them talk amongst themselves about challenges they face. To me, “The PO doesn't understand the developers” is a very good description for a (team-) culture that is quite dysfunctional for Scrum.

[So perhaps scrum isn’t the best choice for the situation at hand - how about trying FDD or DSDM? But I digress]

Of course the Product Owner doesn't have to know everything. Quite the opposite actually: they are even encouraged to delegate. According to the 2017 Scrum Guide: "The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable."

Of course, if the Product Owner does delegate some of their work to the team, that would probably turn up on their task-list as well. And since “Ensuring the Development Team understands items in the Product Backlog to the level needed” is also part of the PO’s responsibilities, they would have to interact with the team even more. Probably even become part of the team. Which would nicely fit with the old eXtreme Programming value of the on-site customer.

So why did I call the Product Owner an anti-pattern?
Because most of the time they aren’t. They neither have the final say regarding the ordering of the items to implement, nor do they have a real chance to influence the economical outcome of the work. They simply don’t own the product.

So perhaps –whenever we see a Product Owner who isn’t– let’s take a step back from using the Scrum term of product owner and look around for things that are actually happening (Kanban people might call that: “start with what you do now”).

Perhaps even try to look out for some other agile process templates which maybe fit your reality more closely.

till next time
  Michael Mahlberg

Sunday, February 10, 2019

Why all the boards for your lean and agile teams should be visible all the time

A simple answer would be: spatial memory.

A slightly longer answer could be: spatial memory and confirmation bias.

(Oh, and by the way: They should be visible all the time only for the people who need to see the information on them)

But let's put that into context. Why are spatial memory and confirmation bias important for the way we use boards in Agile teams?

As many people have pointed out in the past Agile doesn't fix any problems, it just makes them visible, so that it is easier to do something about them. One of the tools agile teams started to use early on to facilitate this is visualization. A team, working towards a goal, visualizes the information they need to know about. This can be all kind of information –which might be a topic for another blog-post–, but one of the most prominent visualization techniques is the taskboard. Taskboards are especially helpful for knowledge workers because the very nature of our work makes it impossible to directly perceive the status of the work – let alone knowing how much work is currently in progress. The Kanban method went so far as to have the notion of ‘making invisible work visible’ at its very heart, albeit many so-called Kanban-boards are merely task-boards.

To really make use of this visualization we need to leverage spatial memory and counter confirmation bias.

Why spatial memory?

If the great benefit of (Task-)boards is, that they make work tangible and agile only makes problems visible, then it is important, that we help our brain to make use of this information. With a visible board, it is plausible that the amount of information displayed is still manageable. With electronic boards on the other hand: not so much.

Physical work (what David Allen –of getting-things-done fame– calls "cranking widgets") takes up a defined amount of space and most of the time also a defined location. So, for example, when working on some home-made stuff, during sanding it is easy to remember that “the blocks on the left side of the table still need work, and those in the upper row need some special treatment because they felt ’strange’.“ In this case, ‘left-hand side’ would be associated with unfinished and ‘top row’ with special treatment needed.

Likewise, if we have a number of boards physically placed throughout the workspace, location gets mapped to meaning. After a while, we just ’know’ that we have to look at the board on the wall behind Jenny to see the current status of Portfolio initiatives. Or at the board in the hallway to see the state of affairs with regard to the committed user-related features.

One could argue that having electronic boards for the same information works almost the same, because with electronic boards we just ‘know’ that we have to go to «boards»->«companywide»->«MyDepartment»->«Initiatives» to find the portfolio information and we have to go to «boards»->«MyDepartment»->«Stories» to see the committed user-related features. But this draws on a different kind of memory, which is accessed a lot slower. And takes more energy to activate. At least that's one of the learnings I took away from Sharon Bowman’s “Training from the Back of the Room”.

Even our figures of speech are quite informative here. Getting a ‘picture or the situation’ or having the ‘big picture’ are good examples of this.

And glancing at the walls just takes somewhere between a fraction of a second and a couple of seconds, depending on how much information you want to absorb. It even happens without conscious effort. Just walking by the feature-board in the hallway and the portfolio-board behind Jenny's desk gives you a certain amount of situational awareness - whether you want it or not.

What about confirmation bias?

Unfortunately, even though one of the original ideas behind Agile approaches was to make problems visible most humans are influenced by confirmation bias. We tend to look for helpful clues to help us to confirm whether a course of action is feasible. In earlier times that was helpful – and it even is helpful today as Jeffry Levine explains convincingly on quora. We wouldn’t be able to act in the world if we didn’t apply filters to the huge amount of information that comes at us all the time. And re-thinking topics we already thought about would –most of the time– be a waste of the rare resource mental power.

One of the implications of this is that we –in general– don’t go out there and look for things that are not as expected. We probably won’t open the portfolio board every day to check whether the portfolio item that our current feature relates to just got flagged ‘canceled.’ And neither is it likely that all portfolio managers look at the detail boards all the time. But, in my personal experience, they develop quite a keen eye for an agglomeration of blockers on features if they pass that wall several times a day.

To help people tackle problems and issues they care about it does help to make this information visible. Especially in those cases where nobody would actively look for the unwelcome information.

It's called visual management for a reason

Even if Agile and the Kanban method have both somewhat evolved from their roots in Lean, the whole board idea is based on visual control and the enormous lever for self-management it provides.

So, if you use boards, make sure the important ones are visible all the time to the right people.

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, February 14, 2021

How to do physical {Kanban|Task|Scrum} boards virtually

As I’ve mentioned earlier most of the time it is a good idea to start visualization with a physical board. And very often it is a good idea to stick with that. For all the reasons that make it worthwhile to start with it.

One of the biggest advantages of a physical board is the one thing that command and control organizations perceive as it’s biggest drawback: A physical board knows nothing about the process.

The fact that the physical board knows nothing about the process forces the people who use it, to actually know about their working agreements. And to negotiate them. And to make them explicit in some way. Well, at least if the want to remember the gist of their long discussion from Friday afternoon on Wednesday morning.

As my esteemed colleague Simon Kühn put it all those years back: The intelligence is in front of the board.

But we’re all working remote now

Now, that we‘re not in a shared office space anymore, real physical boards are hard to do, aren’t they? Well – yes and no. If you look at the important advantages of physical boards, they are easy to replicate with today’s electronic white board solutions.

Whether you use use google drawings, miro, or conceptboard –to name just the ones I’m familiar with– is mostly a question of taste and, more importantly, legal and company policy considerations.

Using a simple collaborative whiteboard enables people to have most of the advantages they can have from physical board, while retaining the advantages of remote work.

What are the big advantages of a physical board?

A physical board can easily be changed by everyone. Just pick up a marker and draw something on it. The same is true for electronic whiteboards. In both cases it is a good idea to also have a talk with your colleagues to make sure they are okay with the additional (or removed) thing you did to the board.

One could say “individuals and interaction over workflows (process) embedded somewhere in a ticket system (tool)” – just to reiterate the first value pair from the Manifesto for Agile Software Development as an argument for “physical” boards.

Physical boards have extremely quick iterations. Trying out whether a new policy makes sense takes just a pen, a sticky note, a quick discussion and a couple of days (sometimes only hours) to see if it works. Conversely, with ticket systems even proposing a change to the admins often takes weeks and needs a predefined concept and sign-off. Not exactly agile. But with electronic whiteboards you can do just the same things you would do on a physical board. Which is why they provide tremendously quick feedback loops.

And as Boyd’s law of iteration says: speed of iteration beats quality of iteration.

If you decide to add a new status on a physical board or add new meta-information on a ticket, you don’t have to migrate all the old tickets. And you don’t have to coordinate that meta-information with the names of the meta-information of all other projects in the organization. Another huge an advantage of physical boards over ticket systems. And you can achieve the exact same independence with electronic white boards.

But where do the details go?

When I have these discussion in real life, I usually get a couple of questions about the details. Let’s look at two of them.

Q: On a physical board I used to write my acceptance-criteria on the back of the card. I can’t do that with an electronic whiteboard.

A: True, but then again you can put a link on the card on the electronic whiteboard and that can point to almost any place you like. For example a wiki-page that contains that additional information.

Q: But if I use a dedicated bug tracker (the origin of Jira) or any other ticket system I have all those nifty fields for details.

A: But do you need them on the card? Wouldn‘t they better be put on a documentation page?

My general advise here: put only meta-data on the card and all the other information in appropriate systems like a wiki. This also gives you the opportunity to put the information where it belongs in the long run, instead of putting it on the perishable ticket. On the page related to the ticket you can just link to or include that central information.

But what about metrics?

One of the things that gets lost with the ”physical” board is the automated transcription of relevant data for statistics. And I have to admit that this is a real disadvantage. With an electronic whiteboard you could either write a little plugin that tracks the movement of the cards or do a very strict separation of concerns and use different tools for different topics.

A word of caution – writing that little tool for the electronic whiteboard might not be that easy, after all. And even if you were going to do that eventually, it would be a good idea to start by collecting the metrics manually.

Either way: if you start with the metrics that you really need now and create your own tools for those –based on spreadsheets or databases, after all you’re in the software development business— you have a huge advantage over the metrics provided out of the box by many tools: you actually know, what the data means.

And some of the most important metrics are actually easy to evaluate and some of them even easier to capture.

Just give electronic whiteboards a try – if you adhere to the same ideas and first principles that guide your usage of a physical whiteboard you should reap almost all of the same benefits and get a couple of helpful things like links on the cards and enough space for dozens of people to stand in front of the board on top.

till next time
  Michael Mahlberg

Sunday, May 24, 2020

Error: Customer unavailable! How do you manage flow now?

It’s Wednesday morning, you try to get an appointment with the stakeholder who is the most important customer for a work item that your team started to work on on Monday. And now you find out that they’re out of the office for the coming two weeks.

Now what?

You and your team invested 2 days already (for a 7 people team that would represent 14 person days of effort), and you all would really like to work on the topic.

After some inquiry about the requested feature it becomes clear that no one else knows what the requirements on this work item really are and now you’re faced with a tough decision: mark this card as blocked and become ‘idle’ as a team, or abandon the card (discard it) and let the customer bring up the topic later again?

There are drawbacks to both approaches –after all the situation is bad to begin with– but both follow the mantra to “accept reality” and are way better than following the wiscy approach where you start defining the result (e.g. by programming) without even knowing the requirements.

Let’s look at the implications of each approach.

For the following assume that we manage our work using ideas from the Kanban method and thus have the flow of our work visualised on a board including WIP-targets.

Option 1: put a blocker on the card if the customer is unavailable

Putting a blocker on a card is the normal way to make it visible to everyone that there seems to be no way to progress on the work represented by that card in a sensible way. At least if you apply the Kanban method. If your WIP-Target (mostly known as WIP-Limit) was already honored this creates a tremendous amount of slack for the team that worked on that card. In most cases more than you actually want and more than is wise from an economic point of view. But it reflects reality. If the relevant stakeholder is not available for an extended period of time this could be really expensive.

The important point here is that blocking the card fosters learning inside the system. People might come up with policies to make sure that the customer is actually available for before starting to work on the work item. Or they might come up with completely different ideas on how to mitigate this situation. Remember: Documentation isn’t bad per se.

Option 2: discard –or abandon– the work

On the other hand there is always the option of starting something new. In a system with a known capacity that usually means abandoning the old work – after all there are good reasons to limit the work in progress in a system. Amongst other reasons, allowing more work in has a very clear and negative impact on the lead time for the system as a whole. Discarding the work doesn’t necessarily mean that all the work already put into this item will be lost. It just means that the work item has to start its journey again from the far left side of the board and it might even take a couple of replenishment meetings (where stakeholders decide wich item to commit into the system) before work is started again. Some of the work will probably have to be redone because the world will have changed by the time work on that item again.

Here the systemic aspect is that discarding or abandoning a card fosters learning outside the system. Especially upstream, at the customer’s end. Customers might come up with the idea that it is a good idea to have more than one person who knows what the reasoning behind a requirement is. Or they might develop other smart ideas on how to handle this. Remember: there once was a whole body of knowledge called requirements engineering.

Either way: it is a chance for learning

Both approaches offer a chance to improve the system. While the former is targeted more at the system itself, the latter is target more towards the customer interface. Both are legitimate ways to “accept reality” and thus are way better than the alternative: wishful thinking and hoping you will guess the customer’s needs correctly.

till next time
  Michael Mahlberg

Sunday, April 26, 2020

Handling recurring work - some options from Lean and TPS

As someone who draws from the Kanban Method and its Lean and TPS ancestors when supporting change in organizations I regularly come across the question of “how to handle recurring work?”

And while neither the Kanban Method nor I have definite answers there are some options from Lean and TPS that can be integrated nicely into the workflow of 21st century knowledge workers.

I originally got the basic idea to adapt Kamishibai boards (see below) from @LukasDonSchmidt and I would have preferred to just link to a blogpost of his, but unfortunately I can’t find that out in the wild. Yet. (Didn’t you intend to write something, Lukas?)

Capacity allocation and recurring work

Assuming that you visualized your work using some kind of board and you use WIP-targets to manage flow, there is one challenge (amongst many others) that often arises. Small, recurring units of work that “need to” interrupt the flow of the big main work items. In an ideal world we might just strive for the knowledge worker’s equivalent to single-piece flow, but in the real world that is not always attainable or even feasible. To take a small business, non-IT example: the big Work Item might be an essay that needs a week to finish, and the small items could be fetching the mail and paying invoices.
One approach to handle this is to combine the concepts of different swim lanes for different work item types and capacity allocation. Let’s look at a small scale example for that.

Starting with this fictional, initial board for a very small –let’s say three person– writing agency, we see that the company has committed themselves to limit their sold “Options” ((Options for others, but things the people from our little agency committed to) to six “announced” articles and agreed to have a target number of articles they’re “writing” concurrently to two (thus allowing some work to be already in the “ready for B” column). Furthermore they agreed to have only one article at a time in the “copy edit” stage and one in the “delivery” stage. The “done” column in the example is unlimited (∞) and the invoicing process seems not to be part of this board.

But is this kind of work really the only thing that has to be done in this small company? Of course not.

Let’s take invoicing for example. Even if we assume that writing the invoice and sending it out is part of “delivery” then there still is the little thing of checking if all open invoice get paid some time. And most probably there are also invoices coming in that need to be paid. So there a many small things that need to be done and that we might want to visualize if they are important enough to justify the effort.

Taking the approach of capacity allocation a first solution might look like this:

The idea here is to simply start by allocating part of the day to the big chunks and reserving a smaller part for all the small chunks. Those small chunks might be things like fetching the mail, checking the payment of invoices or paying their own bills.

Following the original ideas behind the Kanban Method principle of “visualize work”, this whole setup is rather buggy. The description of the columns doesn't match with the actual work that's performed in that column, and probably the whole workflow is quite different for those smaller pieces of work.

So let's take another page from the Kanban method and let's have a look at what we actually do now (start with what you do now ) for those small items that we work on we find that we don't have a general workflow but instead the workflow for each card follows the steps of “pick a card”, “understand card”, “perform task”, and “reschedule card as necessary.” And even though this might be the actual workflow, for such small tasks it would not make much sense to separate “understand card” and “perform task” – especially since they happen repeatedly.

So, a more realistic model might only include columns like “options”, “doing”, and “ready to reschedule.”

Picture of a two swimlane board with different workflows for Standard and repeating work

In this picture we now have a Kanban board with two swim lanes. Each lane with its own work item type and both with separate work in progress targets.

Even though this board would actually work (and in many cases I've seen boards like this being really helpful) the actual workflow here is so generic that it doesn't really pull its weight to have a separate board for this.

Depending on details of the cadences (i.e. the rhythms in which work happens) and how much time each item takes to complete, the aforementioned challenge might also be addressed via the lean concept of Heijunka (workload levelling) in the way I mentioned in my earlier post.

Enter kamishibai…

Luckily, the Kanban board is not the only thing that made its way over from TPS into other applications of lean thinking. One of the important parts of the Kanban Method –and probably the most visible one– is the first principle: “Visualize (the work and the workflow).” Using visual representations for things important for the job to be done is a key tenet of visual management. Which in itself is a key component of lean production. Like other things from lean (e.g. 5S), visual management has to be adapted to knowledge work to reap its benefits in this realm as well. Kamishibai boards, which are sometimes used for recurring audits, can be used quite nicely to manage recurring tasks with low complexity like the ones described in the example above.

A simple kamishibai-board just consists of a place to put cards with different colored sides (e.g. red/green). Having a card with the green side up means it’s done, having it with the red side up means it is not yet done. Also, you have an indication of the cadences (the Rhythms in which you want to repeat the tasks) and the very moments those cadences start. Each time a cadence start you simply turn all the cards in that area to show the red side.

Now each time you intend to work on the recurring tasks, you just go to the board, pick a red one, do it and place it back again with the green side up.

Picture of a very simple Kamishibai-Board

In this example the mail has been fetched (green card), the receivables have been checked (green card) and the invoices have yet to be paid. All daily tasks will be turned to red at 9 o’clock and all weekly cards will be turned to red on Sundays at 9pm.

Do you have to do actual board design for this?

Certainly, even board with almost no explicit design like the one pictured above will already be sufficient for many situations. That doesn't mean that there are no approaches to designing such a board that can be helpful. First off let's start with the areas. In the example above we concentrated on weekly and daily recurring tasks – that might be completely different in your situation. Whatever the cadence of your recurring tasks is: make an area for that. For example, daily weekly and monthly or biweekly or any other cadence you actually need. A helpful practice here is to note down the point in time when cards should be turned back to “undone” next to the cadence name, so that everyone knows when the cards need to be turned back and the organization doesn’t become dependent on the knowledge of one single person who acts as a “keeper of the board.”

If you have more than just a few recurring tasks, it becomes a good idea to hang the board on the wall instead of wasting precious horizontal flat surface otherwise known as desk space. something metallic with magnets to hold the cards is a good idea here. Or you might to want to invest in professional T card holders as they are used for example in manufacturing (or just build them yourselves…).

Picture of a DIY T-Card-Holder

What about the cards?

Even with a simple board there are a lot of things you can do with the cards. By the way: a simple way to create cards with two sides of different color is to just stick two post-its together, back to back… Or to take a white card and mark the top off in the colors of your choosing. Lots of room for DIY ideas here.

Colors?

Is it really worthwhile to talk about the colors? Can’t we choose whatever looks fine? E.g. blue for undone and yellow for done? Or whatever our mood suggests? Yes that would be an option and it would even work. But with visual workplace management we want to make things easy to recognize with as little mental load as possible. So I suggest to stick with color codes that fit with everyday expectation, and Green for “done” seems to be pretty universal while “to be done” works with any color that’s far enough away from green like Orange, Red, Purple and the like.

What to put on the card

Apart from a short description of the task, it turned out to be a good idea to also put some additional information on the card. Two of the most important improvements or adaptations for knowledge work are sizing and tracking.

Assumption is the mother of all screw-ups

One helpful piece of information to add to the card is the time it should take to complete the task. Also, to make it more plausible that the work gets done reliably, it is a good idea to note down how long it actually took. A good practice here is to write the expected time on the “to be done side” and the time it actually took on the “done” side. And make sure to adjust the time it should take in accordance with those numbers. At least each time you have to replace the card because there is no more space for more records. Then we’re not talking about estimations anymore but about actual data from measurements.

Card sizing (kind of a hack actually)

If you have a dedicated amount of time to take care of your recurring tasks, it is a good idea to have a rough idea how many of those you're going to handle in any one session. One way to visualize this is to just have different sizes for the cards reflecting their average effort (doesn’t work with the T-Card approach, btw). This way, you can easily see how much of your time slot for recurring work will be filled up by the cards just by having a space at your own work area reflecting the time you allocate for these recurring tasks by it’s size.
You still should try to have a healthy mix of cards from different cadences e.g. daily and weekly, so that you don't have to do all the weekly stuff at the end of the week (or whatever the largest cadence is – could well be quarter in many enterprises).

Kamishibai – a little more complex

Even though simple recurring tasks do not merit the creation of a board that reflects their workflow, some recurring tasks can become quite complex. For those we can combine the whole idea of kamishibai with some insights from the checklist manifesto. The aforementioned task of checking invoices or receivables may actually turn out to be a bit more complicated than it might seem at first glance. Especially when the business is prospering and the client base grows. It might look like fetch the list of open receivables, add invoices we wrote since the last time we checked our receivables, fetch bank statements, cross out invoices where we got the money from our list of receivables, update last-check-date on the list of open receivables. As we can see, this workflow is in no way a process of knowledge gathering but actually just a collection of steps to be performed. Therefore, it wouldn't be natural inside the Kanban method to have a column for each of the steps. Furthermore, this process is very specific to this one recurring task. So, what's more natural than to put it directly on the kamishibai card? This way you might end up with kamishibai cards with things like cadences written on them, with an “Effort”, with little checklists and with any additional information helpful in the specific context of that task. Quite enough to handle most simple recurring tasks. Should the tasks become so complex that they warrant their own workflow the quest for an appropriate solution starts again of course.

The right approach?

Is it more appropriate to takle recurring tasks based on the kamishibai ideas? Well - it depends. It depends on the maturity of the people using the boards, it depends on the type of the recurring tasks –the approach lined out here assumes that the recurring tasks are small–, it depends on the complexity of the recurring tasks –having checklists on the task-cards makes it easier for people to swarm on recurring tasks- etc.
In my personal opinion one of the biggest advantages is that the approach helps in separating “value items” or “products” from items that are mere “tasks“ and are neither visible to the customer nor appreciated in themselves.

This illustration shows the approaches “use Kanban boards for everything” (one way) and “Kanban boards for value stream work and kamishibai boards for recurring tasks” (another way) can be used to represent the exact same situation.

A multi-process Kanban board broken down into value-stream Kanban board and kamishibai board

Both the light blue and the yellow scenarios represent the same situation. With regard to the recurring tasks: Two cards to do, one card in progress and one card “done” (at least done until the next cycle starts).

The second scenario uses a kamishibai representation for the recurring tasks. The recurring cards that were in the “committed” state on the kanban board of scenario “one way” became “undone” (red) cards on the kamishibai board in the scenario “another way.” An additional advantage is that the different cadence for both cards –one occurs weekly, the other one each day– is immediately visible. The “in progress“ card from the Kanban representation is not visible in this instance of a kamishibai board because the person working on it has taken it along e.g. to use the checklist on it. The card from the “done” column became a green (“done“) card in the kamishibai version. Again with the advantage that the cadence of that card is obvious.

Try kamishibai

Before you try to handle all work alike, maybe give the approach of kamishibai for recurring work a chance – it might help more than you think.

till next time
   Michael Mahlberg

Wednesday, November 15, 2023

Decoding Service Levels: Rethinking SLO, SLE, SLA, and SLM

Language creates reality, and when in comes to the delivery capabilities of organization the language around service levels sometimes makes it hard to improve the reality.

The SLA (Service Level Agreement) has become a very loose Term.

Photo by Sora Shimazaki: https://www.pexels.com/photo/multiracial-colleagues-shaking-hands-at-work-5668838/

Non-sensical sentences like “I expect an SLA of less than two weeks!” for example (when used to underline the fact that the customer wants their delivery within two weeks or less) are way too common and make it hard(er) to discuss capabilities in a helpful manner. At least when we take SLA to mean Service Level Agreement.

A lead time distribution diagram built with post its

Right now, early 2023, not only the SLA, but also the SLE is quite popular - the Service Level Expectation. But again – this term can easily be misused and its definition depends quite a lot on context. This term has recently been taken up by people working with Scrum and Kanban and they definitely have their own interpretation.

Sometimes it is helpful to look at the original meanings of terms and try to use them in a way that is most helpful to the situations at hand.

Back to original meanings

Let’s look at what the terms actually (used to) mean and how they could all fit nicely together:

SLO - Service Level Offering

The speed and quality of service that is offered by someone (a person, a team, or an organization) to someone else.

SLE - Service Level Expectation

This term was commonly used mainly in RFPs (Request For Proposals) and in the context of contracts and offerings and describes which level of service would be expected from someone who bids on this RFP. E.g. “If you want to be our supplier for headlights, than we expect that we will have any headlight we order within 48 hours as long as we don’t order more than 200 pieces.” Today’s interpretation sometimes differs, as can be seen by numerous articles around SLEs and Kanban and Scrum

SLA - Service Level Agreement

This is the actual, mutual agreement between two parties that has been reached after discussing

  • the needs and hopes of the client (the SLE in the original sense of the word) and
  • the capabilities of the provider (the SLO)

Most of the time an SLA that has really been negotiated also takes into consideration what each party considers to be a fair and economically viable compensation for that level of service.

SLM - Service Level Measurement / Monitoring

To make sure that everything still works as the parties involved intended it is a good idea to measure the actual service level to be able to make adjustments as needed.

Why can this be helpful?

Once we return to aknowledging the different needs of the different parties involved, it becomes much easier to arrive at the most important letter of this whole three-letter-acronym (TLA) zoo: the A as in agreement!

When the SLO is left in the hands of the people providing the service they can measure their own capabilities and actually know what they can offer.

When it is clear, that the expectation that the outside world has, can not be defined from within the party providing the service, but only from the outside, then the actual clients can (and have to) define what they need.

And if all parties concerned know what they can do and what they need they will have a much time coming to an agreement.

till next time
  Michael Mahlberg

Sunday, April 14, 2019

When implementing Kanban, don't underestimate step 8 of STATIK

When you first start of with Kanban, you might hear that there is a very clear cut way to introduce it – it is called STATIK, the Systems Thinking Approach To Introducing Kanban.

For me this is not always the way to go, but it definitely is a way you should know. As long as you don't think that you can introduce the Kanban method with a half day (or one day) STATIK-Workshop.

Let's look at STATIK briefly: The way David Anderson describes it on his linked-in post STATIK consists of 9 steps. (There are other descriptions as well, most notably Mike Burrows' version from the Book "Kanban from the inside")

  • Step 0: Identify Services
    [For each service]
    • Step 1: Understand what makes the service fit for purpose for the customer
    • Step 2: Understand sources of dissatisfaction with the current system
    • Step 3: Analyze demand
    • Step 4: Analyze capability
    • Step 5: Model workflow
    • Step 6: Discover classes of service
    • Step 7: Design the kanban system
    • Step 8: Socialize the design and negotiate implementation

(I just quoted the summary, the full description is available in David's above mentioned post on LinkedIn )

Starting with step 1 through 7

While it is true that you could hold a STATIK Workshop for the steps one to seven in a really short amount of time, I have never seen the Kanban method implemented this way. I have seen quite a lot of Kanban systems implemented this way. But that's not quite the same – defining a system that reflects a certain point in time is different from embodying a method that fosters ongoing change.

Why I think step 8 is the most important one

Remember – as the titel of the defining book says - it is an approach to change: "Successful Evolutionary Change for Your Technology Business". And I have yet to see a system with human actors that can be changed in a day. Especially because the goal is not to change it only once, but to enable it to continue to do so in an evolutionary manner.
Therefore I think that step 8 is the most underrated Step of STATIK and would strongly suggest to use the result of steps 1 to 7 (a hypothesis the current system) only as a starting point for the work that starts with step 8 – implementing an approach to collaboratively strive for improvement through evolutionary change.

till next time
  Michael Mahlberg

P.S.: For some inspiration on steps 1 to 7 you might also want to look intoAlexei Zheglov's Posts on the approach and the Canvas/A3.

Sunday, February 13, 2022

Is the user story overrated? Some story patterns and formats to learn from

The term “User Story” or simply “Story” as a shorthand for a requirement has become quite widespread these days. But what does it actually mean and how can we benefit best from it?

We all know, what a story is, don’t we?

Let’s try this one on, for size:

“Once upon a time, there was… here goes the story … ever after”

That’s the kind of story that most people in the real world think about, when they hear the term “story.”

In the agile realm stories seem to be a different kind of beast

As I point out below, my personal recommendation is something quite different, but in the realm of Agile, stories seem to be something other than in the rest of the world. Within the realm of Agile, the majority of people seem to believe that the “requirements packaged in the form of a story” is the central element that everything revolves around.

That extends so far, that even the “speed” of development teams is (way too) often measured in something called story-points – even though at least one of the potential inventors of the story-point concept says “I […]may have invented story points, and if I did, I’m sorry now.”

And almost everyone in that realm, as well as in its adjacent territories, have –at one time or the other– heard the stipulation that a well-crafted story

  • starts with “As a <role>…”,
  • has an important “…I want <System behavior>…” in the middle
  • and –in the better cases– ends with “…so that <desired business effect>.”

So – why is this incarnation of the concept “story” so prevalent in the realm of Agile? And is it really the best way to handle requirements in contemporary endeavors? To write better stories today, we need to have a look at how stories came to be such an important instrument in the realm of “Agile Software Development”1 in the first place.

How stories came to software development

Back in the day, before the “Manifesto for Agile Software Development” was written, there were several approaches whose champions called their movement “lightweight software development” and who would later come together and write down what unified their approaches under the moniker “Agile Software Development.” These approaches used all kinds of helpful ways to describe what the system should be able to do.

In Scrum they had the PBI (Product Backlog Item), in Crystal the use case was somewhat prominent, other approaches used comparable artifacts. Extreme Programming was the one that used something called a User Story.

This concept of the user story somehow had such an appeal, that many of the other approaches embraced the idea – more or less.

It was more about the telling, than about the story

A key component behind the idea to use “stories” has even made it into the Manifesto for Agile Software Development – To quote the sixth principle from that manifesto

“The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.”

Before the recommendation that requirements should be talked about was written down in that form, it was embodied in ideas like CCC Card – Conversation – Confirmation or the nice quote from the Book XP-Installed from the year 2000 that a card is a promise to have a “series of conversations about the topic.”

Unfortunately, in today’s world the concept of On-site customers often has been reduced to a person who is called Product Owner but doesn’t have any real business authority and spends about two hours with the team every two weeks. Under these circumstances it seems questionable whether this approach to product development is still viable for all cases.

But I am convinced that understanding why it was okay to write only one sentence to represent a complex requirement back in the early days of lightweight methods helps a lot with writing good stories today.

The fact that the way of working that lead to the original user story is hardly feasible in today’s “corporate agile” with all its compromises, has a direct impact here. It implies that we need something more than just the concept of a “User Story” if we want to capture and process requirements in an efficient manner.

Don’t put the story in the center, focus on the value and the work item

What most approaches propose, is some container that represents “value for someone.” In the process framework Scrum this is called Product Backlog Item, in more general approaches –like the Kanban Method– it is often simply called Work Item.

Such a work item –to go with the broader term– can have many structures. A few common attributes of many such item types are:

Of course, one of the attributes needs to be the actual requirement. And that could be represented by a story. But does that have to be a user story? Actually, there are some pretty helpful alternatives out there.

If you use some kind of story, get to know several types of stories well

As it is often the case, the habitat of the original user story provided many things that were no longer present once the concept was mimicked elsewhere. And as time went by, some people re-discovered what a story could mean for them. Some other people –many, actually– got confused by the story concept since they never really saw it in action and only knew about it through very indirect word of mouth.

Stakeholder Story

After the “As a «role» I want…” format for user stories had been around for quite a while, Liz Keogh pointed out that many of the so called user stories out there are not actual user stories but instead Stakeholder Stories.

  • Format of the Stakeholder Story
    • Liz Keogh described her ideas and observations in the 2010 Article “They’re not User Stories.”

    • The generic form of this kind of story –the way I use it these days– is

      • In order to «the required business effect»

      • «some stakeholder or stakeholder persona»

      • «wants,need,requires,…» «some kind of system behavior or future state»

  • Context for the Stakeholder Story
    • This is an extremely useful perspective if you have to describe requirements that are not actually wanted by the end user of the system, or that don’t actually have a direct user interaction.
    • Most of the requirements I encounter in enterprise contexts are more stakeholder-driven than user driven. (Legal requirement for example. Something like “To avoid being sued for GDPR violations our CISO requires that we have some GDPR-compliant deletion mechanisms that could be executed at least manually if ever a user actually should file a complaint that conforms to article 17 of the GDPR.”)
  • Caveats for the Stakeholder Story
    • The stakeholder should be as tangible and concrete as possible. Unlike with the model of personas in user stories for stakeholders in user stories, it is extremely helpful to name a real person for stakeholders in stakeholder-stories.
  • What to avoid for the Stakeholder Story
    • The most common problem I see with stakeholder stories these days is that the required business effect gets confused mixed up with the system behavior or future state.

User Story

It was probably Mike Cohn who popularized the now so common form of user stories in his 2004 and 2005 books “User Stories Applied” and “Agile Estimation and Planning” but to my knowledge Rachel Davies came up with it around 2002 at Connextra (actually that’s also what Mike Cohn’s post about the three part user story tells us)

  • Format of the User Story
    • The now prevalent way to capture user stories is the well known

    • “As a «role or persona» I want «system behavior» so that «desired business outcome».”

    • This is described (amongst other sources) in the often quoted Article Why the Three-Part User Story Template Works So Well by Mike Cohn.

  • Context for the User Story in this sense
    • Helpful if you really have a product (sometimes a project and seldomly a service) that has actual interactions with actual users
  • Caveats for the User Story in this sense
    • It should describe an interaction between a user and a system that will be possible after the requirements has been implemented.
  • What to avoid for the User Story
    • A story like “As a team member, I want another team member to implement the database logic for the WhatNotField so that it will be available” is using the format alright, but misses almost all point of using User Stories.

Job Story

To my knowledge the whole “Jobs to be Done” way of approaching product challenges became popularized through Alex Osterwalder’s work with Strategyzer around the value proposition canvas. [Please let me know, if you know the whole back-story, I’d be really interested in learning about that] Soon after that the JTBD idea proved so powerful that it spawned it’s own community.

Thanks to my esteemed colleague Matthias I learned about the job story format and the whole idea of using job stories to work on product ideas

  • Format of the Job Story
    • The article Replacing The User Story With The Job Story describe the idea of the Job Story as separating situation, motivation and expected outcome by using the format
    • When ________, (the situation part)

    • I want to ________ (the motivation part)

    • so I can ________ (the expected outcome part)

  • Context for the Job Story
    • Good for very young stories, when you still try to figure out what you’re really talking about.
  • Caveats for the Job Story
    • Unlike Stakeholder Stories and User Stories, Job Stories don’t (yet) provide an easy way to fill out the ________ part, so you really need to dive into the ideas outlined in the above mentioned articles and there can be a lot of discussion about the “right” way to write such a story.
  • What to avoid for the Job Story
    • Don’t treat it like a piece of functionality that just needs to be executed. Job Stories make for good candidates or the narrative flow of Story Maps. There’s also an 2-page summary explanation of Story Maps if you want to know more about that concept.

Of course this only covers some aspects of the usage of stories in todays post-agile society, and I would strongly encourage anyone to look (deeply) into the stuff about INVEST and SMART and at User Story Mapping, to get event more background with regard to working effectively with stories to represent aspects of requirements, but I hope this article gives you some ideas on when and how to use some other kinds of stories to represent requirements that are really hard to fit in the “As a «Role» I want…” format.

till next time
  Michael Mahlberg


  1. (Remember: There is not really an Agile Manifesto)↩︎

Sunday, January 02, 2011

Notes to self - 001, Always put up a visible agenda

Each working day I learn something new - or relearn something old.

=====8<---------- Start of note-to-self 001, Always put up a visible agenda ----

Today I recalled a lesson from AYE - When facilitating a meeting with different personality types it helps everybody to set up a visible agenda and adhere to it - as log as it leaves enough room for deviation.

Some people need a clear picture of where the discussion is going while others are comfortable by "going with the flow". While it doesn't do harm for the latter if you put up an agenda - as long as the topics are liberal enough - it enables those who are in favor of the clear picture to focus on the topic at hand without worrying to much about what might come next.

The fact that the agenda might be helpful for the facilitator as well might be noteworthy as well - for example as a tool to direct the focus or as a tool to postpone the discussion to a later topic. Mixes well with a 'parking lot' to keep track of topics/issues to cover. But of course YMMV

[And of course "Always" should always be used with caution - in this case it is
meant to be read as "Whenever it is applicable, use common sense"]

=====8<---------- End of note-to-self 001, Always put up a visible agenda ----

What are these notes-to-self?

As Alan Weiß' calculation "if one improves 1 percent a day, one will be twice as 'good' in 70 days" shows the possibilities for self improvement are enourmous. (according to Kn = K0 * (1 + (p/100))^n => 1 * ( 1 + (1/100))^70 => 1.01 ^ 70 => 2.0067633... it is even a little bit more...)

But in my experience that math doesn't compute - or at least not for me.
Although I do work on getting better every day there also is a constant loss going on with me. I forget things, I don't apply learnings to new situations, I fail in the application some piece of knowledge that I posses and so on.

When (and if) I realize these events I have a chance to get my 1 percent for that day. (Nah - not really - make it 0.1%)

Up until now I tried to make a "mental note" of these learnings - both old and new. But after only one year it's hard for me to go over 365 purely mental notes, so I thought I should explicitly put them somewhere.

Starting today I'll try to pick the most important one of these aha-effects for each working day (no correlation to business days - I work freelancing) and put it down here. Each note-to-self will consist of the note itself plus a short explanation of it's meaning and context, as can be seen above in the first one.

Topics might be from a very wide range - don't expect notes on CxO level if I spent the day knee deep in code. I guess I'll cover:

  • very low level (like: Note to self: ci in vim is important or Note to self: make sure you're laptop is in powersave if you give a presentation in an hour)

  • development related (like: rvm helps with the descendants of the dll hell)

  • coaching related (Note to self: What looks like resistance is often lack of safety)

  • Facilitation related (see above)

  • Or something that I haven't yet thought of.

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.

Communicate!

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

Huh?
Seriously?
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, January 26, 2014

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

Sunday, February 22, 2015

Triage may seem cruel, but it could save your product

Triage is a term from the battlefield. To be more specific from the battlefield mobile hospitals.

So triage should not have a place in the – comparatively peaceful – world of software development. Or should it?

Sometimes you can’t get them all

It’s all about the question of how to make the best use of your resources in times when the demand exceeds the resources.

The original idea behind triage was to categorize the wounded into three categories (as described more closely in the wikipedia article on triage)

  • Those who are likely to live, regardless of what care they receive
  • Those who are likely to die, regardless of what care they receive
  • Those who would die if they did not receive immediate care but are likely to live if the do get immediate care

and then concentrate your resources on the category where your effort really makes a difference. In the original case this means to start with the third category – cruel though it may seem for the other two categories.

Over the course of time the rationale and theory behind triage have evolved immensely, as can be seen in the article. Both the ethics and the practical application have been refined, but the basic idea is stimm the same. Don’t waste your energy on “lost causes” when that would lead to loosing causes you have a chance of rescuing.

What’s that got to do with software development?

In our day to day work we’re often confronted with situations where the requirements exceed our capacity.

If we try to do everything, even if we dynamically reschedule according to priority, some things won’t get done. That is exactly what “requirements exceed capacity” means. And this is exactly where triage fit’s into the model. If only 4 of 11 requirements will “survive” make sure not to waste any effort on those, that will never see the light of day anyway. Put them in a separate “folder” and once you’ve got discretionary time on your hands revisit that folder and check which of the requirements would still provide value.

If we concentrate on the 4 most important requirements first – the amount we can expect to complete – we end up wit only 36% (4/11) of the requirements fulfilled, but the features for those four requirements can be shipped.

But it is never a good idea to try to fulfill all 11 requirements with only enough resources for 4 – we would end up with 11 requirements fulfilled to 36%. And because a feature that is only 36% complete in most cases is not shippable we would end up with zero deliverable features.

No, it does not mean you can skip tests or refactoring

So if we have to cut functionality can’t we go faster by skipping unit test, documentation or refactoring? That would be just silly – just as if the doctors in the battlefield hospital would omit washing their hands as Uncle Bob would probably remark. On the contrary. Applying triage on a requirement level should give you the time and space to work at your optimum on those requirements that can survive.

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, August 11, 2024

Do we need to get rid of the “Magic –or Iron– Triangle”?

Fast, good and cheap – choose any two. – internet proverb

Or, according to another source > SPEED, QUALITY, PRICE – Pick any Two > – James M. Wallace / Paul Dickson 1980

The Magic of the Triangle

Google search results for Magic Triangle on 2024-04-24 - two out of six show the project management triangle, two show the mathematical construct and two who other concepts

As a quick search on Wikipedia will point out a somewhat more appropriate name seems to be “project management triangle”, but still, with all the ambiguity of the term “magic triangle”, many people equate it with the aforementioned unholy trinity of speed, quality and price and a quick Google search showed that at least in September 2024 they were not alone.

Unfortunately the project management triangle is a model that holds true only under very specific constraints.

Looking at some sources like for example the 2012 IEEE paper that analyses original sources back to 1987 we find some interesting points. First of all, it is important to note that according to theses sources the project management triangle consists of the edges Cost, Scope, and Time while Quality is the area of the triangle.

If we take this literary than we could actually improve the quality by increasing cost, scope and time. (e.g. let’s double time, scope and cost and we quadruple the quality). Obviously it’s not that simple.

Furthermore, unlike in geometry, in project management cost, scope, time, and quality are measured in different units and can not easily be converted into each other.

Especially the simplicity of the relationship between cost and quality has been questioned quite publicly by people like W. Edwards Deming with his concept of “Total Quality Management” or even more poignant by Philip B. Crosby with the catchy book title “Quality Is Free (1980)”

Which quality is negotiable?

We see the tradeoff between price and quality all the time in everyday life. * Is it better to buy the cheap drill bit that will wear off after two holes or to buy the expensive one that will last for hundreds of holes? * Is it better to buy the cheap wine or the expensive one? * Is it better to buy a cheap chair that can be afforded today but will only last a year or an expensive one that will last for many years, but can not be afforded sooner than year?

If we look at these everyday questions, most of us humans start to think in different categories of qualities. For example durability, cost effectiveness, utility and so on.

Once you start to differentiate which category of quality you’re talking about many conversations about “cost vs. quality” become much clearer. (Thinking in project management triangle terms this would make the specific “quality” one of the parts of the scope axis)

Product quality vs. production quality

The last point I would like to stress in this article is the differentiation between the quality of the product (you can make a cheap tool out of cheaper materials) and the quality of the production (you can work with unfitting tools yourself or deprive your employees of good education.)

The important thing here is that while * product quality –or lack thereof– directly affects the customers experience, * production quality directly affects your own bottom line – the worse your production quality is the more it hurts your bottom line.

Like in the drill bit example - when you ship cheap drill bits, the customer will need to replace them earlier. But if you use cheap drill bits on your own manufacturing line you will have to replace them more often, resulting in additional work for you and downtime with accompanied lost revenue.

And if you think that is only true for manufacturing, think of well written, easily understood software vs. the nightmare we see all to often where the complex, unstructured and undocumented code base leads to a simple change taking weeks to implement. Wich in turn looses a couple of potential buyers or creates effort for manual workarounds.

Therefore, when it comes to production quality the “cheap vs. good” adage actually can be quite harmful. In most cases lowering production quality will make the total cost go up.

’till next time Michael Mahlberg

Sunday, October 28, 2018

Meeting hacks: playing the right cards

Some meeting run very smoothly. Others don't.
For today let's look at one special kind of meeting - requirements preparation (refinement meetings –to use scrum-inspired lingo– are one instance of this meeting type, but there are many others that fall into the same category). Those meetings share some common attributes:

  • Usually they are time-boxed
  • The intention is to talk about numerous topics of a similar nature
  • All of the discussed items should be elevated in quality, depth or detail to reach some –more or less well defined– threshold
  • [optional, but very common] Often those meeting tend to overrun and annoy a lot of the participants

How to make it better

With experienced participants or an experienced facilitator, these meetings tend to run much better - neither breaking the time box nor annoying the participants. What can we do to make this kind of meeting work better for teams without a facilitator, or those just starting of with the practice? Over the years I have seen two behaviors that seem to drive up both the annoyance-level and the time required for the meeting more than most others.

Too much detail

The first behavior we tend to fall into, is to discuss an item in way more detail than is required for the current level of decision making. A special case of this is bike shedding where almost everyone is discussing details of an irrelevant topic because that happens to be the easiest way to contribute. But even without this phenomenon, it happens all the time and with the best of intentions.

Off-topic discussions

Another driver for the discussion going ‘off the rails’ is exactly that: getting off-topic. Often by deepening the discussion on topics triggered by talking about the original item, but actually straying away from the context of the item under discussion. Even worse, many of these spontaneous discussions completely disregard the purpose of the meeting and morph into heated arguments about unrelated issues.

Cards on the table

Oftentimes, some of the people in the room may notice these effects, but due to a number of phycological barriers, it can be hard for them to voice their concern. Reasons not to speak up might be the impression that they are the only ones with that concern, past experience that trying to stop an argument only extends it, a difference in rank and many others.
Using playing cards (or planning poker cards) as a means to assist in the management of the two behaviors mentioned above, has proven to be an effective self-facilitation tool. I typically use the Aces and the Jokers from a traditional card deck or the question mark and the coffee cup from a planning poker deck.

  • Ace indicates that the discussion is lost in detail
  • Joker is used to denote the fact that the discussion has run off-topic.

When using planning poker cards I tend to use the question mark as a symbol for too much detail and the coffee cup to indicate getting off-topic.
In any case it is a good idea to post the rules visibly so that the group doesn't have to remember –or even discuss– the meaning of the cards.

Rules of engagement

Just discussing the meaning of the cards and being physically in possession of them already raises everyone’s awareness of (at least) these two ways to derail even well-structured elaborations, but some additional rules on how to use the cards make this technique even more valuable.

I suggest these three rules:

  1. If one person holds up an, card nothing happens. The discussion may continue. (This allows for a simple verification of the personal impression without interrupting the potentially important discussion and simultaneously gives permission for other people to ‘voice’ their opinion.)
  2. If a second person holds up a card of the same type the discussion is tabled for the moment, and a reminder to pick it up again is posted on a jointly visible spot. (I also reduce the time of the main discussion by a minute or so –depending on the group– for each Ace.)

    Furthermore, I tent to use two different spots for the different types of cards, because those different concerns need to be addressed differently. In most cases I find it important to make sure that the Aces (too much detail) get picked up before the meeting is closed.

    It is up to the participants whether they want to do anything about the Jokers after the meeting, but for the Aces the next (third) rule seems to be an extremely valuable practice:

  3. Take time at the end of the meeting to agree on a further course of action for each of the topics posted under «too much detail». For those items the ‘course of action’ tends to be an agreement on «who is going to clarify the details with whom until when?» (Pro tip: Don't elaborate on the details in this meeting, just schedule a follow up meeting and agree to convene again to share the results of that meeting.)

Since I started using this approach, I've seen a steep improvement in the way people conduct refinement meetings, Sprint-Plannings and other “lets discuss this number of similar topics in a fixed time” meetings.

Maybe this approach also works for you?

till next time
  Michael Mahlberg