tag:blogger.com,1999:blog-203377982024-03-13T07:17:42.809+01:00agile aspectsNow it's about organizational development, but back in 2005 my focus was on agile processes and aspect oriented programmingMichael Mahlberghttp://www.blogger.com/profile/17228297952885873743noreply@blogger.comBlogger234125tag:blogger.com,1999:blog-20337798.post-1289487426555111832024-01-10T14:17:00.006+01:002024-02-14T17:40:32.821+01:00A minimum setup for planning?<blockquote>
<p>“Without planning we would fall right back to being hunters and
gatherers again”</p>
<p align="right">-- someone on the internet</p>
</blockquote>
<h3 id="the-gist-of-it-aka-tldr"><strong>The gist of it (aka
TL;DR):</strong></h3>
<ul>
<li>Separate <strong>sizing</strong> and <strong>planning</strong> –
different circumstances lead to different times to completion, even for
equal sized work items,</li>
<li>replace <em>estimation</em> by <strong>analysis</strong> and
<strong>forecasting</strong>,</li>
<li>apply <strong>confidence intervals</strong> <a
href="#separating-size-and-certainty">according to your familiarity with
the problem class</a>. And</li>
<li>communicate the <strong><em>whole</em> probability
distribution</strong> whenever possible.</li>
</ul>
<h1 id="a-minimum-setup-for-planning">A minimum setup for planning?</h1>
<p>
<a href="https://commons.wikimedia.org/wiki/File:Kappa_weibull_pdf.png"><img src="https://upload.wikimedia.org/wikipedia/commons/c/ca/Kappa_weibull_pdf.png"
alt="Weibull Distribution as illustrated at wikipedia, file license CC 4.0 SA"
style="float: right; margin-left: 10px;"
width=240/></a>
</p>
<p>While I’m a big fan of many of the “no estimates” ideas and the whole
“beyond budgeting” movement, I think we still need to make planning
better for those instances where we can’t avoid it.</p>
<p>When we talk to people outside of product development and project
work, estimation and planning are very normal. Questions like “What do
we plan for dinner?” or “What are the plans for the party?” show that
planning is a normal thing for many, if not most, people.</p>
<p>There are many situations where we need to do planning and
“estimation” outside of project and product work. After all, it was
planning and estimation that enabled us to become settlers instead of
hunters and gatherers several milenia ago.</p>
<p>The important thing is to un-mix the two concepts. And maybe also
extract a third component called “co-ordination.”</p>
<h1 id="planning-and-estimation-in-the-physical-world">Planning and
estimation in the physical world</h1>
<p>When we ask someone “When will it be done?” we implicitly ask a
number of questions, with different contexts, like: * With regard to the
understanding of the problem? (to gauge it’s actual size) * How much
work has to be done for this? (How many square meters of wall have to be
painted? How much scaffolding has to be built for this? Etc) * How much
experience do you have with this kind of work? (Have you ever held a
paintbrush? Have you used this kind of paint on this kind of surface
before?) * With regard to the understanding of the problem? (this time,
to gauge it’s feasibility) * What other problems have to be solved,
first? (Do I have to move my furniture into a U-Haul for the time of the
renovation?) * Can these problems be solved directly, or do they, in
turn, have any prerequisites? (Do I need to have a drivers license to
rent a U-Haul?) * With regard to the execution of the solution * How
many people will do the work? Can the work be parallelized? * Who will
actually perform which work? How experienced are they? (How long does it
take <em>them</em> to paint one square meter, how long does it take
<em>them</em> to build one running meter of scaffolding?) * With regard
to external aspects * What other work has to be finished at certain
times? (e.g. outdoor work during dry weather that has to be done first)
* What other activities depend on this task? (How long will I have to
live in the motel and leave my stuff in a U-Haul before I can move back
in?)</p>
<h1 id="planning-and-estimation-in-the-project-world">Planning and
estimation in the project world</h1>
<p>When we go through these questions, we can infer some activities for
planning in the product / project world (and in the world of so-called
agile software development) as well.</p>
<h2 id="separating-size-and-certainty">Separating size and
certainty</h2>
<p>When we separate the question of the amount of wall surface to be
painted from the question of experience in painting walls, we also
separate the question of “size” and the question of “certainty.”</p>
<p>Being aware of the (un-)certainty enables us to better asses how much
accuracy will be in our plans and adjust for it accordingly.</p>
<p>Using <a
href="https://lizkeogh.com/2013/07/21/estimating-complexity/">Liz
Keogh’s model of complexity</a> for example, we could agree that for all
activities categorized as <em><strong>3</strong></em> (<em>Someone in
the world did this, but not in our organization (and probably at a
competitor)</em>) we will assume that it might take anything between
half as much effort as we think now or twice as much.</p>
<p>For an item categorized as a <em><strong>1</strong></em> (<em>We all
know how to do this [and did it several times before]</em>) that range
might –just as an example– be from 0.8 to 1.2.</p>
<p>Of course, you have to finde the right factors for uncertainty for
each level on the scale according to <em>your</em> local situation. ##
Separating size and effort As even Mike Cohn wrote: <a
href="https://www.mountaingoatsoftware.com/blog/its-effort-not-complexity">estimation
is about effort</a> and knowing the “size” of an item does not
automatically give us the effort necessary to complete that item. (Using
white-out to “paint” the wall will result in a different amount of work
than using a spray gun)</p>
<h2 id="separating-effort-and-duration">Separating effort and
duration</h2>
<p>Here’s the thing about ‘estimation’ and duration: even if we knew the
<strong>effort</strong> that is required, we still can’t know the time
it will take from start to finish.</p>
<p>Let’s look at a different analogy here, specifically with regards to
relative estimation.</p>
<p>If you ask two people -one who drives a sports car and another one
who drives a truck– how long it would take them to drive from Munich to
Berlin (about 600 km) <em>relative</em> to the time it takes them to
drive from Munich to Karlsruhe (about 300 km) they would probably both
answer the same: “Twice as long.”</p>
<p>In this example relative sizing enables people with different
backgrounds to still have meaningful conversations about effort, without
even needing to know the absolute estimation of one another.</p>
<p>Still, when executing, the person driving the sports car would
probably deliver a package to Berlin in less time than it would take the
one driving the truck to get to Karlsruhe. (Hint: Trucks are limited to
80 km/h in Germany and there are –unfortunately– still large parts of
the highway system in Germany without speed limit so the sports car
could leverage its top speed from time to time).</p>
<p>What this example also shows, is that it is important to keep in mind
that the actual time it takes to complete an item can very much depend
on the current capabilities of the people working on it.</p>
<h2 id="managing-prerequisites-and-dependencies">Managing prerequisites
and dependencies</h2>
<p>Even in the world of agile software development, it is necessary to
understand prerequisites and dependencies.</p>
<p>That does not mean that we need <a
href="https://en.wikipedia.org/wiki/Gantt_chart">Gantt charts</a> or <a
href="https://en.wikipedia.org/wiki/Program_evaluation_and_review_technique">PERT-diagrams</a>
with detailed timelines month and years into the future. The well
researched <a
href="https://www.construx.com/books/the-cone-of-uncertainty/">cone of
uncertainty</a> has shown that these would be useless in a matter of
weeks anyway. To me the frustration with the misuse of techniques like
Gant charts and PERT diagrams that seems to be one of the drivers of the
whole “no estimate” movement.</p>
<p>But using the basic ideas of PERT for example –actively modeling
which activity is dependent upon which other activity and which
activities can be tackled independently– is still quite helpful. Just
mapping out –and agreeing upon– which hard dependencies exist on the
next lower level of abstraction makes a huge difference when it comes to
succeeding with most real-life multi-step ventures.</p>
<h1 id="putting-it-all-together-a-model-for-sizing-and-planning">Putting
it all together: a model for sizing and planning</h1>
<p>From my experience, every explanation about how to do planning and
sizing right has to be wrong on some level, <a
href="https://en.wikipedia.org/wiki/All_models_are_wrong">but maybe some
[of the ideas] are useful nonetheless</a>.</p>
<h2
id="a-flawed-but-sometimes-helpful-workflow-for-the-question-when-will-it-be-done">A
flawed, but sometimes helpful, workflow for the question “When will it
be done?”</h2>
<ol type="1">
<li>Cut it down to to chunks reasonably well understood size (analyze,
don’t estimate). Some ideas for that could be:
<ul>
<li>using the sizes <a
href="https://estimation.lunarlogic.io/#pg"><strong>NFC</strong>,
<strong>1</strong>, and <strong>TFB</strong> as explained by Pawel
Brodzinski</a> instead of t-shirt sizes or other arbitrary numbers</li>
<li>using equivalent items from the past is also quite helpful
(selecting a couple of reference items, or at least one for each size,
to <em>compare</em> future work items with)</li>
</ul></li>
<li>Make sure to know about the dependencies between the work
items.</li>
<li>Use historical data (e.g. <a
href="https://agile-aspects.michaelmahlberg.com/2019/03/how-to-visualize-imho-most-important.html">lead
time distributions</a> separated per reference item class) to forecast
durations. (The closer you get to actually working on the elements the
more important it is to use not <em>any</em> historical data, but data
from the team (or other subpart of the organization) that will do the
work.</li>
<li>Apply confidence intervals (e.g. based on Liz Keogh’s aforementioned
scale) to those forecasts.</li>
<li>Apply risk management heuristics (<a
href="https://amzn.to/3pAd5WL">e.g. from “Waltzing with Bears”</a> and
maybe, but not necessarily using the <a
href="https://systemsguild.eu/riskology">Riskology</a> spreadsheet) to
the result of the previous steps.</li>
<li>Communicate the result as a probability distribution, or at the very
least as a range, not as a single number.
<ul>
<li>If you don’t use the whole distribution try to communicate a date or
duration that feels sufficiently safe, like the 80th percentile, and
communicate the other ends of the distribution in relation to that point
(e.g. <em>“for 8 out of 10 items like this, it should take 21 days, but
we might end up three days earlier or -in 2 out of 10 cases- it might
take 25 days”</em> - thus you avoid anchoring people on the
nano-percent-probabillity of 18 days)</li>
</ul></li>
<li>If your endeavor consist of dependent items (and you can’t break the
dependencies) consider using something <em>like</em> the PERT-approach
without actual dates to plan parallel and sequential parts of the
work.</li>
</ol>
<p>Some people might argue that it would be possible to lump steps 3 to
5 together in just one so-called “Monte-Carlo simulation” as they come
out-of-the box in many contemporary tools but there are drawbacks to
this approach. (although Riskology also uses a Monte Carlo simulation
under the hood),</p>
<p>On the other hand, the black box approach of many of the Monte-Carlo
simulations that have been integrated into popular tools makes it very
hard to really know what is being calculated, how things are weighted
and so on.</p>
<p>Even so, just applying steps 1 through 4 already gives so much better
forecasting and planning that, in my book, it is definitely worth the
while.</p>
<p>till next time<br /> <em><a
href="http://www.michaelmahlberg.com">Michael Mahlberg</a></em></p>
<hr />
<h1 id="footer-ignore">Footer (ignore)</h1>
<h1 id="fieldstones">fieldstones</h1>
<p>Estimation hast many dimensions: * complexity * effort</p>
<p>planning has other dimensions: * capability of the system
(e.g. company or team) * relative cost of not doing things * customer
demand (e.g. due dates)</p>
Michael Mahlberghttp://www.blogger.com/profile/17228297952885873743noreply@blogger.com0tag:blogger.com,1999:blog-20337798.post-74346493092649215482023-11-15T14:09:00.000+01:002023-11-15T14:09:45.148+01:00Decoding Service Levels: Rethinking SLO, SLE, SLA, and SLM<p>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.</p>
<h1
id="the-sla-service-level-agreement-has-become-a-very-loose-term.">The
SLA (Service Level Agreement) has become a very loose Term.</h1>
<p>
<img src="https://www.dropbox.com/scl/fi/qlgo16pbz16huqfqgsu9j/pexels-sora-shimazaki-5668838.jpg?rlkey=c2ca0vkbpxkz0dt3yd8szp95y&raw=1"
alt="Photo by Sora Shimazaki: https://www.pexels.com/photo/multiracial-colleagues-shaking-hands-at-work-5668838/ "
style="float: right; margin-left: 10px;"
width=200/>
</p>
<p>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 <strong>S</strong>ervice <strong>L</strong>evel
<strong>A</strong>greement.</p>
<p>
<img src="https://www.dropbox.com/scl/fi/rwc89bn12eg55mah1ru2m/LTD-in-paper.png?rlkey=afi7g5slty60igj2ubojyhklb&raw=1"
alt="A lead time distribution diagram built with post its"
style="float: right; margin-left: 10px;"
width=200/>
</p>
<p>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.</p>
<p>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.</p>
<h1 id="back-to-original-meanings">Back to original meanings</h1>
<p>Let’s look at what the terms actually (used to) mean and how they
could all fit nicely together:</p>
<h2 id="slo---service-level-offering">SLO - Service Level Offering</h2>
<p>The speed and quality of service that is offered by someone (a
person, a team, or an organization) to someone else.</p>
<h2 id="sle---service-level-expectation">SLE - Service Level
Expectation</h2>
<p>This term was commonly used mainly in RFPs (Request For Proposals)
and in the context of <a
href="https://www.lawinsider.com/dictionary/service-level-expectations">contracts
and offerings</a> 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</p>
<h2 id="sla---service-level-agreement">SLA - Service Level
Agreement</h2>
<p>This is the actual, mutual agreement between two parties that has
been reached after discussing</p>
<ul>
<li>the needs and hopes of the client (the SLE in the original sense of
the word) and</li>
<li>the capabilities of the provider (the SLO)</li>
</ul>
<p>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.</p>
<h2 id="slm---service-level-measurement-monitoring">SLM - Service Level
Measurement / Monitoring</h2>
<p>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.</p>
<h1 id="why-can-this-be-helpful">Why can this be helpful?</h1>
<p>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!</p>
<p>When the SLO is left in the hands of the people providing the service
they can measure their own capabilities and actually <em>know</em> what
they can offer.</p>
<p>When it is clear, that the expectation that the outside world has,
can not be defined from <em>within the party providing the service</em>,
but only from the outside, then the actual clients can (and have to)
define what they need.</p>
<p>And if all parties concerned know what they can do and what they need
they will have a much time coming to an agreement.</p>
<p>till next time<br /> <em><a
href="http://www.michaelmahlberg.com">Michael Mahlberg</a></em></p>
Michael Mahlberghttp://www.blogger.com/profile/17228297952885873743noreply@blogger.com0tag:blogger.com,1999:blog-20337798.post-17136133831003646352023-11-08T14:09:00.001+01:002023-11-08T14:27:45.712+01:00What’s the «Minimum» in MVP (Minumun Viable Product) anyways?<p>“There can only be one!” (Or not?)</p>
<p>At least one of my friends gets “all highlander” on people who try to
talk about having defined the MVP<strong><em>s</em></strong> (plural)
for the product strategy and makes a very strong point of the fact that
there can only be one (predefined) <em>minimum</em> viable product.</p>
<p>But is that really true? Or is it prudent to say “we’ve defined a
couple of MVPs?” Does it make sense to talk about the amount of users
who actively “use our MVP?” Or is an MVP a thing that does not really
provide any user functionality?</p>
<p>Well – as I like to point out: <em>Context is King. Always.</em> And
we have to accept reality <em>as it is</em>. In that vain, I think we
have to recognize that people are using all the notions above.</p>
<p>From what I’ve learned over the last couple of years, at least two
fundamentally different ideas behind the term
<em><strong>MVP</strong></em> are widely spread and of course we also
have to take <a
href="https://martinfowler.com/bliki/SemanticDiffusion.html">semantic
diffusion</a> into account.</p>
<h2 id="the-mvp-in-the-world-of-lean-startup-2008">The MVP in the world
of Lean Startup (2008)</h2>
<p><img src="https://www.dropbox.com/scl/fi/ff2cyh16w0x5p3vavximj/Research.png?rlkey=1i6px3jh3o3cy9grly49dsmet&raw=1"
alt="Some green liquid in a scientific jar – Free Image on pexels"
style="float: right; margin-left: 10px;"
width=200/></p>
<p>With Eric Ries seminal work on <a href="https://amzn.to/3U0qHnY">The
Lean Startup</a> and the adoption of the whole lean startup approach,
the term MVP gained real popularity.</p>
<p><a href="https://en.wikipedia.org/wiki/Steve_Blank">Steve Blank</a>,
“<a
href="https://steveblank.com/2013/07/22/an-mvp-is-not-a-cheaper-product-its-about-smart-learning/"
title="An MVP is not a Cheaper Product, It’s about Smart Learning">An
MVP is not a Cheaper Product, It’s about Smart Learning</a>” “MVP is
whatever you could build to learn the most at a certain time” in this <a
href="https://www.youtube.com/watch?v=PpAjMU-E9_g">interview at Startup
Istanbul</a></p>
<p>According to Alex Osterwalder’s ideas for example, an MVP is “A model
of a value proposition designed specifically to validate or invalidate
one or more hypotheses” – at least in the context of <a
href="https://issuu.com/business.model.innovation/docs/vpd_sneakpeek/103">value
proposition design</a> so I would argue, that there is some merit to
this position.</p>
<h2 id="the-mvp-in-the-world-of-product-development-2001">The MVP in the
world of product development (2001)</h2>
<p><img src="https://www.dropbox.com/scl/fi/tthwdrpp1a1bihozt16yh/CashRegister.png?rlkey=45l8o90qoifb911w2uxoibmdh&raw=1"
alt="An old time cash register – Photo by Ramiro Mendes on Unsplash"
style="float: right; margin-left: 10px;"
width=200/></p>
<p>Way before Lean Startup, in 2001, Frank Robinson published a
definition of the term MVP that is much closer to the concept I have
most often heard associated with the term by people who have
<em>not</em> been exposed to the ideas of Eric Ries :</p>
<blockquote>
<p>The smallest product that will actually be sellable.</p>
</blockquote>
<p>The problem with this outlook is of course, that the risk-issues
Steve Blank and Eric Ries point out in their work are not at all
addressed by this approach.</p>
<p>For those interested: the original wording from Robinson was >
“ <em>The MVP is the right-sized product for your company and your
customer. It is big enough to cause adoption, satisfaction, and sales,
but not so big as to be bloated and risky. Technically, it is the
product with maximum ROI divided by risk. The MVP is determined by
revenue-weighting major features across your most relevant customers,
not aggregating all requests for all features from all
customers.</em>”</p>
<p>For a more in-depth discussion of the topic I recommend reading
through product board’s <a
href="https://www.productboard.com/glossary/minimum-viable-product-mvp/">article
about MVP</a> and through the product schools’s <a
href="https://productschool.com/blog/product-management-2/difference-prototype-mvp/">comparision
between MVP and prototype</a></p>
<p>Given this point of view, I’m inclined to argue that there is value
in this position as well.</p>
<h2 id="other-terms-that-might-help">Other terms that might help</h2>
<p>In the 2004 book <a href="https://amzn.to/3TcNAEd">software by
numbers</a> Jane Clelans-Huag and Mark Denne introduced the term minimum
marketable feature (MMF) that nicely describes what is often
<em>meant</em> when people talk about MVPs:</p>
<blockquote>
<p>A chunk of functionality that can be sold together and makes sense
for a potential customer to buy <em>(Paraphrased by me)</em></p>
</blockquote>
<p>till next time<br /> <em><a
href="http://www.michaelmahlberg.com">Michael Mahlberg</a></em></p>
Michael Mahlberghttp://www.blogger.com/profile/17228297952885873743noreply@blogger.com0tag:blogger.com,1999:blog-20337798.post-7456777436099002622022-11-20T14:38:00.001+01:002022-11-20T14:38:00.178+01:00How can I rent a 50 foot yacht (or get a job as a scrum master) if I have no experience? You shouldn’t!<p>Recently, a successful speaker and trainer –whom I also happen to
know personally– posted a (German) article on linkedIn, where he
“replied” to the many questions he got on “How do I find a job as a
Scrum Master if I have no experience?”</p>
<p>He actually <em>did give</em> suggestions. And that is what really
made me sad, because the question alone already highlights much of
what's wrong in today's post-agile world.</p>
<p>In my opinion the only right answer would have been: "You shouldn't!”</p>
<p><img src="https://www.dropbox.com/s/diuayszqmha3sve/adventures-ofmaldives-dch7r8qAzpg-unsplash.jpg?raw=1"
alt="aerial view of green body of water with sank ship photo – Free Image on Unsplash"
style="float: right; margin-left: 10px;"
width=200/></p>
<p>To me, the whole <strong><em>"How can I get a job as a scrum master
if I don't have any scrum master experience yet? It's so unfair that
they all expect me to have experience."</em></strong> is fundamentally
the wrong question to ask.<br />
It is like asking <strong><em>“How can I rent a sailing yacht if I don't
have any sailing experience yet? It's so unfair that they all expect me
to have experience. How should I ever get the experience if they don’t
let me try it out?” </em></strong> or maybe even <strong><em>"How do I
get a job as a surgeon if I don't have any
experience?"</em></strong></p>
<p>There are many jobs for which you <em>do</em> need experience.</p>
<p>Let's look at what a master used to be:</p>
<p>In most areas (university excluded) you become a master after you've
been an apprentice (usually for three years) and after completing your
<a href="https://en.wikipedia.org/wiki/Journeyman">journeyperson’s</a>
time (in Germany usually also three years). After that, you have to pass
an examination and deliver a so–called masterpiece.</p>
<p>In the agile realm people can become a “Master” (at least a Scrum
Master) after a two-day training course.</p>
<p>The people who defined Scrum (around 1995) were part of the group
that wrote the <a
href="https://agile-aspects.michaelmahlberg.com/2022/01/there-is-no-agile-manifesto.html">Manifesto
for Agile Software Development</a>, so it's safe to assume that they
also co-created the first page that starts with "We are uncovering
better ways of developing software <strong>by doing it</strong> and
helping others do it.” If one believes that sentence, how much sense
does it make to have people who don’t have any actual experience
<em>doing it</em> train and coach other people in things they never
experienced themselves?</p>
<p>If you look at the original idea of a Scrum Master you will find that
the Scrum Master is –to pick just a few items– meant to</p>
<ul>
<li>[be …] accountable for establishing Scrum</li>
<li>help[ing] everyone understand Scrum theory and practice, both within
the Scrum Team and the organization.</li>
<li>enabling the Scrum Team to improve its practices, within the Scrum
framework</li>
<li>[be] leading, training, and coaching the organization in its Scrum
adoption</li>
<li>for more: see the <a
href="https://scrumguides.org/scrum-guide.html#scrum-master">current
version of the scrum guide</a></li>
</ul>
<p>All of these things are pretty hard to do if you only know them from
theory. For similar reasons maritime law makes sure that even though the
first journey of a skipper <em>is</em> their first journey as a skipper,
it is by far not their first journey in an active role on a ship. In the
same vein, new Scrum Masters really ought to have experienced the
environment from numerous roles to fulfill the expectations laid out in
the framework.</p>
<p>To quote one of the original books on Scrum by Ken Schwaber (Used to
be required reading for getting the Scrum Master certification in the
olden days):</p>
<blockquote>
<p>The Team Leader, Project Leader, or Project Manager often assume the
Scrum Master role. Scrum provides this person with a structure to
effectively carry out Scrum’s new way of building systems. If it is
likely that many impediments will have to be initially removed, this
position may need to be filled by a senior manager or Scrum consultant.
<a href="https://amzn.to/39W3h16">Schwaber2001, p. 32</a></p>
</blockquote>
<p>On the other hand, especially that innocous “enabling the Scrum Team
to improve its practices” from the bullet-list above implies (according
to most, but not all, certified scrum trainers (CSTs) I know) all the
stuff from the technical side of agile as well.</p>
<!-- It's hard to convince anyone that e.g. TDD or pairprogramming are good ideas if neither you nor the person you’re trying to convince has ever felt the positive effect of really using these approaches. (Note that neither TDD nor pair programming are necessary for agile software development, they are just two examples of practices that have proven to be very helpful in this realm) -->
<p>So please, if we want to achieve the goals we had in the early 2000s,
when “lightweight processes” –as they were called before 2001— became
“Agile Software Development”, then let’s stop with dishing out the idea
that the person who is intended to help people get better at the game,
can learn what to do in a couple of days and “on the job.” Let’s be
realistic and tell people that they should go through the path of
apprentice and journeyperson themselves before they start acting in
roles that are designed to be held by experienced people.</p>
<p>Because of all of this, in my opinion, the best answer to the
original question “How do I find a job as a Scrum Master if I have no
experience?” should have been “You shouldn't.” Amended with the
suggestion of better questions to ask.</p>
<p>To me one better question would be: “How can I get the experience
that is necessary to be an effective and useful scrum master?” (From my
point of view, working as a developer, tester, subject matter expert or
maybe even as an intern in an environment that actually has a working(!)
Scrum setup are some good ways to get experience.)</p>
<p>In my experience, the (few) people who ask this latter question and
try to get that experience usually don't have any problem with job
offers – except that they might get too many. <em>After</em> they did
get the experience…</p>
<p>till next time<br /> <em><a
href="http://www.michaelmahlberg.com">Michael Mahlberg</a></em></p>
<!-- https://www.linkedin.com/feed/update/urn:li:activity:6922882713339236352/ -->
Michael Mahlberghttp://www.blogger.com/profile/17228297952885873743noreply@blogger.com0tag:blogger.com,1999:blog-20337798.post-27066449071160343832022-09-18T17:00:00.006+02:002022-09-18T17:00:00.193+02:00Coach? Consultant? Trainer?<p>Language is a funny thing.</p>
<p>As philosopher Wittgenstein said "The limits of my language mean the
limits of my world."<a href="#fn1" class="footnote-ref" id="fnref1"
role="doc-noteref"><sup>1</sup></a></p>
<p>Or, to take another angle, as Steve Young put it "Perception is
reality" <a href="#fn2" class="footnote-ref" id="fnref2"
role="doc-noteref"><sup>2</sup></a></p>
<p>Without wanting to re-iterate my whole <a
href="https://agile-aspects.michaelmahlberg.com/2018/07/what-is-agile-coaching-really.html">earlier
post</a>, I would just like to shine a light to the fact that outside
the agile realm the coach is much more prevalant in sports than in
psychology (e.g. life-coaching).</p>
<p>And a sports coach acts quite differently from a life coach. Can you
imagine a group of people who hire a coach because they want to become a
soccer team and that coach would <em>start</em> by asking everyone how
<em>they</em> think soccer should be played? If the distance of the
goals is to their liking and whether a ball would be the best thing to
play with?</p>
<p>If you can imagine this scenario, then I guess, it is either with a
sarcastic glance at the way many agile coaches work today or you where
reminded of some kind of comedy.</p>
<p>Life coaching, solution focused coaching, systemic coaching all have
their places – even in soccer coaching – but usually not in the
beginning when the players still are unaware of the rules of the game,
not well versed in the moves and inexperienced.</p>
<p>And by the way: the oldest mention of a coach in what later came to
be the agile realm was from eXtreme Programming (XP). To quote my <a
href="https://agile-aspects.michaelmahlberg.com/2018/07/what-is-agile-coaching-really.html">aforementioned
article</a> and paraphrase from eXtreme Programming explained:</p>
<p>“... the [coache’s] job duties are as follows:</p>
<ul>
<li>Be available as a development [programming] partner [...]</li>
<li>[make refactoring happen]</li>
<li>Help programmers with individual technical skills, like testing,
formatting, and refactoring</li>
<li>Explain the process to upper-level managers.”</li>
</ul>
<p>or – on a later page – “Sometimes, however, you must be direct,
direct to the point of rudeness. [...] the only cure is plain speaking.”
And also “[...]I am always in the position of teaching the skills [...]
But once the skills are there my job is mostly reminding the team of the
way they said they wanted to act in various situations. The role of the
coach diminishes as the team matures.”(p 146)</p>
<p>So maybe – just maybe – it would helpful to be aware whether the team
needs a sports coach or a therapeutic coach.</p>
<p>I find that both are appropriate at different points in time, but I
have seen a lot of cases recently, where the client was looking for –and
needed– a coach akin to the sports-coach metaphor, ended up with a coach
conforming to the life-coaching metaphor and everyone just ended up
really unhappy.</p>
<p>till next time<br /> <em><a
href="http://www.michaelmahlberg.com">Michael Mahlberg</a></em></p>
<section class="footnotes footnotes-end-of-document"
role="doc-endnotes">
<hr />
<ol>
<li id="fn1" role="doc-endnote"><p>"Die Grenzen meiner Sprache bedeuten
die Grenzen meiner Welt", – <strong>Ludwig Wittgenstein, Tractatus
logico philosophicus, 5.6, 1922</strong>.<a href="#fnref1"
class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn2" role="doc-endnote"><p>"Perception is reality. If you are
perceived to be something, you might as well be it because that's the
truth in people's minds." - Steve Young<a href="#fnref2"
class="footnote-back" role="doc-backlink">↩︎</a></p></li>
</ol>
</section>
Michael Mahlberghttp://www.blogger.com/profile/17228297952885873743noreply@blogger.com0tag:blogger.com,1999:blog-20337798.post-52499814279926372822022-05-08T17:00:00.022+02:002023-08-16T14:43:49.959+02:00«Creating Feedback Loops» is not about having meetings<p>In many modern approaches to work, like <a
href="https://djaa.com/revisiting-the-principles-and-general-practices-of-the-kanban-method/">The
Kanban Method</a>, <a
href="http://theleanstartup.com/principles#lean_principles">Lean
Startup</a>, <a
href="https://agile-aspects.michaelmahlberg.com/2022/01/there-is-no-agile-manifesto.html">Agile
Software Development</a>, or <a
href="https://itrevolution.com/the-three-ways-principles-underpinning-devops/">DevOps</a>,
<strong>Feedback</strong> is an essential part of the approach.</p>
<p>Sometimes the role of feedback is explicit, whereas in some cases it
is more of an implicit assumption that is only visible upon deeper
inspection.</p>
<p>The Kanban Method has it pointed out explicitly as (currently) the
fifth practice (Establish feedback loops) while the DevOps movement has
one of its "three ways of DevOps" dedicated to it (The second way: the
principles of feedback) which in itself consists of five principles.</p>
<h2 id="lets-have-more-meetings-a-common-misconception">“Let’s have more
meetings” – a common misconception</h2>
<p>Unfortunately, some of the currently popular approaches have
introduced the notion that implementing feedback loops implies having
some special meetings for feedback.</p>
<p>Feedback like that, could be a daily meeting regarding the current
status of the work – especially focusing on problems or things to solve,
or an event-based meetings, like post deployment retrospection.</p>
<p>For example, if you look into The Kanban Method, you'll find a whole
slew of other meetings to be held at different cadences to foster more
feedback in your work.</p>
<p>While these meetings can be very helpful, they are not at all the
best way to get real feedaback, really quick.</p>
<h2 id="the-problem-with-meetings-as-the-primary-source-of-feedback">The
problem with meetings as the primary source of feedback</h2>
<p>The trouble with feedback that only comes periodically, and is
dependent on human interaction, is that most of the time it comes too
late.</p>
<p>Consider some feedback loops from outside the work organization
world:</p>
<ul>
<li>The speedometer of your car gives you feedback about your current
speed – just waiting for the speeding tickets to come in would be way
too slow as a feedback loop.</li>
<li>Or how about another thing in your car that you get information
about: the oil in the motor via the oil warning lamp and the oil
dipstick. For certain kinds of information the dipstick, at which we
look from time to time gives us enough feedback. For the important
short-term feedback that the oil pressure is too low, we need faster
feedback. That's why your car comes with an oil pressure warning
lamp.</li>
</ul>
<h2
id="how-can-we-crate-feedback-loops-inherent-in-the-ways-we-work">How
can we create feedback loops inherent in the ways we work?</h2>
<p>What we actually want when we talk about feedback, is usually a very
prompt response from the system we are interacting with. This system can
be anything from a technical system through a physical system or a
mechanical system to a system consisting of people interacting with one
another.</p>
<p>One of the best ways to get early feedback is to actually remove
inventory.</p>
<p>You may have heard that removing inventory is a central tenant of all
the lean approaches, but when thinking specifically about feedback,
removing inventory has the added benefit of making sure that we get our
feedback earlier.</p>
<p>So really, what we mean by “creating feedback loops” is finding ways
to see the final impact of the things we just did as early as possible
instead of waiting for the effects to happen somewhere very far down
stream.</p>
<p>till next time<br /> <em><a
href="http://www.michaelmahlberg.com">Michael Mahlberg</a></em></p>
Michael Mahlberghttp://www.blogger.com/profile/17228297952885873743noreply@blogger.com1tag:blogger.com,1999:blog-20337798.post-47689645519815408752022-03-13T18:00:00.007+01:002022-03-13T18:27:57.334+01:00Three strategies to ease the meeting pain<p>“Since we started the new approach, I hardly ever get any work done,
because we have so many meetings.” That is a sentiment, I here quite
often when I’m visiting clients who have just started with some new
approach. Surprisingly often that is the case if that new approrach is
some flavor of “Agile.”</p>
<p>This seems more frequent if the client is a large corporation, but it
certainly also happens at startups and SMEs.</p>
<p>And yet, on the other hand it seems to be increasingly hard to get
any meetings scheduled. Let’s look at some approaches to make things a
bit more manageable again</p>
<p>Once we start to differentiate between meetings that generate work
and meetings that get work done it starts to get easier to handle the
workload.</p>
<p>As described below, once we start making that distinction we can
apply strategies like</p>
<ul>
<li>planning the Work instead of the meetings (allocating time in my
calendar for “getting stuff done” – especially helpful when applied –and
negotiated– on a team or even multi-team level)</li>
<li>conscious capacity allocation (I will have 3,5 hours of working time
and 3,5 hours of meeting time each day)</li>
<li>Actively keeping buffers open for unexpected, short term
interactions (Putting blockers in my calendar that I remove only shortly
before they are due)</li>
</ul>
<p>Now let’s look at these strategies in detail:</p>
<h2 id="two-types-of-meetings">Two types of meetings</h2>
<p>Some people (maybe many) tend to view all meetings as “a waste of
time” and “not <em>real</em> work” – I beg to differ.<br />
I would say that we need to differentiate between meetings that leave us
with more work than before and meetings that leave us with less work
than before.</p>
<h3 id="work-generating-meetings-coordination-time">Work generating
meetings (coordination time)</h3>
<p>Some meetings leave us with more work than we had when before we
attended the meeting.</p>
<ul>
<li>Planning meetings, where the actual purpose of the meeting is to
find or define work that needs to be done.</li>
<li>Status meetings, where the original intention is just to ”get in
sync” but where it often happens that someone realized: ”oh, and we have
to do X”</li>
<li>Knowledge sharing meetings, where not everyone affected is invited
and thus we need to share the knowledge again.</li>
<li>Knowledge building and gathering meetings where the purpose is to
better understand something, we didn’t fully understand before – be it a
user interview in a product development company, a design session for
something be build ourselves, some kind of process improvement meeting,
or something else in the same vain.</li>
</ul>
<p>This list is of course by no means conclusive, but it should give you
an idea of the kind of meetings that could be put in that category.</p>
<h3 id="meetings-that-get-work-done-creation-time">Meetings that get
work done (creation time)</h3>
<p>On the other hand there are meetings that actually get work done.
Especially for work that needs more than one person to complete it.</p>
<ul>
<li>Design Sessions that end with decisions.</li>
<li>Pair-Writing an article or a piece of software</li>
<li>Co-creating an outline for an offer</li>
<li>Co-Creating the calculations for next years budget (if your company
still does budgeting the old way)</li>
</ul>
<p>Try not to mix the two types of meetings. At least not too much.
Especially try to make the second kind of meeting really a meeting that
gets work done. As in done-done. Make sure that there is no ”X will
write this up, and we’ll review it it two days.”</p>
<p>If it’s good enough in the meeting, it’s probably good enough for
work.</p>
<p>If we introduce some kind of follow-up work, especially follow
up-work that has to be reviewed again, we actually prevent people from
using the result of the work we just did in that meeting. Try to make it
“good enough for now” and then let’s get on with creating value at other
places.</p>
<p>And if it takes too long to create those documents in the Meeting
with the tools you have available in the meeting, you probably have some
great opportunity to re-think your choice of tools.</p>
<p>With this in mind, let’s look at the three strategies in a bit more
detail.</p>
<p>And even though the strategies are persented in a specific order,
there is no real ordering between them. Each of them works well on it’s
own and you can combine them in any possible way.</p>
<h2 id="strategy-one-plan-the-work-not-the-meetings">Strategy one: Plan
the work, not the meetings</h2>
<p>Even if you apply only this one strategy it can be a real game
changer.<br />
Instead of keeping your agenda open for meetings and then work during
the few times where no meeting is scheduled, no meeting needs
preparation, and no meeting needs post-processing, switch it around.</p>
<p>Start by filling your schedule with “creation time” – time slots
where you intend to do the part of your work that directly creates
stuff. When you’re a knowledge worker in the times of a pandemic, this
might also include meetings, but those should be only meetings that
<em>create tangible results</em>. (This could be a design session with
colleagues if you’re in manufacturing, it could be an editing session on
a paper if you’re in academia, or maybe a pair- or mob- (ensemble)
programming session if you’re in software development. Any meeting that
<em>outputs</em> work.)</p>
<p>Only <em>after</em> you filled your schedule with a reasonable amount
of time allocated to ”creation time” fit those other things, that I like
to call “coordination time”, in some of the remaining spaces on your
calendar.</p>
<p>This “coordination time” can include planning, status updates,
learning and agreeing upon how you want to do things, understanding the
challenge you’re currently working on, and so on. It is basically the
coordination you need to efficiently get stuff done in the “creation
time.”</p>
<p>Some people tend to call only “creation time” <em>Work</em> and the
rest of the time <em>Meetings</em>. However, meetings that neither add
value through creation nor through a better understanding of who is
doing what when and how, should be eliminated altogether. And maybe
replaced by an e-mail or</p>
<p>Especially when we work on process improvements or introduce new
approaches we tend to start by planning when the related events (or
ceremonies to use an older term ;-) ) should occur to include all the
necessary participants.</p>
<p>I suggest to <em>first</em> try to agree upon the times out when all
the participants can do their “creation work” and then fit the events
and other necessary meetings around that.</p>
<p>Combining this approach with a conscious allocation on capacity makes
it even more powerful.</p>
<h2 id="strategy-two-allocate-capacity-consciously">Strategy two:
Allocate capacity consciously</h2>
<p>Don’t just look at the days of the week as a long stream of hours
passing by. Make a conscious decision on how to invest the time
beforehand.</p>
<p>If you’re involved with some kind of process framework you probably
have some of the time allocation already done for you “daily standups”,
“plannings”, “review” and “retrospectives” to name but a few.</p>
<p>But is the rest of the time really uniform? For most of us it isn’t.
It consists of periods where I can just chop away at my work, of periods
where I need information from other people and of periods where other
people need information from me.</p>
<p>Creating even an informal and rough plan of how you intend to
allocate your time helps a lot in reasoning about the number of meetings
and makes the gut feeling a lot more tangible and negotiable.</p>
<p>Such a rough and informal plan might just look like this:</p>
<pre><code>Allocation per Week (on average)
Process related 4h (8h in total every two weeks)
Creating stuff 20h (4h per day)
Helping others 10h (2h per day)
Slack for surprises 6h (a bit over an hour per day)</code></pre>
<p>With this little list it is already much easier to argue for or
against meetings. And if we start tracking how we <em>actually</em> use
our time against this list, it usually gets even more helpful. You might
want to give it a try.</p>
<h2 id="strategy-three-plan-your-slack-ahead-of-time">Strategy three:
Plan your slack ahead of time</h2>
<p>Just put “Slack Spacers” in your agenda and remove shortly before
their time comes up. This way if someone asks you whether you have time
for them today you might well be able to say “yes” without having to
move any other appointments.</p>
<p>To be able to react to things that are happening every systems needs
some slack. If there is not enough slack in the system every little
disruption or interference will wreak havoc on the system and might even
result in a total system breakdown.</p>
<p>Back in the seventies it was “common knowledge” that in knowledge
work one should never plan out more than 60% of one’s day. Simply
because “things will happen.” How does that fit in with calendars that
are filled up to the brim for the next two weeks?</p>
<p>If you allocate specific times for “creation work” and put them in
your calendar you might already have one thing that absorbs some of the
“things that happen”, but that’s not always quite what you intended to
do with those allocated time slots.</p>
<p>A simple and effective strategy to deal with this is the usage of
“Slack Spacers” – appointments with yourself, that are just in your
agenda to make sure you don’t plan too much of time too far in
advance.</p>
<p>Those could go from 30 minute slices which you remove on the evening
of the day before they come up to 4 hour slots twice a week which you
remove on Sunday evenings. Or any other sizing and timing that works for
you.</p>
<p>Depending on your environment you might either declare them for what
they are or hide them behind inconspicuous titles like “Preparation for
the XYZ project.”</p>
<h2 id="Wrap-up">Wrap-up</h2>
<p>So these are three strategies you could put into effect right now
</p>
<ul><li>Foster collaboration by planning the time you work together</li><li>Get control of the amount of work you can do by allocating capacity deliberately</li><li>Create maneuverability by explicitly blocking time for work that shows up unannounced.</li></ul>
<p>till next time<br /> <em><a
href="http://www.michaelmahlberg.com">Michael Mahlberg</a></em></p>
Michael Mahlberghttp://www.blogger.com/profile/17228297952885873743noreply@blogger.com0tag:blogger.com,1999:blog-20337798.post-50410854660734278792022-02-27T18:00:00.005+01:002022-02-27T18:00:00.196+01:00Unplanned work is killing us – really?<p>One of the things I often hear teams complain about is the amount of unplanned work they have to handle.</p>
<h2 id="drowning-in-irrefutable-small-requests">Drowning in irrefutable small requests</h2>
<p>This unplanned work also frequently seems to be “irrefutable.” But is it? What does it mean to take up an unlimited amount of irrefutable work that has to be done right away?</p>
<p>Starting a new task immediately when it arrives means that you either have been idle when it arrived or –just as plausible– you had to put the stuff you were working on to the side. As long as you only have one item of irrefutable work at a time that might work. However the problem begins as soon as the next piece of unplanned work arrives before you were able to complete the current one.</p>
<p>In this situation you’re most probably not idle (since you’re working on the previous irrefutable piece of work) and you can’t easily put away your current work (because, well, it is also irrefutable).</p>
<p>This dynamic usually leads to a cascade of interrupted work that has been labeled as “irrefutable” and that still gets tossed in the “waiting bin” at the back end.</p>
<p>Most of the time, deciding for stuff to hunker in some “waiting“ state late in the process makes the “client” unhappy – the very person who insisted on the the irrefutability of the work.</p>
<p>This problem gets worse because often there isn’t any time to inform the original client that their work has been paused. After all, the new piece of irrefutable work had to be started <em>immediately!</em></p>
<p>Thus, even though people try to work on the requirements coming at them as fast as they can it seems to be an uphill battle without much chance of ever getting a grip on the work.</p>
<p>But is that really the only way?</p>
<h2 id="accept-reality">Accept reality</h2>
<p>Once we face the fact that in these situations things <em>will</em> take longer to be completed than the mere net working time, we can employ other approaches to get on top of the situation.</p>
<p>There is this seemingly little trick that enables us to transform unplanned work into planned work. It’s called <strong>Planning.</strong> And the cool thing is that it doesn’t have to be big.</p>
<p>Once you know how many irrefutable small request usually land in your lap each day you can re-structure your day to handle them way more effectively.</p>
<p>You can get that number either from your gut feeling, or from some simple kind of low tech metric like tally marks on a sticky-note near your keyboard. Or maybe just start with an arbitrary guess and iterate towards better numbers later.</p>
<h2 id="planning-to-plan">Planning to plan</h2>
<p>So if you come to the conclusion that if all that work came in structured you could do it in 2 hours a day on average, there are two structural elements you could introduce to your daily structure to handle this</p>
<ul>
<li>Firstly block out those two hours from your schedule. You will lose 2 hours per day anyway in which you will not be working on standard work. This is part of the “accept reality” thinking.</li>
<li>Set aside a couple of minutes for planning <em>when</em> you will work on these items and for feedback every couple of hours. Assuming you work 8 hours a day, I would take 5 minutes every two hours for “planning” which leaves us with 2 planning events per day.</li>
</ul>
<p>All you do in these 5 Minutes is a quick check whether the requests actually fall into the category of “small” request.</p>
<p>If they do, schedule them for later today or next day, based on a rough guesstimation of the amount of work you already scheduled for the respective window and the perceived importance of the task. After scheduling the request you might want to let the client know that you scheduled the item and for when.</p>
<p>If they are not of the category “small” you have a different problem at hand – here you might still want to reserve a small amount of time in the 2 hour window to draft a more detailed feedback on why this request has to be discussed on another level. Still, you do this answering as a planned activity.</p>
<p>With just accepting that the two hours you ‘lose’ per day are actually lost for standard work and subtracting 10 more standard-work-minutes from your working day, you can probably convert 90% of your unplanned work into planned work. Without adding to the actual customer lead time of the items that used to ruin your day in the form of unplanned work.</p>
<p>And as almost every situation is unique, you most probably will have to come up with different numbers, but the general principles statet here should be applicable to most situations.</p>
<p>till next time<br /> <em><a href="http://www.michaelmahlberg.com">Michael Mahlberg</a></em></p>
Michael Mahlberghttp://www.blogger.com/profile/17228297952885873743noreply@blogger.com0tag:blogger.com,1999:blog-20337798.post-8133378515072241862022-02-13T18:00:00.010+01:002022-03-21T21:37:21.890+01:00Is the user story overrated? Some story patterns and formats to learn from<p>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?</p>
<h2 id="we-all-know-what-a-story-is-dont-we">We all know, what a story is, don’t we?</h2>
<p>Let’s try this one on, for size:</p>
<blockquote>
<p>“Once upon a time, there was… <em><strong>here goes the story</strong></em> … ever after”</p>
</blockquote>
<p><em>That’s</em> the kind of story that most people in the real world think about, when they hear the term “story.”</p>
<h2 id="in-the-agile-realm-stories-seem-to-be-a-different-kind-of-beast">In the agile realm stories seem to be a different kind of beast</h2>
<p>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 <a href="https://www.mountaingoatsoftware.com/blog/why-the-three-part-user-story-template-works-so-well">“requirements packaged in the form of a story”</a> is the central element that everything revolves around.</p>
<p>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 <a href="https://twitter.com/ronjeffries/status/1131641856398438401?lang=en">“I […]may have invented story points, and if I did, <em>I’m sorry now.</em>”</a></p>
<p>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</p>
<ul>
<li>starts with <em>“As a <role>…”</em>,</li>
<li>has an important <em>“…I want <System behavior>…”</em> in the middle</li>
<li>and –in the better cases– ends with <em>“…so that <desired business effect>.”</em></li>
</ul>
<p>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”<a href="#fn1" class="footnote-ref" id="fnref1" role="doc-noteref"><sup>1</sup></a> in the first place.</p>
<h2 id="how-stories-came-to-software-development">How stories came to software development</h2>
<p>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.</p>
<p>In Scrum they had the PBI (Product Backlog Item), in Crystal the use case was somewhat prominent, other approaches used comparable artifacts. <a href="http://www.extremeprogramming.org/index.html" title="extremeprogramming.org – one of the older sites centered on eXtreme Proggramming">Extreme Programming</a> was the one that used something called a <em><a href="https://wiki.c2.com/?UserStory">User Story</a></em>.</p>
<p>This concept of the user story somehow had such an appeal, that many of the other approaches embraced the idea – more or less.</p>
<h2 id="it-was-more-about-the-telling-than-about-the-story">It was more about the telling, than about the story</h2>
<p>A key component behind the idea to use “stories” has even made it into the <em>Manifesto for Agile Software Development</em> – To quote the sixth principle from that manifesto</p>
<blockquote>
<p>“The most efficient and effective method of<br />
conveying information to and within a development<br />
team is face-to-face conversation.”</p>
</blockquote>
<p>Before the recommendation that requirements should be <em>talked</em> about was written down in that form, it was embodied in ideas like <em>CCC</em> <a href="https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/">Card – Conversation – Confirmation</a> or the nice quote from <a href="https://www.oreilly.com/library/view/extreme-programming-installed/0201708426/">the Book <em>XP-Installed</em> from the year 2000</a> that a card is a <strong>promise</strong> to have a <em>“series of conversations about the topic.”</em></p>
<p>Unfortunately, in today’s world the concept of <a href="http://www.extremeprogramming.org/rules/customer.html">On-site customers</a> often has been reduced to a person who is <em>called</em> Product Owner but doesn’t have any real business authority and spends about two <em>hours</em> with the team every two <em>weeks</em>. Under these circumstances it seems questionable whether this approach to product development is still viable for all cases.</p>
<p>But I am convinced that understanding <em>why</em> 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.</p>
<p>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.</p>
<h3 id="dont-put-the-story-in-the-center-focus-on-the-value-and-the-work-item">Don’t put the story in the center, focus on the value and the work item</h3>
<p>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.</p>
<p>Such a work item –to go with the broader term– can have many structures. A few common attributes of many such item types are:</p>
<ul>
<li>Creator</li>
<li>Expected value</li>
<li>“The Actual Requirement”</li>
<li>Currently responsible person</li>
<li>Estimated effort (<a href="https://www.mountaingoatsoftware.com/blog/its-effort-not-complexity">Yes, I really mean effort - as Mike Cohn explains, too</a>)</li>
<li>Technical risk/complexity (<a href="https://lizkeogh.com/2013/07/21/estimating-complexity/">Liz Keogh has some helpful suggestions on that</a>)</li>
<li>and many more.</li>
</ul>
<p>Of course, one of the attributes needs to be the actual requirement. And that <em>could</em> be represented by a story. But does that have to be a user story? Actually, there are some pretty helpful alternatives out there.</p>
<h3 id="if-you-use-some-kind-of-story-get-to-know-several-types-of-stories-well">If you use some kind of story, get to know several types of stories well</h3>
<p>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.</p>
<h4 id="stakeholder-story">Stakeholder Story</h4>
<p>After the “As a «role» I want…” format for user stories had been around for quite a while, <a href="https://twitter.com/lunivore">Liz Keogh</a> pointed out that many of the so called <em>user stories</em> out there are not actual <em>user stories</em> but instead Stakeholder Stories.</p>
<ul>
<li>Format of the <em>Stakeholder Story</em>
<ul>
<li><p>Liz Keogh described her ideas and observations in the <a href="https://lizkeogh.com/2010/02/02/theyre-not-user-stories/">2010 Article “They’re not User Stories.”</a></p></li>
<li><p>The generic form of this kind of story –the way I use it these days– is</p>
<ul>
<li><blockquote>
<p>In order to «the required business effect»</p>
</blockquote></li>
<li><blockquote>
<p>«some stakeholder or stakeholder persona»</p>
</blockquote></li>
<li><blockquote>
<p>«wants,need,requires,…» «some kind of system behavior or future state»</p>
</blockquote></li>
</ul></li>
</ul></li>
<li>Context for the <em>Stakeholder Story</em>
<ul>
<li>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.<br />
</li>
<li>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.”)</li>
</ul></li>
<li>Caveats for the <em>Stakeholder Story</em>
<ul>
<li>The stakeholder should be as tangible and concrete as possible. Unlike with the model of <a href="https://www.function1.com/2015/07/user-centered-design-user-personas-vs-user-stories">personas in user stories</a> for stakeholders in user stories, it is extremely helpful to name a real person for stakeholders in stakeholder-stories.<br />
</li>
</ul></li>
<li>What to avoid for the <em>Stakeholder Story</em>
<ul>
<li>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.</li>
</ul></li>
</ul>
<h4 id="user-story">User Story</h4>
<p>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 <a href="https://www.mountaingoatsoftware.com/blog/why-the-three-part-user-story-template-works-so-well" title="This template originated with agile coach Rachel Davies at an English company, Connextra, in the early 2000s.">post about the three part user story tells us</a>)</p>
<ul>
<li>Format of the <em>User Story</em>
<ul>
<li><p>The now prevalent way to capture user stories is the well known</p></li>
<li><blockquote>
<p><em>“As a</em> «role or persona» <em>I want</em> «system behavior» <em>so that</em> «desired business outcome»<em>.”</em></p>
</blockquote></li>
<li><p>This is described (amongst other sources) in the often quoted Article <a href="https://www.mountaingoatsoftware.com/blog/why-the-three-part-user-story-template-works-so-well">Why the Three-Part User Story Template Works So Well</a> by Mike Cohn.</p></li>
</ul></li>
<li>Context for the <em>User Story</em> in this sense
<ul>
<li>Helpful if you really have a product (sometimes a project and seldomly a service) that has actual interactions with actual users</li>
</ul></li>
<li>Caveats for the <em>User Story</em> in this sense
<ul>
<li>It should describe an interaction between a user and a system that will be possible after the requirements has been implemented.</li>
</ul></li>
<li>What to avoid for the <em>User Story</em>
<ul>
<li>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 <em>User Stories</em>.</li>
</ul></li>
</ul>
<h4 id="job-story">Job Story</h4>
<p>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.</p>
<p>Thanks to my esteemed colleague <a href="https://twitter.com/mbohlende">Matthias</a> I learned about the job story format and the <a href="https://www.intercom.com/blog/using-job-stories-design-features-ui-ux/">whole idea of using job stories</a> to work on product ideas</p>
<ul>
<li>Format of the <em>Job Story</em>
<ul>
<li>The article <a href="https://jtbd.info/replacing-the-user-story-with-the-job-story-af7cdee10c27">Replacing The User Story With The Job Story</a> describe the idea of the Job Story as separating situation, motivation and expected outcome by using the format</li>
<li><blockquote>
<p>When ________, (the situation part)</p>
</blockquote></li>
<li><blockquote>
<p>I want to ________ (the motivation part)</p>
</blockquote></li>
<li><blockquote>
<p>so I can ________ (the expected outcome part)</p>
</blockquote></li>
</ul></li>
<li>Context for the <em>Job Story</em>
<ul>
<li>Good for very young stories, when you still try to figure out what you’re really talking about.</li>
</ul></li>
<li>Caveats for the <em>Job Story</em>
<ul>
<li>Unlike <em>Stakeholder Stories</em> and <em>User Stories</em>, <em>Job Stories</em> 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.</li>
</ul></li>
<li>What to avoid for the <em>Job Story</em>
<ul>
<li>Don’t treat it like a piece of functionality that just needs to be executed. <em>Job Stories</em> make for good candidates or the narrative flow of <a href="https://www.jpattonassociates.com/the-new-backlog/" title="The original article in which Jeff Patton describes the Story Map concept">Story Maps</a>. There’s also an <a href="https://www.jpattonassociates.com/story-mapping-quick-ref/" title="A two page pdf explaining the Story Map elements">2-page summary explanation of Story Maps</a> if you want to know more about that concept.</li>
</ul></li>
</ul>
<p>Of course this only covers <em>some</em> aspects of the usage of stories in todays post-agile society, and I would strongly encourage anyone to look (deeply) into the stuff about <a href="https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/">INVEST and SMART</a> and at <a href="https://www.jpattonassociates.com/story-mapping/">User Story Mapping</a>, 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 <em>“As a «Role» I want…”</em> format.</p>
<p>till next time<br /> <em><a href="http://www.michaelmahlberg.com">Michael Mahlberg</a></em></p>
<section class="footnotes footnotes-end-of-document" role="doc-endnotes">
<hr />
<ol>
<li id="fn1" role="doc-endnote"><p>(Remember: <a href="https://agile-aspects.michaelmahlberg.com/2022/01/there-is-no-agile-manifesto.html">There is not really an Agile Manifesto</a>)<a href="#fnref1" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
</ol>
</section>
Michael Mahlberghttp://www.blogger.com/profile/17228297952885873743noreply@blogger.com0tag:blogger.com,1999:blog-20337798.post-38531552067990530542022-01-30T05:00:00.009+01:002022-01-30T05:00:00.205+01:00There is no Agile Manifesto<p>Just a little reminder: what many people nowadays think is a way of living or even a way of designing whole organisations was originally something quite different…</p>
<p>What most people call <a href="http://agilemanifesto.org">“The Agile Manifesto”</a> actually has a title.</p>
<blockquote>
<p>it is called <strong>Manifesto for Agile Software Development</strong></p>
</blockquote>
<p>And its authors propose the “Twelve Principles of Agile <strong>Software.</strong>”</p>
<ul>
<li>It does not specify a defined approach to continuous improvement – TPS (<a href="https://en.wikipedia.org/wiki/Toyota_Production_System">Toyota Production System</a>) does that, for example</li>
<li>It does not elaborate on good ways to optimize lead times – The ToC (<a href="https://en.wikipedia.org/wiki/Theory_of_constraints">Theory of Constraints</a>) does that, for example</li>
<li>It does not express any opinion on how a company should be structured in the post-Taylor era – <a href="https://en.wikipedia.org/wiki/Sociocracy">Sociocracy</a> and its derivates do that for example. So does <a href="https://en.wikipedia.org/wiki/New_Work">New Work</a></li>
<li>It does not tell anyone how to handle finances without upfront budget plans – <a href="https://en.everybodywiki.com/Beyond_Budgeting">Beyond Budgeting</a> does that, for example</li>
</ul>
<p>And all of the approaches on the right hand side came into existence long <em>before</em> 2001, the year the “Manifesto for Agile Software Development“ was drafted.</p>
<p>If you look a bit further on the original web-page that launched the term “Agile” into the world, you’ll find that in the section “About the Manifesto” as well as in the headline above the twelve principles, it has been called “The Agile Manifesto” even by its authors. Maybe this helps explaining some of the confusion.</p>
<p>Personally, I find it very helpful to remember the context where the whole idea of “Agile” came from – maybe it’s helpful for you, too.</p>
<p>till next time<br /> <em><a href="http://www.michaelmahlberg.com">Michael Mahlberg</a></em></p>
Michael Mahlberghttp://www.blogger.com/profile/17228297952885873743noreply@blogger.com3tag:blogger.com,1999:blog-20337798.post-76505591457074966362021-05-16T16:56:00.020+02:002021-05-16T16:56:00.206+02:00The difference between acceptance criteria and the definition of done<p>When it comes to building things, we often want to know when it's really done. Two terms have gained popularity over the last couple of years within the realms of software development and other areas that use spillover ideas from the agile movement. These two concepts are acceptance criteria and the definition of done. Unfortunately those concepts are often mixed up which leads to subpar results.</p>
<p>The distinction can be pretty short: the definition of done (DoD) is a property of a process-step, while acceptance criteria are properties of a request for a capability. However, the question remains: why does it matter?</p>
<h2>Let’s clarify some terms</h2>
<p>I intentionally used the uncommon way to refer to a requirement as “a request for a capability“ to avoid notions such as story, requirement, feature, epic etc. Sometimes just saying what we actually mean instead of using an overused metaphor can make things much clearer. For now I will call “requests for a capability” simply <em>work items</em>, since that term has –at least up until now– very few connotations. </p>
<h3>Where does the definition of done come from, and what does it mean?</h3>
<p>To be perfectly honest I don't <em>exactly</em> know where the phrase came from. (I'll come back to Scrum in the postscriptum below) I've heard jokes about “If it works on your machine, you're about 80% done” and “do you mean done, or do you mean done done“ since the 80s. So obviously it's not really a new phenomenon that it's hard to tell when something really is done. </p>
<p>The term became more formalized, especially in the Scrum community between 2005 and 2011, when “Definition of done” became a top-level topic with it’s own heading in the scrum-guide. In this context the definition of done is the sum of all quality requirements a work item has to fullfil to be considered “done.” </p>
<p>If we look at it from a process perspective, this is a policy <strong>all</strong> work items have to comply with before they can move from “working on it” to “done.”</p>
<p><a href="https://www.dropbox.com/s/0zmye74pvjtlyi3/DoD-DoNotPass.png?raw=1"><img src="https://www.dropbox.com/s/g4xv8sn0spnmhpx/DoD-DoNotPassPreview.png?raw=1" alt="where the DoD applies"></a></p>
<h3>Who brought us acceptance criteria, and why?</h3>
<p>Again, the origins are lost in the depth of time. At least to me. But the first experiences I had with them as a part of agile software development were back in my earlier XP-days, around the turn of the century. </p>
<p>At that time it was “common practice” (at the places I was around) to put requirements on cards. And when the time came to find the answer to “how would you know that this item was done” with the onsite customer, we just flipped over the card and jotted his acceptance criteria on the back of the card. </p>
<p>Those acceptance criteria hardly ever included anything technical, let alone any requirements regarding the documentation or in which source code repository it should reside. Those things were captured by our working agreements. In a section that nowadays would be called definition of done. </p>
<p>The acceptance criteria usually were things the customer would be able to do with the system once the requirement had been implemented. Someting like: “I can see the list of all unbooked rooms in an area when I search by zip code“ as <em>one</em> acceptance criterion for a card called “find available rooms” in a booking system.</p>
<p>Remember that these were the days of real <a href="http://www.extremeprogramming.org/rules/customer.html">on-site customers</a> in a high trust environment and stories were written according to the CCC idea of <a href="https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/">Card – Conversation – Confirmation</a>. Therefore it was quite okay to have such a vague acceptance criterion, where there was no up-front definition of what a “search by zip-code” actually means or how the “unbooked rooms” state had to be determined. </p>
<p>Nowadays these acceptance criteria are sometimes formulated as BDD or ATDD style <em><a href="https://automationpanda.com/2017/01/27/bdd-101-gherkin-by-example/">scenarios and examples</a></em>, wich allows for very concrete and specific acceptance criteria (but without enforcing them).</p>
<h2>Now, what <em>is</em> the difference between acceptance criteria and the definition of done?</h2>
<p>After we defined the terms, the terse explanation from above <em>“the definition of done (DoD) is a property of a process-step while acceptance criteria are properties of a request for a capability”</em> might actually make sense. </p>
<p>So, the «defintion of done» is a rule that applies to all the work items in the system and is a policy on a very specific edge between two columns on a board, namely the edge separating the “done” column from the one right before it. In contrast, «acceptance criteria» give the answer to the question “what functionality does the system have to provide to consider this work-item to conform to the customers expectations?”</p>
<p>And so, both are necessary and neither is a replacement for the other. Acceptance critery go with work items, and the definition of done goes with the system. </p>
<p>till next time<br />
<em><a href="http://www.michaelmahlberg.com">Michael Mahlberg</a></em> </p>
<h3>P.S. In most real life settings, processes tend to have more policies than just the definition of done.</h3>
<p>And some of them describe the expections at process boundaries. If you use the Kanban method to model these processes you would naturally make these policies explicit as well, like <a href="https://agile-aspects.michaelmahlberg.com/2017/04/do-we-have-definition-of-ready-dor-and.html">I described in an earlier post</a>.</p>
<h3>P.P.S.: Scrum didn't start of with the now prominent <a href="https://scrumguides.org/scrum-guide.html#commitment-definition-of-done">Definition of Done</a> as a first class citizen.</h3>
<p>In the original books, that used to be literally required reading for aspiring scrum masters in 2005 –<a href="https://amzn.to/3eiMHbp">Agile Software Development With Scrum[ASD]</a> and <a href="https://amzn.to/3eiMHbp">Agile Project Management with Scrum [APM]</a>– there is “Done” on the same level as “Burndown”,“Iteration”,“Chicken” and “Pig" [APM, p141] and no notion of "Definition of Done" in either of the books. </p>
<p>Even in the Scrum Guide from 2010 –one year before the DoD moved up and got its own headline– there are paragraphs like</p>
<blockquote>
<p>If everyone doesn’t know what the definition of “done” is, the other two legs of empirical process control don’t work. When someone describes something as done, everyone must understand what done means.</p>
</blockquote>
<p>But still not yet quite the now seemingly well established term “Definition of Done” that we see today.</p>
Michael Mahlberghttp://www.blogger.com/profile/17228297952885873743noreply@blogger.com0tag:blogger.com,1999:blog-20337798.post-13531367953096229592021-03-14T17:43:00.001+01:002021-03-14T17:43:00.160+01:00Options can be expensive -- not only at the stock market<p>What do you actually get, when you buy a cinema ticket? (In those
ancient times when cinemas were still a thing) </p>
<p>You <em>buy</em> yourself an <em>option</em>. The right --but not the obligation-- to execute an operation at a later time. In this case the right to watch a certain movie at a
certain time.</p>
<p>The cinema, on the other hand, <em>sells</em> a <em>commitment</em>. They are (to a
degree) obliged to actually show that specific movie at the stipulated
time. If we look at it like this, it is a considerable investment the
cinema promises, in exchange for those couple of bucks your option
costs.</p>
<p>And while it is often thought to be helpful to think in options, it is
also almost always important to make sure that you're on the right side
of that transaction.</p>
<h2>Where's the problem with options?</h2>
<p>What does that mean for our day-to-day actions? If we hand out options
too freely, we quickly end up in a quagmire of "maybes" that is hard to
get out of. As I mentioned in an <a href="https://agile-aspects.michaelmahlberg.com/2012/09/real-options-revisited.html">earlier
post</a>,
the whole thinking around real options in the way Olav Maassen and Chris
Matts describe in their book <a href="https://amzn.to/3dGbm9J">"Commitment"</a>, is
quite fascinating and well worth a read. But for today let's just look
at one thing we don't do often enough, when we use options in our
personal lives.</p>
<p>We tend to offer options without an expiry date. And that can leave us
with a huge amount of commitments, and very few options left for
ourselves. One of the prime offenders here is doodle (or similar meeting
planners) and the way they are often used these days. Just the other day
I got a doodle poll for 58 30-minute slots stretched over two weeks.
Scheduled in about six months from now. And the closing date for these
options was meant to be set three <sic> months in the future. So worst
case, I would have committed to keep 29 hours blocked for three months.
Which would have left me unable to actually plan <em>anything</em> for those
weeks in the next three months.</p>
<p>Of course doodle only makes this <em>visible</em> – it happens all the
time. Look at this scenario:</p>
<ul>
<li><p>We could go on vacation either at the beginning of the summer break
or at the end</p></li>
<li><p>I could renovate the shelter either in the beginning of the summer
break or towards the end</p></li>
<li><p>Our kids could go on their "no parents camping weekend" either in
the beginning of the summer break or at the end</p></li>
</ul>
<p>For as long as you don't decide the first one of these, those options
create a deadlock.</p>
<p>And the situation makes it almost impossible to actually decide <em>anything</em>
related to the summer break as well, for that matter.</p>
<h2>Set an expiration date to ease the pain</h2>
<p>The solution is simple, really. But it takes some uncommon behavior to
apply it. Let's look at the way the stock market handles options.
Options at the stock market have a window of execution and an expiry
date. Once that date has passed the option can no longer be converted.
Merely adding this expiry date, already mitigates the risk of too many
open ended options even for the side which holds the commitment end of
it.</p>
<p>A lot of options that we encounter have this attribute of an expiration
date in one way or another: When we get a quote for some repair work for
our house, car or even bicycle, it usually says "valid until." The same
is true for business offers, medical quotes, and almost everything we
consider as "business."</p>
<p>Amending the options we hand out with expiration dates, even if it is
not in a formal business setting, may feel a little strange at first.
But it makes life so much easier. Whether it's toward a colleague, a
significant other, friends or even yourself. Reducing the amount of open
options also reduces the number of times you have to say "I don't know
yet, I <em>might</em> have another engagement."</p>
<p>till next time<br />
<em><a href="http://www.michaelmahlberg.com">Michael Mahlberg</a></em></p>
Michael Mahlberghttp://www.blogger.com/profile/17228297952885873743noreply@blogger.com0tag:blogger.com,1999:blog-20337798.post-68112294671890888112021-02-14T18:00:00.002+01:002021-02-16T23:14:25.107+01:00How to do physical {Kanban|Task|Scrum} boards virtually<p>As I’ve mentioned earlier <a href="https://agile-aspects.michaelmahlberg.com/2015/05/boards-paper-vs-digital-when-how-and-why.html">most of the time it is a good idea to start visualization with a <em>physical</em> board.</a> And very often it is a good idea to <em>stick</em> with that. For all the reasons that make it worthwhile to <em>start</em> with it. </p>
<p>One of the biggest advantages of a physical board is the one thing that command and control organizations perceive as it’s biggest drawback: <em>A physical board knows nothing about the process.</em></p>
<p>The fact that the physical board knows nothing about the process forces the people who use it, to actually <em>know</em> 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.</p>
<p>As my esteemed colleague <a href="https://twitter.com/simonkuehn">Simon Kühn</a> put it all those years back: <strong>The intelligence is <em>in front</em> of the board.</strong> </p>
<h3>But we’re all working remote now</h3>
<p>Now, that we‘re not in a shared office space anymore, <em>real</em> 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. </p>
<p>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. </p>
<p>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.</p>
<h3>What are the big advantages of a physical board?</h3>
<p>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. </p>
<p>One could say <strong>“individuals and interaction over workflows (process) embedded somewhere in a ticket system (tool)”</strong> – just to reiterate the first value pair from the <a href="http://agilemanifesto.org">Manifesto for Agile Software Development</a> as an argument for “physical” boards. </p>
<p>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.</p>
<p>And as <a href="https://blog.codinghorror.com/boyds-law-of-iteration/">Boyd’s law of iteration</a> says: <strong>speed of iteration beats quality of iteration.</strong></p>
<p>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.</p>
<h3>But where do the details go?</h3>
<p>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.</p>
<p>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. </p>
<p>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.</p>
<p>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. </p>
<p>A: But do you need them <em>on</em> the card? Wouldn‘t they better be put on a documentation page?</p>
<p>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. </p>
<h3>But what about metrics?</h3>
<p>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. </p>
<p>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 <em>start</em> by collecting the metrics manually. </p>
<p>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. </p>
<p>And some of the most important metrics are actually <a href="https://agile-aspects.michaelmahlberg.com/search?q=most+important">easy to evaluate</a> and some of them <a href="https://www.jrothman.com/mpd/2021/01/low-tech-way-to-visualize-your-percentile-confidence-for-forecasts/">even easier to capture</a>. </p>
<p>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. </p>
<p>till next time<br />
<em><a href="http://www.michaelmahlberg.com">Michael Mahlberg</a></em></p>
Michael Mahlberghttp://www.blogger.com/profile/17228297952885873743noreply@blogger.com0tag:blogger.com,1999:blog-20337798.post-73997917007209821112021-01-30T18:00:00.004+01:002021-01-30T18:00:02.836+01:00The benefits of continuous blocker clustering<p>If you manage your work by using some kind of visualization, the chances are high that you also visualize your blockages. </p>
<p>One of the most common visualizations is some kind of task board that represents the subsequent stages work items go through. Assuming you have such a board it can be quite helpful to visually mark which of those work items are currently blocked. This enables the whole team or organization (depending on the scope of your board) to see where work is stuck and to do something about it.</p>
<p>Usually (in the physical world ) these markers had the form of post-it notes in a different color and denoting the reason for the blockage. If you add just a little bit additional information, these blockers can be utilized to identify typical hindrances in the flow. Information you might want to gather are a reference to the original work item this blocker was attached to, the time(stamp) the blockage occurred and the time(stamp) it was solved.</p>
<p>In the Kanban community there is a practice known as “blocker clustering” where all involved parties come together at specific points in time and cluster these blockers according to things that stand out once you try to sort them and categorize them. </p>
<p>Blocker clusters can be either things like “Waiting for department «X»” or “Problems with system «Y»” or something completely different like “discovered missing information from phase «Z»” – that really very much depends on your individual environment. And usually these blocker clusters change over time. And so the should.</p>
<p>Now, here’s an idea: why only do this at certain intervals? Just as pair-programming in software development could also be called continuous code-review, the practice of blocker clustering could be done each time a blocker is resolved. </p>
<p>Granted, this wouldn’t make the big blocker clustering superfluous. After all that is where all concerned parties can decide whether they want to treat the resulting blocker clusters as special case variation –where one-off events caused the blockage– or common cause variation, where the blockage is caused by things that happen “all the time”. </p>
<p>The distinction between these two kinds of variation in the flow is important. One of them, the special case variation, hast to be handled on a case by case basis, whereas the other one is a great opportunity for structural improvements in the way you work. </p>
<p>And this is where continuous blocker clustering really can make a difference. Instead of waiting for the big blocker clustering, people come together and decide into which blocker cluster the blocker goes as soon as it is finished. This doesn’t have to happen in a separate meeting. </p>
<p>After all, the blocker (and the way it got solved) would be announced in the next board walk anyway. Which is also a good place to have this discussion. </p>
<p>And once you do continuous blocker clustering, you can have additional agreements like for example: If there are more than five new blockers in a category you can immediately (or at least <em>very</em> shortly afterwards) come together to discuss whether you want to treat this as a new common cause variation and whether you see a chance to improve your way of working together to address this new common cause. The number <em>five</em> is just an arbitraty number, depending on things like number of people involved, throughput etc. <em>your</em> numbers will differ. </p>
<p>You could also have an agreement to hold such a meeting whenever you have collected five blockers that you couldn’t categorize into a blocker cluster in less than 2 minutes and were therefore grouped under “uncategorized”. (Another working agreement.) The opportunities for demand driven improvements through this approach are vast. </p>
<p>The same basic idea is behind the concept of signal-based Kaizen meetings, that happen whenever specific –agreed upon– circumstances trigger the need for improvement and invoke a spontaneous get-together of the involved parties. Opposed to having only improvement meetings at fixed intervals this makes for much tighter feedback loops and thus enables quicker improvement.</p>
<p>till next time<br />
<em><a href="http://www.michaelmahlberg.com">Michael Mahlberg</a></em> </p>
<p>(Special note for people who rely solely on jira: It is a bit hard to implement this is an easy way in jira, but it is possible. And also helpful. But it does include some creative use of fieldvalues, some JQL-Fu and some dedicated Jira-boards. Keep in mind that Jira-Boards are nothing more, and nothing less, than a visualized database query. There’s a lot of power in that, once you start moving beyond the pre-packed solutions.)</p>
Michael Mahlberghttp://www.blogger.com/profile/17228297952885873743noreply@blogger.com0tag:blogger.com,1999:blog-20337798.post-1863080244813826692020-08-09T17:13:00.002+02:002020-08-09T17:13:00.157+02:00Bringing Agile to non-IT work... those who don't remember history are doomed to repeat it<p>People tend forget that many of the agile approaches borrowed heavily
from the Toyota Production System and its relatives, commonly known
under the umbrella term "Lean."</p>
<p>These days we're experiencing an interesting development. People try to
bring things they perceive as "typical agile practices" to non-IT work.
For knowledge workers --<a href="https://en.wikipedia.org/wiki/Knowledge_worker#History">a term coined by Peter Drucker in the
1960s</a>-- this
might perhaps be a valid approach. Even though I doubt it. For
non-knowledge-worker work on the other hand, I would like to point out
what happened here. Approaches taken from the Lean context of shop-floor
management and vehicle design, related to continuous improvement and
optimizing the flow of work, were translated into a very different
environment -- that of software development. And even the considerable
body of knowledge from other fields of expertise that is at the
foundation of agile was put into a very specific context here. Actually,
the so-called "agile manifesto" is called "Manifesto for Agile Software
Development" and thus very specific with regards to the domain it
targeted. So nowadays, when people try to "apply Agile to non-IT
situations", they basically take the adaptations that have been made to
non-IT approaches to make them helpful in Software Development and try
to re-apply what's left of them back to non-IT work. Of course the
original non-IT approaches have also evolved since the days that --just
to pick an example-- Ken Schwaber and Jeff Sutherland read 1986 paper "<a href="https://www.agilepractice.eu/wp-content/uploads/2016/09/Product-Development-Scrum-1986.pdf" title="The original article by Takeuchi and Nonaka from 1986 that already make use of the scrum metaphor">The new new
product development game</a>" (sic!), and took parts of those ideas as a
foundation of their own agile approach (Scrum). Hence it seems kind of
silly to me to derive ideas for modern ways to organize non-IT work from
the spin-offs from more than two decades ago instead of going directly
to the source.</p>
<p>Of course sometimes re-applying the stuff we learned from agile software
development actually works, but I think going directly to the source is
a much better idea. Perhaps instead of trying to derive the helpful
approaches non-knowledge-worker work from the shadows they cast unto the
walls of the Agile world --to paraphrase Plato-- it might be a good idea
to look at the origins and try to understand the <em>original</em> approaches
to non-knowledge-worker work. Of course, oftentimes non-knowledge-worker
work was simply called <em>"work"</em>, back in the day. Directly adopting from
approaches like Lean (from the 1950s) or New Work (which originated in
the 1970s) might be an approach to improving work that avoids the
'Chinese-whispers' effect of the indirect approach via "Agile."</p>
<p>To end on a more positive note: the Kanban method is a great example of
an approach that targets the challenges of the (non-it) knowledge worker
and brings ideas from Lean and similar fields into a new context. And
even though many people use the Kanban method in the realm of IT, it has
many equally --if not more-- effective applications outside of IT. Maybe
that's because the Kanban method avoids the triangulation via the older
agile approaches and builds directly upon the common ancestors. I guess
that is one of the reasons why <a href="https://dzone.com/articles/how-kanban-got-hot-david">David Anderson called the Kanban method
"post-agile" even back in
2010</a>.</p>
<p>till next time</p>
<p> <a href="http://www.michaelmahlberg.com"><em>Michael Mahlberg</em></a></p>Michael Mahlberghttp://www.blogger.com/profile/17228297952885873743noreply@blogger.com0tag:blogger.com,1999:blog-20337798.post-64909884384781368522020-05-24T16:46:00.000+02:002020-05-26T15:11:30.330+02:00Error: Customer unavailable! How do you manage flow now?<p>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. </p>
<p>Now what?</p>
<p>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. </p>
<p>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? </p>
<p>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 <a href="https://agile-aspects.michaelmahlberg.com/2016/09/how-about-some-wiscy-in-product.html">wiscy approach</a> where you start defining the result (e.g. by programming) without even knowing the requirements. </p>
<p>Let’s look at the implications of each approach.</p>
<p>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.</p>
<h2>Option 1: put a blocker on the card if the customer is unavailable</h2>
<p>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. </p>
<p>The important point here is that blocking the card fosters learning <strong><em>inside</em></strong> 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 <em>per se</em>.</p>
<h2>Option 2: discard –or abandon– the work</h2>
<p>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. </p>
<p>Here the systemic aspect is that discarding or abandoning a card fosters learning <em><strong>outside</strong></em> 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.</p>
<h2>Either way: it is a chance for learning</h2>
<p>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.</p>
<p>till next time<br />
<em><a href="http://www.michaelmahlberg.com">Michael Mahlberg</a></em></p>
Michael Mahlberghttp://www.blogger.com/profile/17228297952885873743noreply@blogger.com0tag:blogger.com,1999:blog-20337798.post-60912444192298532622020-04-26T16:10:00.000+02:002020-04-28T11:45:35.194+02:00Handling recurring work - some options from Lean and TPS<p>As someone who draws from the Kanban Method and its <a href="https://en.wikipedia.org/wiki/Lean_manufacturing">Lean</a> and <a title="Toyota Production System (Explained by Toyota)" href="https://global.toyota/en/company/vision-and-philosophy/production-system/">TPS</a> ancestors when supporting change in organizations I regularly come across the question of “how to handle recurring work?”</p>
<p>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.</p>
<p>I originally got the basic idea to adapt Kamishibai boards (see below) from <span class="citation"><a href="https://twitter.com/lukasdonschmidt">@LukasDonSchmidt</a></span> 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?)</p>
<h3 id="capacity-allocation-and-recurring-work">Capacity allocation and recurring work</h3>
<p>Assuming that you visualized your work using some kind of board and you use <a title="formerly known as WIP limits ;-)">WIP-targets</a> 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 <a href="https://www.reliableplant.com/Read/14703/one-piece-flow">single-piece flow</a>, 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.<br />
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.</p>
<p><a href="https://www.dropbox.com/s/bh9u6wdnxf61gbv/BigItemsOnly.jpeg?raw=1"><img src="https://www.dropbox.com/s/bh9u6wdnxf61gbv/BigItemsOnly.jpeg?raw=1" width="300"></a></p>
<p>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” ((<a href="http://agile-aspects.michaelmahlberg.com/2018/04/do-i-really-have-to-on-options-and.html">Options for others</a>, but things the people from our little agency <a href="http://agile-aspects.michaelmahlberg.com/2018/04/do-i-really-have-to-on-options-and.html">committed to</a>) to six <em>“announced”</em> articles and agreed to have a target number of articles they’re <em>“writing”</em> 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 <em>“copy edit”</em> stage and one in the <em>“delivery”</em> stage. The <em>“done”</em> column in the example is unlimited (∞) and the invoicing process seems not to be part of this board.</p>
<p>But is this kind of work really the only thing that has to be done in this small company? Of course not.</p>
<p>Let’s take invoicing for example. Even if we assume that writing the invoice and sending it out is part of <em>“delivery”</em> 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.</p>
<p>Taking the approach of capacity allocation a first solution might look like this:</p>
<p><a href="https://www.dropbox.com/s/5v917sspd5cp15r/BigAndSmallOneBoard.jpeg?dl=0"><img src="https://www.dropbox.com/s/5v917sspd5cp15r/BigAndSmallOneBoard.jpeg?raw=1" width="300"></a></p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>So, a more realistic model might only include columns like “options”, “doing”, and “ready to reschedule.”</p>
<p><a href="https://www.dropbox.com/s/6jtz6f40kl8o3tr/BigAndSmallSwimlanes.jpeg?dl=0"><img alt="Picture of a two swimlane board with different workflows for Standard and repeating work" src="https://www.dropbox.com/s/6jtz6f40kl8o3tr/BigAndSmallSwimlanes.jpeg?raw=1" width="300"></a></p>
<p>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.</p>
<p>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.</p>
<p>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 <a href="https://agile-aspects.michaelmahlberg.com/2014/08/bigger-and-smaller-pieces-in-flow-think.html">Heijunka</a> (workload levelling) in the way I mentioned in <a href="https://agile-aspects.michaelmahlberg.com/2014/08/bigger-and-smaller-pieces-in-flow-think.html">my earlier post</a>.</p>
<h3 id="enter-kamishibai">Enter kamishibai…</h3>
<p>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 <a href="https://en.wikipedia.org/wiki/Lean_manufacturing">lean production</a>. Like other things from lean (e.g. <a href="https://agile-aspects.michaelmahlberg.com/2014/09/gradually-changing-system-team-company.html">5S</a>), visual management has to be adapted to knowledge work to reap its benefits in this realm as well. <a href="https://blog.gembaacademy.com/2006/11/21/what_is_a_kamishibai/">Kamishibai</a> boards, which are sometimes used for recurring <em>audits</em>, can be used quite nicely to manage recurring <em>tasks</em> with low complexity like the ones described in the example above.</p>
<p>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.</p>
<p>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.</p>
<p><a href="https://www.dropbox.com/s/fpzwrc2padny41h/SimpleKamishibai.jpg?dl=0"><img alt="Picture of a very simple Kamishibai-Board" src="https://www.dropbox.com/s/fpzwrc2padny41h/SimpleKamishibai.jpg?raw=1" width="300"></a></p>
<p>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.</p>
<h3 id="do-you-have-to-do-actual-board-design-for-this">Do you have to do actual board design for this?</h3>
<p>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 <em>everyone</em> 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.”</p>
<p>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…).</p>
<p><a href="https://www.dropbox.com/s/jf6qvr3dl6ny08i/Makeshift-T-Card-holder.jpg?dl=0"><img alt="Picture of a DIY T-Card-Holder" src="https://www.dropbox.com/s/jf6qvr3dl6ny08i/Makeshift-T-Card-holder.jpg?raw=1" width="300"></a></p>
<h3 id="what-about-the-cards">What about the cards?</h3>
<p>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.</p>
<h4 id="colors">Colors?</h4>
<p>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.</p>
<h4 id="what-to-put-on-the-card">What to put on the card</h4>
<p>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. </p>
<h4>Assumption is the mother of all screw-ups </h4>
<p>One helpful piece of information to add to the card is the time it <em>should</em> 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.</p>
<h4 id="card-sizing-kind-of-a-hack-actually">Card sizing (kind of a hack actually)</h4>
<p>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.<br />
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).</p>
<h3 id="kamishibai-a-little-more-complex">Kamishibai – a little more complex</h3>
<p>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 <a href="https://en.wikipedia.org/wiki/The_Checklist_Manifesto">the checklist manifesto.</a> 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.</p>
<h3 id="the-right-approach">The right approach?</h3>
<p>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.<br />
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.</p>
<p>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.</p>
<p><a href="https://www.dropbox.com/s/so0lhlfst1qs11k/kamishibaiExplanation.jpeg?dl=0"><img alt="A multi-process Kanban board broken down into value-stream Kanban board and kamishibai board" src="https://www.dropbox.com/s/so0lhlfst1qs11k/kamishibaiExplanation.jpeg?raw=1" width="300"></a></p>
<p>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).</p>
<p>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.</p>
<h3 id="try-kamishibai">Try kamishibai</h3>
<p>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.</p>
<p>till next time<br /> <em><a href="http://www.michaelmahlberg.com">Michael Mahlberg</a></em></p>
Michael Mahlberghttp://www.blogger.com/profile/17228297952885873743noreply@blogger.com1tag:blogger.com,1999:blog-20337798.post-14050099641740595502019-12-22T17:47:00.000+01:002019-12-22T17:47:10.705+01:00Don't get hung up on ‘Business Agility’ too much<p>To quote a currently very popular insight:</p>
<blockquote>
<p>“As long as you don’t have your Business Layer under control, it doesn’t matter how agile your teams are.”</p>
</blockquote>
<p>And YES, there is some truth in that. But it can turn out to be a logical fallacy. </p>
<p>And that is where I have my beef with the lure of ‘Business Agility’, because a lot of people think, that it is enough to focus on that level now. Not in my experience. </p>
<p>Having the awareness is –as the mathematicians would probably say– <em><strong>necessary but not sufficient.</strong></em></p>
<p>An organisation is a system of interconnected systems (or <em>services</em> to use the terminology from the Kanban method) and if these underlying systems don’t work then all the ‘business level coordination awareness’ in the world won’t change much about the delivery capability of your organisation. </p>
<p>You can invest as much as you want into power steering (Servolenkung in German) and slip control – as long as your car is sliding sideways on an ice slope with slicks for tyres it actually pays to invest into better tyres before you start fiddling with the higher level elements. </p>
<p>As long as your business analysts don’t know how to quantify a business value, your engineers don’t know how to reliably ship the product, your sales people don’t know about the capabilities of your delivery services (sometimes a.k.a. development teams), or –in short– your teams are still at a low ‘agile’ maturity you won’t be able to steer the business. </p>
<p>The bottom line is: </p>
<blockquote>
<p>As long, as your team level maturity is too low, you can improve the business level as much as you want – it won’t make a difference. </p>
</blockquote>
<p>Therefore:</p>
<blockquote>
<p><em>The maturity of an organization has to be evolved as a whole. The evolution at team-level, business level and strategic level has to go hand in hand</em></p>
</blockquote>
<p>till next time<br />
<em><a href="http://www.michaelmahlberg.com">Michael Mahlberg</a></em></p>
<p>P.S.: But if you focus on Business Agility alone at least some people in the organization will feel good. For about six to twelve release-cycles. Because –in my experience– that’s how long it usually takes the organization to come to this realization. [That can be up to three years btw...]</p>
Michael Mahlberghttp://www.blogger.com/profile/17228297952885873743noreply@blogger.com0tag:blogger.com,1999:blog-20337798.post-49833777609016202952019-12-01T17:24:00.000+01:002019-12-01T17:24:06.532+01:00Let MoSCoW help you with facilitation and workshop design ;-)<h2>Interactivity vs. Schedule</h2>
<p>When designing a workshop –or any session– you facilitate one crucial aspect is timing. But timing gets complicated when you have lots of interactive parts in the session in question. And we know from <a href="https://fromthebackoftheroom.training/a-short-overview-of-training-from-the-back-of-the-room">research about training</a> and oftentimes also from personal experience, that interactive elements are essential to successful sessions, so there is a serious incentive to include interactive stuff. The same holds true for other kinds of meetings as well – from design sessions to board meetings. </p>
<h2>Balancing being on time an interactivity with MoSCoW</h2>
<p>There is an old idea, made popular in the early days of agile by its extensive use in <a href="https://en.wikipedia.org/wiki/Dynamic_systems_development_method">DSDM</a> called
<a href="https://en.wikipedia.org/wiki/MoSCoW_method">MoSCoW</a>. The capital letters in MoSCoW stand for <strong>M</strong>ust <strong>S</strong>hould <strong>C</strong>ould <strong>W</strong>on’t and the «o»s are just there to make it sound nice. Without looking into the original priotization method too deeply, thinking about the design of a session in therm of MoSCoW categories helps a lot in balancing timeliness and interactivity. Especially if you combine the MoSCoW thinking with the concept of <a href="https://agile-aspects.michaelmahlberg.com/2014/08/bigger-and-smaller-pieces-in-flow-think.html">Heijunka</a> or work (load) leveling. </p>
<h2>Designing the session</h2>
<p>In most sessions, especially in teaching, it is not a good idea to have all the musts at the beginning – because of the <a href="https://bowperson.com/wp-content/uploads/2014/11/SixTrumpsArticle220101.pdf">way people learn</a> a schedule should not be a backlog where you put all the important stuff up front and the rest at the end anyway. The approach that I have seen to be usefull to a lot of facilitators, is to make shure that your schedule consists of a well balanced mix of must, should and could elements. What ‘well balanced’ means depends on the circumstances of course. Assuming we’re in a training situation and we know only very little about your audience, we might want to include more ‘could’ elements than we do when we’re working in a well known setting. This is the Heijunka part – heijunka literally means ‘leveling’, but in the context of lean the meaning is extended to something like ‘smart leveling.’</p>
<blockquote>
<p>BTW: In meetings that need to have decisions at the end, one of the must items –come to decisions– <em>needs</em> to be at the end. So it’s a very good idea to have discardable parts in the schedule even if the sessions you’re facilitating is <em>not</em> a training. </p>
</blockquote>
<h2>Applying triage <em>as you go</em></h2>
<p>Now while we run the session we don‘t want to constantly check the clock to see if we’re either too fast or too slow. Quite to the contrary. We do look at the time often, but we use our projected agenda (including the MoSCoW classifications) to adjust as we go. When we’re ahead of the time (e.g. because the audience is faster than expeted) we can transport a bit more information and include the <em>could</em> element that we put in our internal agenda. Should we be slower than planned we cut one of the <em>should</em> elements. By using this approach it is way easier to keep the value for the participants high for the whole session. (As opposed to lumping all the unimportant stuff at the end, so that we also could skip it – as we would do it in a prioritized backlog apporach.] </p>
<p>Just give it a try...</p>
<p>till next time<br />
<em><a href="http://www.michaelmahlberg.com">Michael Mahlberg</a></em></p>
Michael Mahlberghttp://www.blogger.com/profile/17228297952885873743noreply@blogger.com0tag:blogger.com,1999:blog-20337798.post-42957692272730891242019-09-08T17:56:00.000+02:002019-09-08T17:56:00.659+02:00Is that “start with what you do now”-principle from kanban still ‘true’?<p>One of the pillars of the Kanban method is the principle “Start with what you do now.”</p>
<p>Looking at it historically, this was especially related to the fact that there is no need for any additional roles, meetings, or titles when introducing the Kanban method. In the early days that was such a stark contrast to other process improvement approaches that you still can find the <em>foundational principle</em> “Initially, respect current roles, responsibilities & job titles” on some Kanban method websites. Today this message has become part of the “Start with what you do now”-principle (as the second bullet point).</p>
<p>Over the years the body of knowledge in the realm of Kanban has grown and with some of the “newer” ideas there are a number of aspects that <em>seem</em> to contradict this very notion. </p>
<p>One of the more prominent ideas in this respect is the whole landscape of “Discovery Kanban”, “Customer Kanban”, and “Upstream Kanban.” Basically this is the idea to not only manage the delivery of work through a Kanban system, but also manage and organize the discovery of options with a Kanban system. Conceptually this has been described by <a href="https://twitter.com/PatrickSteyaert">Patrick Steyaert</a> and it has been incorporated in the Kanban method as can be found e.g. in the related book <a href="https://leankanban.com/upstream/">Essential Upstream Kanban</a>.</p>
<p>Yet, many companies don’t actually <em>have</em> a managed options discovery process – so where does this leave us with regards to the "start with what you do now"-principle? One possible starting point is <a href="https://www.slideshare.net/agilemanager">David Anderson’s</a> example for <a href="https://www.slideshare.net/agilemanager/kanban-follow-your-own-path-to-agility/36">combining discovery and delivery kanban</a>. This is a little different from the approach Patrick is describing, and most probably not exactly how the items “on the left“ of your delivery Kanban system flow <em>now</em>. (That is of course regardless of whether you call them “ideas“, “options”, “feature requests”, “demands”, or anything else.) But in my experience it is a very feasible way to <em>get to</em> “(finding out and) starting with what you do now.” As in so many cases, even though there might not be any <em>formal</em> discovery process, once you start looking into the details of the existing items and their history you might find that there is an informal process to be uncovered. It <em>might</em> more or less conform to the concepts lined out in the system <a href="https://www.slideshare.net/agilemanager/kanban-follow-your-own-path-to-agility/36">descibed by David J Anderson</a>, or not. Even if it doesn’t, just by having a board conforming to those concepts, trying to fit the (existing or assumed) items on it and <em>facilitating the discussions</em> around it, there is a good chance that you either uncover the real process or already evolve the process to something a little bit more fit for purpose. </p>
<p>Still, you actually started with what you did then – no new roles, no new processes. Not initially at least. Probably some processes <em>evolved</em> from having the discussions about the relative position of items on the board and how to get them there. And that is already the Kanban method at work as <a href="http://agile-aspects.michaelmahlberg.com/2019/08/which-change-management-approach-is.html">a change-management approach</a>. </p>
<p>till next time<br /> <em><a href="http://www.michaelmahlberg.com">Michael Mahlberg</a></em></p>
<p>P.S.:
Thanks to <a href="https://twitter.com/produktwerkCGN">Tim</a> for bringing up this issue about “start with what you do now.” Nice catch.</p>
Michael Mahlberghttp://www.blogger.com/profile/17228297952885873743noreply@blogger.com0tag:blogger.com,1999:blog-20337798.post-81702561796859970262019-08-11T17:31:00.000+02:002019-08-11T17:31:00.347+02:00Which change-management approach is required to implement Kanban?<p>Well, there's the thing: the way I understand it, the Kanban method is not an end in itself – it is quite the other way round. Kanban <em>is</em> the change-management approach.</p>
<p>As lined out in <a href="https://www.amazon.com/Kanban-Successful-Evolutionary-Technology-Business/dp/0984521402" title="David J. Anderson. Kanban: Successful Evolutionary Change for Your Technology Business (Kindle Locations 3145-3146). Blue Hole Press.">the book that defined the method</a> «I [<a href="https://twitter.com/lki_dja">David</a>] subtitled this book, “Successful Evolutionary Change for Your Technology Business.” I did this to underscore the point that <em><strong>the main reason for adopting Kanban is change management. Everything else is secondary.</strong></em>» (emphasis added) </p>
<p>Over time the Kanban Method has evolved, and with the current material there are quite a few additional actionable tools available which hugely extend the original book. But for me, the core is still the same. You use the Kanban method <em><strong>to enable change</strong></em> – simultaneously giving people control over the processes (the process control or service delivery part) and enabling evolutionary change by making formerly intangible things visible and negotiable (the –evolutionary– change management part)</p>
<p>Of course, there is STATIK, the Systems Thinking Approach To Introducing Kanban, but once again, this is not an end in itself. And it only is an approach to <em>introduce</em> the Kanban method. All the organizational change that comes after that is not driven by STATIK, but by the Kanban method itself. </p>
<p>So, I guess what I'm trying to say is "Don't ask what you have to do for the Kanban method, ask what the Kanban method can do for you."</p>
<p>till next time<br /> <em><a href="http://www.michaelmahlberg.com">Michael Mahlberg</a></em></p>
Michael Mahlberghttp://www.blogger.com/profile/17228297952885873743noreply@blogger.com0tag:blogger.com,1999:blog-20337798.post-78944548792862786582019-07-15T16:28:00.003+02:002019-07-15T16:28:56.705+02:00Why are there no product owners in Kanban?<p>Or perhaps the better question would be: Are there no product owners in the Kanban method?</p>
<p>It is actually a question I hear more often lately – especially since I started to publicly rant against the misnomer that “product owner” has become.</p>
<h2>The question doesn’t make too much sense</h2>
<p>As I mentioned earlier it does not make too much sense to directly compare the Kanban method and Scrum <a href="https://agile-aspects.michaelmahlberg.com/2017/02/if-you-talk-about-moving-from-scrum-to.html">because they exist on different levels</a>. Same is true for their lingo.</p>
<h3>The Kanban method neither promotes or prescribes roles</h3>
<p>There is no formal definition of any role. (cf. <a href="https://leankanban.com/guide/">Essential Kanban Condensed</a>, p. 33) The aim of the Kanban method is to help create systems that can evolve, following an agreed upon –and in itself evolving– set of explicit policies. That being said, there are roles that the Kanban community has <em>observed</em> as emerging in many Kanban scenarios, but those are not prescriptive. (And of course, there’s more to the Kanban method than explicit policies – bear with me for the sake of the role argument with regard to the product owner)</p>
<h2>Are there any product owners? Anywhere?</h2>
<p>The first principle I ever heard when I learned about the Kanban Method was “Start with what you are doing now.” I'm personally quite fond of the statement “Accept reality.” </p>
<h3>Accept reality</h3>
<p>However you put it – the role that is described as a product owner in the original scrum literature (imho that would be Schwaber, 1995 or Schwaber, 2003) is very hard to find out in the fields. As a story goes which makes its round in Germany right now, some famous product development guru (if someone could point me to the source I would be happy to quote the original source) asked a room full of conference attendees how many of them were “product owners.” Almost everyone raised a hand. The next question was “Who could end their product tomorrow?” No one lifted a hand. Thus the stated conclusion was “So – we don’t have any product owners in the room.”<br>
This might sound a bit harsh, but it points to a quite valid aspect of working together IMHO: the question of our understanding of that role. </p>
<h3>What is a product owner?</h3>
<p>In today’s reality, there are many people who are called product owners, but who aren’t really product owners in the original sense. That’s not as bad as it sounds. At least many people have a rough idea of what a product owner could be. The trouble is that there are many different interpretations of the role. Unfortunately only very few of them are coherent with the original definition. Given that the process descriptions out there use the term as it is interpreted in their context, problems arise when business analysts, subject matter experts, product managers, requirements engineers and other people working on the conceptual development of products are all collated into the umbrella term “product owner.” If you hold people accountable for ordering work items who are specialized in requirements analysis or if you try to get the conceptual sign-off for a new decision table implementation from someone who’s area of competence is customer management it is highly probable that you will be disappointed. “You” in this case can be anyone – from the CEO to the customer to yourself. I have witnessed huge disaggreements about the competencies of the different product owners (note the plural) that work together with a team. A lot of these arguments vanished when we dropped the name “product owner” and used terms appropriate for the real expectations and competencies. But then the process models had to be adapted to these new names. Which, in itself, is not necessarily a catastrophe, but –more often than not– only the end of an illusion. Those descriptions had to be adapted because they didn’t fit “anymore.“ Actually, they never had, but with the new wording, the discrepancies became visible. And all of a sudden, a model of the real –living– workflow became visible. </p>
<h2>The Kanban method makes these things explicit by default</h2>
<p>Amongst other things the Kanban method encompasses 6 practices –Visualize [work and workflow], Limit work in progress, Manage flow, Make policies explicit, Implement feedback loops and Improve Collaboratively, Evolve Experimentally.<br>
By applying only two of them – “Visualizing” the <em>real</em> workflow and “making [the <em>real</em> ] policies explicit” – you already can find out if there are product owners in your actual workflow. And by applying the other practices and policies you can evolve (step by step) your technology business to an organization that is fitter for purpose than it is today. But that would fill <a href="https://amzn.to/2k2oI6R">a whole book</a>. Or several. :-) </p>
<p>till next time<br />
<em><a href="http://www.michaelmahlberg.com">Michael Mahlberg</a></em> </p>
Michael Mahlberghttp://www.blogger.com/profile/17228297952885873743noreply@blogger.com0tag:blogger.com,1999:blog-20337798.post-73801600579972397982019-05-27T16:31:00.000+02:002019-05-28T07:33:12.714+02:00We need more "Wax on - wax off"<p>(Thanks to <a href="https://twitter.com/agiledivider">Falk</a> for brining up Mr. Miyagi here)</p>
<p>If you have never seen – or heard of – the 80ies movie <a href="https://www.imdb.com/title/tt0087538/?ref_=nv_sr_1?ref_=nv_sr_1">“The Karate Kid“</a> the phrase “Wax on - wax off” probably won't mean much to you. Fair warning: spoilers ahead!</p>
<p>Amongst other things that happen in the movie, the relevant part here is that Daniel learns karate from Mr. Miyagi, the handyman for the family's apartment. Without delving too deep into the story, in the beginning, Daniel is demanding from Mr. Miyagi that he wants to learn kicking and punching, but Mr. Miyagi stalls him for quite a while giving him seemingly unrelated tasks to do in very specific manners. For example, Daniel has to shine a considerable amount of classic cars following a very explicit process, using one hand to apply the wax (wax on) and the other to polish (wax off) in precise circles. After a number of chores Daniel gets unhappy with being Mr. Miyagi's “slave” and Mr. Miyagi demonstrates that all those “chores” actually built capabilities which Daniel didn't have before and all the “techniques” he learned, like “paint the fence”, “sand the floor” or “wax on – wax off” could actually – <em>once they where mastered</em> – be quite powerful and effective tools (e.g. defensive karate techniques and blocks) that Daniel would use throughout his further Karate training and his tournaments.</p>
<p>Side Note: Of course there are clips on youtube depicting the <a href="https://www.youtube.com/watch?v=fULNUr0rvEc">"building the muscle memory"</a> part of the story as well as for the part where <a href="https://www.youtube.com/watch?v=Bg21M2zwG9Q">“the learnings are applied.”</a></p>
<p>How does this relate to agile?</p>
<p>To me, it seems we have a lot of focus on advanced agile topics and managing agile teams (and I‘m not even talking about <a href="https://agile-aspects.michaelmahlberg.com/2019/05/scaling-at-scale-remember-at-scale.html">scaling agile</a>) and less and less on the basics of working in an agile manner. But from my experience, it is paramount to have the basics at your disposal all the time. Even with all the “Agile Mindset” in the world a racing car team (like <a href="https://en.wikipedia.org/wiki/Wikispeed">Wikispeed</a>, who actually apply lean and agile approaches to building race cars) would not have much success if their team members weren’t highly skilled in their respective crafts. You can’t pick a random person from the street and just expect them to be proficient with a <a href="https://en.wikipedia.org/wiki/Torque_wrench">Torque wrench</a> or a <a href="https://en.wikipedia.org/wiki/Gas_metal_arc_welding">Gas metal arc welder</a>.</p>
<p>IMHO honing the basic skills would do many agile initiatives good. Speaking from my personal experience, even if it seems tedious and even if it is not the sexy “punching and kicking” - every now and then it does help a lot to focus more on “wax on – wax off.”</p>
<p>till next time<br />
<em><a href="http://www.michaelmahlberg.com">Michael Mahlberg</a></em></p>Michael Mahlberghttp://www.blogger.com/profile/17228297952885873743noreply@blogger.com0tag:blogger.com,1999:blog-20337798.post-4875019942934854432019-05-05T17:11:00.000+02:002019-05-05T17:11:02.025+02:00Scaling ≠ at scale – Remember: «at scale» means something different than «scaled»!<p>It might be because I'm not a native speaker, but there is something about "scaling agile" or "scaled agile" that really has been bothering me these last couple of years.</p>
<p><a href="https://agile-aspects.michaelmahlberg.com/2011/01/big-scale-agile-enterprise-agile-what.html">As I wrote before</a> in my recollection of events agile was described as something that works well for small teams. <br/>
IMHO at least two of the principles, namely "face-to-face communication" and "architectures, requirements and designs from self-organizion" are extremely hard to do in larger groups – unless you add additional constraints like structures (aka hierarchy) or special roles outside each individual group of people or team (aka specialists).</p>
<p>So what are we talking about, when we talk about Agile at scale? At scale means (according to <a href="https://www.yourdictionary.com/at-scale">YourDictonary.com</a>) to have something that is "at the required size to solve the problem." Scaling on the other hand means <a href="https://en.wikipedia.org/wiki/Scaling">"a linear transformation that enlarges or diminishes objects."</a></p>
<p>What does that mean for scaling agile approaches?</p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://en.wikipedia.org/wiki/Metcalfe%27s_law" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://upload.wikimedia.org/wikipedia/commons/1/1d/Metcalfe-Network-Effect.svg" width="80" height="184" data-original-width="261" data-original-height="600" /></a></div>
<p>Do we really want to scale e.g. the number of people involved in solving one specific problem? Because, actually the communication overhead does not scale linearly – it 'scales' according to <a href="https://en.wikipedia.org/wiki/Metcalfe%27s_law">Metcalfe's law</a> and thus communication quickly becomes inefficient. (With 5 people there are only 10 unique ways of communication, with 12 people the number is already 66)</p>
<p>Therefore: Why do we keep talking about "scaling agile?"</p>
<p>I think we should talk about "appropriate solutions at scale" and strive for them. That might include approaches from the lean and agile communities, some implementation of the Kanban Method to facilitate the change and many other ideas that are appropriate for the actual challenges at hand. When we truly live in a volatile, uncertain, complex and ambiguous world, than maybe the solutions for big and complex organizations can also only evolve over time according to each specific organization.</p>
<p>till next time<br />
<em><a href="http://www.michaelmahlberg.com">Michael Mahlberg</a></em></p>Michael Mahlberghttp://www.blogger.com/profile/17228297952885873743noreply@blogger.com0tag:blogger.com,1999:blog-20337798.post-56028989353395538672019-04-14T17:23:00.000+02:002019-04-14T19:49:32.475+02:00When implementing Kanban, don't underestimate step 8 of STATIK<p>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 <em><strong>S</strong></em>ystems <em><strong>T</strong></em>hinking <em><strong>A</strong></em>pproach <em><strong>T</strong></em>o <em><strong>I</strong></em>ntroducing <em><strong>K</strong></em>anban.</p>
<p>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.</p>
<p>Let's look at STATIK briefly:
The way <a href="https://twitter.com/lki_dja">David Anderson</a> describes it on <a href="https://www.linkedin.com/pulse/statik-systems-thinking-approach-implementing-kanban-david-anderson/">his linked-in post</a> STATIK consists of 9 steps. (There are other descriptions as well, most notably Mike Burrows' version from the Book "Kanban from the inside")</p>
<blockquote><ul>
<li>Step 0: Identify Services <br/>
[For each service]
<ul>
<li>Step 1: Understand what makes the service fit for purpose for the customer</li>
<li>Step 2: Understand sources of dissatisfaction with the current system</li>
<li>Step 3: Analyze demand</li>
<li>Step 4: Analyze capability</li>
<li>Step 5: Model workflow</li>
<li>Step 6: Discover classes of service</li>
<li>Step 7: Design the kanban system</li>
<li>Step 8: Socialize the design and negotiate implementation</li>
</ul>
</li>
</ul>
</blockquote>
<p>(I just quoted the summary, the full description is available in <a href="https://www.linkedin.com/pulse/statik-systems-thinking-approach-implementing-kanban-david-anderson/">David's above mentioned post on LinkedIn</a> )</p>
<h2>Starting with step 1 through 7</h2>
<p>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 <em>method</em> implemented this way. I have seen quite a lot of Kanban <em>systems</em> implemented this way. But that's not quite the same – defining a <em>system</em> that reflects a certain point in time is different from embodying a method that fosters ongoing change.</p>
<h2>Why I think step 8 is the most important one</h2>
<p>Remember – as the <a href="https://amzn.to/2Kq7mNX" title="Kanban: Successful Evolutionary Change for Your Technology Business">titel of the defining book</a> says - it is an approach to change: <em><strong>"Successful Evolutionary Change for Your Technology Business"</strong></em>. 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. <br/>
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.</p>
<p>till next time<br />
<em><a href="http://www.michaelmahlberg.com">Michael Mahlberg</a></em></p>
<p>P.S.: For some inspiration on steps 1 to 7 you might also want to look into<a href="https://twitter.com/az1">Alexei Zheglov's</a> Posts <a href="https://connected-knowledge.com/2015/04/21/introducing-the-statik-canvas/">on the approach</a> and the <a href="https://connected-knowledge.com/2015/04/21/introducing-the-statik-canvas/">Canvas/A3</a>.</p>Michael Mahlberghttp://www.blogger.com/profile/17228297952885873743noreply@blogger.com1