“It’s just a toolbox” – essentials and accidents in scaling agile

There is a load of support out there for helping your large company to strive towards business agility. But perhaps only a part of what you are being offered is essential and the rest is just accidental?


– And what is agile, Phaedrus, and what is not agile – Need we ask anyone to tell us these things? – Robert M. Pirsig

Skateboarding is a curious sport. Like Scrum, it’s quite simple, as well as very difficult.

And like Scrum, a skateboard is by its construct, quite simple. Even the most spread visual metaphor of the concept of the minimum viable product by Henrik Kniberg has a skateboard as the starting point. Even the most expensive longboard set-ups stay under 500$, and your average agile coach can well afford to have several set-ups for different purposes.   

Essential tools

Just like agile transformation, skateboard maintenance – putting the parts together, exchanging them due to wear and tear, or switching to higher quality or otherwise more suitable gear can get quite complicated.

Now, if you have the proper parts and you know what you are doing, you can easily get away with just the following tool:

pig multip with texts.PNG
The essentials in skateboard maintenance


Here, you have 14mm, 10mm and 8mm sockets as well as an Y-shaped tool with three different screwdriver heads. Effectively, that’s all you need for skateboard maintenance.

You could think of the sockets as rolling wave budgeting, cross-functional feature teams, and working tested output for the customer to try out early and often. The different screwdriver heads could be imagined as the product ownerbacklog refinement and retrospectives.

Accidental tools

When you start to improvise with the parts you’re using to put the skateboard together- the bolts and nuts you attach the trucks to the board, have low-quality bearings or wheels, or forego regular cleaning of the bearings, you’ll fairly soon find that there are quite a bit of more tools that you’ll be needing.

I have during the years needed way more than just the single multi-purpose tool in skateboard maintenance. In fact, I’ve needed the contents of an entire toolbox to deal with various problems and sometimes quite surprising scenarios.

Looking back, those problems and surprises have largely been due to the choices I’ve made out of inexperience.

I’m hoping that from the following parable you can glean some insight to your agile-scaling efforts.

Feature teams

By far most of the problems I’ve run into in skateboard maintenance stem from improvising with the hardware – that is, the bolts and the nuts which keep the trucks in place. This, I think, is quite similar to not going through the trouble of forming cross-functional feature teams.

In an ideal scenario, you have cross-functional feature teams capable of releasing into production upon demand. And likewise, in an ideal scenario, you have bolts made of a hard metal alloy which go through the board and the trucks just enough – some 5mm or so – for you to have room to tighten the nuts.

However, unless you’ve prepared carefully by getting just the right parts, chances are that the bolts are way longer. In such a case you can’t use the multi-purpose tool any more. You’ll need a ring spanner – think of a team product owner – to get proper grip of things.

The right-sized bolts and nuts made out of a hard metal alloy from the skateshop will – just like battle-hardened agile coaches from Nitor may cost slightly more than those coaches you would get from a big chain bodyshop who is into offshoring. From those, you’ll also find too soft nuts which may also be of similar inside but different outside diameters.

Ring spanners _ multi hexagon.JPG
Team product owners come in many sizes and shapes

So you’ll probably be needing many team product owners, pardon me, ring spanners, to keep the teams “self-organizing”.

Another challenge is that due to the longer bolts, there is quite a lot of manual fastening work to do. You’ll probably want to get some kind of power tool to help with all the tightening.

Black _ decker.JPG
A release train engineer to help team-to-team coordination

Actually, final tightening of the bolts is meant to be done by hand, because then you’ll then have a better feel of what is ‘tight enough’.

What happens is that while you may avoid the problem of doing all the extra tightening by hand, using a power tool may lead into a bigger problem than it solves.

Now, the hardness of bolts as well as the nuts can differ quite a bit. Your average hardware store parts are quite soft in terms of the metal alloy used. The bolts you’ll get for a seemingly premium price from a skateboard shop – are way more durable.

Using a power tool it’s quite easy to mess up the screw head of the bolt or the nut, even if you have a hard-enough parts at hand. But since you need the power tool in the first place, there is a good chance that you also have a cheap, soft bolt and/or nut in the play.

Your bolt may be tightened up half-way and there’s no way to further tighten it – or, in the best case, you get it tight, but you can’t remove it any more when you wish to change trucks or add risers because you want to switch to larger diameter wheels.

Thus, you choice of bolts – think of team composition – has created some unnecessary dependencies.

And as the bolts can’t release their grip of the skateboard, you’ll need DevOps.

Who you gonna call? Call DevOps!

As a rule of thumb, when you realize that you “need DevOps”, you are already quite deep into the “you should not have ended up here in the first place but you just didn’t realize that knowledge work does not scale like digging a ditch does” territory.

Often you will be be able to squeeze the hacksaw blade in just enough to do the sawing, but you need adjustable product increment clamps – two months, I mean clamps, is OK but three is better – to hold things steady while you slowly and surely grind away the unnecessary dependencies.

A program increment

But sometimes, however, you just can’t fit the hacksaw blade into place. Here, you’ll need system team pliers to hold the the stripped screw head in place while you untighten the nut just enough for DevOps to perform its release work.

The system team

There was one time when I had stripped the bolt heads so badly that I had to give up. Even DevOps could not help me.

That story had a happy ending as I gave the board and its now-eternally-attached trucks away for my friend who for some hipster artistic reason wanted to hang an extremely beaten up -looking longboard wreck on her Kallio apartment wall.

I wonder if you could do the same with front-end code which was abandoned because the back-end functionality that was needed got stuck somewhere in a back-end team’s backlog?

To sum things up, messing up the team composition – I mean the hardware which keeps the trucks in place – is by far the most common problem I’ve had to deal with.

Note, that when dealing with teams that don’t quite fit, people often try to seek for relief from Jira plugins or a requirement level taxonomy.

plugins plus taxonomy.PNG

However, both tend to make things even more complicated.

Rolling wave budgeting

How tight you keep the kingpin – the main bolt in the center of the truck – is key to all direction changes. Myself, I tend keep the trucks as loose as possible – but not looser, for that causes wheel bite – which causes to board to abruptly stop while the rider continues forward.

But eventually, you have to change the nut which governs the looseness of the kingpin. You should replace it with another high-quality and properly fitting nut from a skateboard shop, and endure the premium price.

Of course, you might have similar-looking parts lying around – like your tried and true multi-year solution roadmaps you used to update as part of your yearly budgeting process. For some strange reason, the roadmaps might – just like the nuts lying around in your toolbox, at first still look ok.

Just like that nut you found lying inside your toolbox doesn’t quite fit the main bolt of the truck – or the multi-purpose tool you had. So you get out your solution roadmap and start jamming away like you used to.

Solution roadmap

I lost two trucks trying to fit seemingly ok-looking nuts onto the kingpin. In one case, the nut got stuck halfway in between, and did not get tight enough or come off no matter how I tried. In the other case, I managed to tighten the nut ok, but the soft metal it was made of took some damage in the process, and did not come off when it was time to replace it.

Since then I have resorted for premium kingpin nuts from the skateboard shop, leave the solution roadmap to other purposes, and stick with the 14mm socket of the multi-purpose tool.

Product owner

Great product owners are like high-quality skateboard wheels. They keep everything rolling. Without them, no matter what other parts you have, nothing much happens.

Unfortunately, great product owners do not grow on trees. In your transformation, you’d naturally want to use those people who are already part of the R&D organization – line managers, business analysts, project managers, or application owners and name them team product owners.

However, most of them are usually better as members of the cross-functional teams. What you would need is a single business-oriented product owner, not many “team product owners”.

Unless you find that person – whether from inside or outside of the development organization – who has a grasp of the whole and is able to communicate and mediate with all stakeholders, things just do not roll that well.

The product backlog

The product backlog is like skateboard bearings – your prioritization, and ultimately your entire value delivery depends on it.

Even with great product owners, your backlog, just like the skateboard bearings, is bound to collect a lot of garbage. If you don’t clean it regularly – that’s  5 times more often than you’d think if you ride in a turbulent environment – your prioritization grinds to a halt.

When this happens, the insides of the bearings fall out and the outermost ring gets tightly stuck into the wheel. Essentially, with that ring stuck, there’s no using the wheel – or rather, all the four wheels that belong to the entire set – any more.

You could think of this as the entire team of teams grinding to a halt from the perspective of delivering customer value.

Here, coaching becomes handy. You jam the head coach into wheel and onto the stuck metal ring bit, and then the lean-agile leadership keeps striking it until the impediment clears.

hammer and head of agile
Head coach and lean-agile leadership getting ready to remove an impediment

This can take quite a bit of effort and patience from both the lean-agile leadership and the head coach, but in the end you either clear the blockade, or break the wheel or the head coach. So far, I have always been able to clear the blockade, but not without some complaints from the HR department. Nowadays I usually go outside to perform the needed hammering.

Another thing the head coach can be used for is when you are removing the bearings for their cleanup. After removing the wheel, you jam the head coach inside the wheel, between the bearings, and then twist real hard to get out a set of PI objectives for the business to score.

Of course that’s much harder than having the business to work with the teams on a daily basis and collaborate on a properly-sized set of user stories in full mutual understanding of the business benefits in the first place. But unless you know that, using the head coach to twist out the PI objectives is a plausible way forward.

Kuvahaun tulos haulle removing the bearings using trucks
Business collaborating with development on a daily basis

The moral of the story?

During all my endeavors, I have managed finally to learn to always go to the skateboard store to get the right-sized parts made of the right kind of material, use only high-quality wheels and clean the bearings early and often – especially those I use to skate in the rain.

And instead of dragging a big toolbox around, I can do all my gear changing with a small hand tool that is easy to carry around.

I’m not yet sure about large-scale agile, but sometimes, at least in skateboarding, less can be more.

the toolbox contents.JPG

Valeketteryys, kuokka ja jussi

Mitä teet, kun kohtaat arkkitehtuuri- tai osaamis- tai osastorajojen mukaan muodostuneita tiimejä? No tietysti hajotat ne ja kokoat uudelleen asiakasarvon toimittamisen ympärille. Mutta jos et voi tehdä näin, on tilanteeseen huonompia ja parempia sopeutumistapoja.


A common disease that afflicts management is the impression that “Our problems are different.” They are different, but the principles that will help are universal in nature

Vuonna 2008 olin onnistunut myymään ketterää portfolionhallintaa tarkastelevan tutkimusprojektimme “täysjäsenyyden” noin 70 hengen kasvavaan ohjelmistopalveluja tarjoavaan yritykseen. Tutkimusprojektimme nimissä minun oli tarkoitus kehittää heidän projektisalkun hallintaansa. Oikeasti he olivat lähteneet mukaan siksi, että olimme sopineet, että samalla saadaan avullani ajettua sisään kelvollinen työkalu työtuntien kirjaamiseen.

Siinä samalla kun neuvoin tuntikirjausten tekemistä ja töiden mallintamista Agilefantiin huomasin, että ne organisaation entiteetit, joita he kutsuivat Tiimeiksi olivat itse asiassa osaamisalueittain järjestettyjä porukoita – tai “resurssipuuleja”.

Näistä porukoista sitten vedettiin kasaan projekteihin kulloinkin tarvitut kaverit. Tämä puolestaan johti siihen, että jossakin teknologiassa edistyneimmät, kuten Saara (nimi muutettu), osallistuivat useaan projektiin kerrallaan.

Aloinkin siksi hivuttamaan myös ajatusta siitä, että nämä heidän “tiiminsä” eivät muuten olekaan tiimejä. Mitäs jos pyrittäisiinkin muodostamaan ihan oikeita tiimejä? Lähdettäisiin systemaattisesti levittämään osaamista niillä alueilla, joissa yksittäiset osaajat muodostuvat pullonkaulaksi.

Kyseisen yrityksen johdon mielestä eri tiimien ekspertit ovat kuitenkin niin pitkälle spesialisoituneet omassa osaamisessaan, että tehokkuuden nimissä kannattaa toimia kuten on toimittu ennenkin.

Kokemuksista oppineena päätin koota teille, rakkaat valeketteryytysten suota raivaavat lukijat, kasan valikoituja linkkejä. Näiden avulla pystytte toisaalta levittämään tietoisuutta siitä, miksi komponenttitiimit johtavat monenlaisiin epäoptimaalisiin organisaatiorakenteisiin ja hidastavat läpimenoaikoja, mutta toisaalta myös tietoa siitä, millaisiin kompromisseihin kannattaa suostua, jos komponentti- tai osastokohtaista organisaatiorakennetta ei ainakaan heti pysty purkamaan.

Kuivata suo…

Ketteryyden ja transformaatioiden yhteydessä puhutaan usein“kulttuurista” ja “mindsetista”. Todellisuudessa ketteryyden tärkeimmät – ja haastavimmat – kulmakivet ovat organisaation rakenteissa.

Tärkeimmät näistä rakenteista ovat kokemukseni mukaan poikkifunktionaaliset täysiaikaiset tekijätiimit – tai pikemminkin niiden puute – sekä vuosibudjetoinnin muuttaminen inkrementaaliseksi. Jos nämä saadaan aikaiseksi, loput yksityiskohdat aika pitkälle loksahtavat paikoilleen itsestään.

Tiimien tulisi myös olla verrattain pysyviä, ja niiden tulisi olla osaamiseltaan sellaisia, että ne pystyvät viemään läpi työnsä määrittelystä tuotantoon asti. Tämä ei suinkaan tarkoita, että jokaisen tiimiläisen tulisi osata tehdä kaikkea. Spesialistejakin tarvitaan, mutta heidän työnsä tekee mahdolliseksi se, että tiimissä on moniosaajia.

Ahmad Fahmyn artikkelissa The Rise of the Team on muutama käytännön esimerkki, miten tiimit saadaan muodostettua asiakasarvon ympärille.

…tai hanki kahluusaappaat

Harmillisen usein hyppy täysiaikaisiin tiimeihin tai etenkin osastojaon/komponenttivastuiden purkamiseen tuntuu “liian suurelta muutokselta”. Tämän vuoksi komponenttitiimit ovat useimmissa organisaatioissa vielä arkipäivää. Osa-aikainen tiimi taas on ryhmä, joka periaatteessa sisältää kaiken tarvittavan osaamisen asiakasarvoa lisäävän työn tuottamiseen (esim. featureiden A ja B edistäminen ja tuotantoonvienti), mutta heillä on muitakin merkittäviä tehtäviä. Tällainenkin organisaatiorakenne on pikemminkin sääntö kuin poikkeus.

Useimmat organisaatiot ovat kasvaneet matriisirakenteeseen, ja matriisiorganisaatioiden fundamentaali ominaisuus on maksimoida resurssien käyttöasteKaikella on tietysti puolensa, mutta resurssien käyttöasteen maksimointi on ristiriidassa niiden periaatteiden kanssa, joihin ketteryys perustuu.

Koska komponenttitiimit ja/tai osa-aikaiset tiimit ovat kovin yleisiä, olen aiheeseen liittyvien kirjoitusten ja ajatusten pohjalta koonnut muutaman nyrkkisäännön, joiden puitteissa toimimalla voidaan epäoptimaalisten tiimirakenteiden aiheuttamia haittoja lieventää.

Älä pidennä sprintejä vaan skaalaa seremonioiden kestoja

Ei ole epätavallista, että etenkin alkuvaiheessa esim. Scrumin sisältämien seremonioiden (sprinttisuunnittelu, dailyt, retro, demo)koetaan vievän liikaa aikaa itse tekemiseltä. Tämä johtuu siitä, että malliin kuuluvien toistuvien tapahtumien lisäksi tiimiläisten muihin vastuisiin liittyvät kokous- ym. raportointikäytännöt eivät ole poistuneet mihinkään.

Tällaisessa tilanteessa voi tiimillä olla kiusaus pidentää sprinttejä ja/tai jaksoja, jotta mallin seremoniat toistuisivat harvemmin ja aikaa jäisi enemmän itse tekemiselle. Jaksojen tai sprinttien pidentäminen ei kuitenkaan oikeasti auta, vaan pikemminkin pahentaa tilannetta, koska takaisinkytkentä harvenee.

Keskeinen periaate on pitää sprintit kalenterikestoltaan samanpituisina (tässä tapauksessa 2 viikkoa), mutta skaalata toistuvien tapahtumien ajallisia kestoja lyhyemmiksi vastaamaan tiimin todellista allokaatiota yhteiseen tekemiseen. Esimerkiksi täysiaikaisen tiimin kahden viikon sprinttirytmissä suositus demon, retron ja seuraavan sprintin suunnittelun kestolle on neljä tuntia.

Jos päätät vähentää seremonioita, säilytä ainakin retrospektiivi

Mitä tahansa perutkin valitsemasi mallin (esim. Scrum) seremonioista, älä peru retrospektiivejä.

Retrospektiivit ovat se kaikkein tärkein seremonia ! Jos et usko, lue edellä olevat linkit ja tutkiskele asiaa sydämessäsi.

On myös paljon helpompi kasvattaa ketteryyttä vähän kerrassaan tiimin oman oivaltamisen, toisin sanoen hyvin fasilitoitujen retrospektiivien kautta, kuin pakottaa “teoreettista ideaalitilanteeseen perustuvaa” viitekehystä ulkoa päin.

Varmista, että tiimilläsi on alkuvaiheessa fasilitaattori

Erityisesti alkuvaiheessa seremonioiden skaalaaminen lyhyemmäksi voi olla vaikeaa, koska uuden opettelu vie oman aikansa. Hanki joku, jolla on kokemusta, osallistumaan sprinttisuunnittelujen, dailyjen, retrojen ja demojen vetämiseen.

Varaudu myös henkisesti siihen, että fasilitaattorista huolimatta näihin tapahtumiin tulee alkuvaiheessa kulumaan rutkasti “suositusta enemmän” aikaa.

Sovi tiimille koordinaattori ja tee kalenterivaraukset yhteiselle tekemiselle

Kannattaa sopia tietyistä päivistä ja/tai ajankohdista, jolloin keskitytään yhteiseen tekemiseen.

Mikäli tiimissä on useampi kuin yksi jäsen, tiimin tulisi myös sopia keskuudestaan koordinaattori, jonka vastuulla on hoitaa käytännön järjestelyjä, kuten

  • kalenterivarausten tekeminen tiimin yhteisille tapaamisille (sprintin suunnittelut, demot ja retrot, sekä dailyt)
  • tapaamisten puheenjohtajana toimiminen
  • fasilitaattorin hankkiminen!

Scrum Master -roolihan on hengeltään näihin kaikkiin – mukaan lukien fasilitointiin – enemmän kuin sopiva. Kokemukseni mukaan Scrum Master -termin käyttäminen silloin, kun tekeminen ei ole Scrumia, tuottaa kuitenkin enemmän harmia kuin iloa.

Pysyvien tiimien tapauksessa suositeltavaa on valita koordinaattoriksi joku tiimistä, ei fasilitaattoria tai spesialistia (jotka saattavat vaihtua sprintistä toiseen) tai tuoteomistajaa (jolla on liikaa tekemistä jo valmiiksi).

Tässä tapauksessa kannattanee valita henkilöitä, joiden todennäköisesti voidaan ajatella aina olevan eri tiimeissä.

Älä luovu pitkäikäisten poikkifunktionaalisten tiimien unelmasta

Jos pysyt sitkeänä, eikä sinua siirretä sellaisiin tehtäviin, joista on vaikeampi tökkiä vallitsevia organisaatiorakenteita, käy ennemmin tai myöhemmin niin, että johto vaihtuu sellaiseksi joka ymmärtää näiden asioiden merkityksen ja ryhtyy toimiin. Voi myös käydä niin, että tiimit retrospektiivien kautta oivaltavat itse muodostua järkevämmin. Sitä odotellessa, muista että oppiminen ja vanhasta pois oppiminen vievät oman aikansa. Pidä pää kylmänä ja vahvista uskoasi kuuntelemalla parhaita ketteryydestä kertovia esityksiä YouTubesta.

SAFe with Vanilla Jira Reloaded

So you still want to use Jira in your SAFe-going organization? Here’s another, an even simpler way to do it.

bird flying under blue cloudy sky

– Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius, and a lot of courage to move in the opposite direction
– E.F. Schumacher

Back in May 2018, I posted about the The simplest way to run SAFe with Jira. After that, I’ve at clients as well as in attending other Jira-spouting companies’ breakfast seminars run into more set-ups which attempt the same – some better, some worse, but definitely more complicated.

Now, I don’t here intend to go into the details of why you would want to run SAFe with Jira and the fundamental challenges which lie in that direction – these are quite throughly described in my previous post.

But alas, there is an even simpler way to run SAFe with Jira, which may be too obvious to notice at first.

Confusion in the plugin land

I’ve had the set-up described below in my mind for some time already, but it took something I read this very morning on the ALMWorks’ Structure for Cloud Google discussion group which got me sparked about returning to the topic.

This is what I saw:

[Structure’s] customers split into two camps to deal with the discrepancy of how Jira does things and how SAFe prescribes it.

  1. Some customers adapt the wording in their process to adapt to Jira’s […] They reason that a feature by any other name, is still a feature. […] They also work diligently to make sure everyone knows that instead of Epic -> Feature -> Story, their hierarchy is […].
  2. A more common case is to adapt Jira to [match SAFe’s terminology]. They will link their Epics to Features and have Features link to Stories. They will define a specific issue link that reflects this relationship and will not use Jira’s built-in Jira of Stories under Epics. For example, they will use an issue link called “Implements”, so in their hierarchy, an Epic is implemented by Features, and in turn Features in implemented by Stories.

Now, as you might have guessed, I don’t recommend either of these approaches. There are simpler set-ups.

Another Simplest Way – The SuperVanilla

This set-up – let’s call it “SuperVanilla” is so obvious that was bound to be overlooked. Let’s walk through how to set up in terms of issue types, workflows, boards and progress metrics.

The set-up is such that for each SAFe portfolio, you can create a separate project using the steps below. However, do first consider whether you really have many separate portfolios as defined in SAFe – in all but the very largest of companies, you really don’t.

I also don’t suggest that you’d take this model as the prescription you follow until the end of time. What I definitely am saying is that only start complicating things when you are really, persistently, in pain without doing so.

Also, if you have teams which prefer their own way of keeping track of their Sprint level work, I would not impose Jira on them. What matters is keeping the Features’ progress up to date.

Furthermore, since in this set-up everything is in the same Jira project, if you want to restrict the visibility of certain issues, you can apply issue-level security. But I would not suggest going that way either.

OK, let’s get started!

Issue types

SAFe has a three-level hierarchy of Epics, Features and Stories. Never mind here the special terms they’ve cooked up for  “Epics that can be completed by a single program / a single value stream”.

Jira, too, has a three-level hierachy – at least sort of – Epics, Stories and Sub-tasks.

If we forget about the problems that come from having a fixed-level requirements taxonomy with named levels – most practitioner audiences I’ve spoken to do so as well – we get SAFe’s levels by simply removing the extra issue types and renaming the rest.

The end result should look like this:


I usually recommend to keep Bug as a separate issue type.


Then, let’s look at the workflow configurations. Here, I’ve gone with the simplest solution that could possibly work – the same workflow for all issue types:

FUNNEL for ‘everything that comes up’, BACKLOG for things which are understood well-enough so that we can work on them, and an ANALYSIS stage to separate those.


Program Increments (PI) are modeled using the states THIS TIMEBOX and IN PROGRESS. Those Features which are in a PI which yet have no stories ongoing are in the THIS TIMEBOX stage, while those which have work ongoing are in the IN PROGRESS stage.

Another thing to consider – which I have not added here for the sake of simplicity – is that you will want to have a REJECTED stage to keep FUNNEL clean and to a manageable size.


The simplest solution is of course to use a single Jira Kanban board. Don’t use a Scrum board – Jira’s sprint functionality is very much glued-on-afterwards and thus rather convoluted. Definitely, it will not make things simpler.

And furthermore, with set-up there is no need to use Jira’s sprint functionality it at all.

The first step there is to set up columns that match the workflow. The result will look like this:


The general filter simply looks up all the issues in the project. On top of that, we create three quick filters to discern between Epics, Features, Stories and Bugs. Here are the filters for the three first mentioned, doing the Bug filter is left as an exercise for the reader:


Teams and trains

In addition, since all the teams’ work is in a single project, we need some way to discern and possibly also filter what issues – if any, belong to which team and train.

I discourage using components to denote teams or trains – those are best used to model – surprise – components.

Also, using a single login to denote an entire team like I suggested in my previous post is both forbidden as well as a tad too radical for most organizations.  

While we could configure groups to denote different teams, using labels is the simplest route to take. They can easily be seen on virtually any Jira screen and are quite easy to use.

In the case when there are several teams (or trains) who need to collaborate on a story, applying several labels is easy, and using labels can also be applied when there are multiple trains who work on the same solution. So, now we have the following quick filters:


And the board itself looks like this; just use different filters to look up only those items you are interested in.


Progress metrics

The most obvious metric you might want to have is to follow an Epic’s progress over time. To make that possible, create another quick filter which looks up the Epic’s Features using the following JQL

“Epic Link” = [issue key of the Epic] AND type = Feature

Note, that without the type limitation, the query will also bring up also the Stories under the Feature – which we do not want.

Then, look up the cumulative flow diagram, and apply the quick filter. Since Jira’s cumulative flow diagram counts the issues and does not weigh them with e.g. story points, it’s best to strive for Features of a uniform size. But then again, that’s what you should pursue anyhow.

While you have to a quick filter for each individual Epic whose progress you wish to monitor, the configuration is not a huge effort. You probably don’t have that many Epics simultaneously launching – or if you do, looking up a particular Epic’s progress is not your most pressing problem.

Anyhow, once you’ve created the first one, it’s a simple copy-paste operation in the quick filters where you simply replace the key of the Epic.

Looking up a Feature’s progress is also fairly straightforward – look up the related stories directly from the Feature itself, and discuss with the team(s) involved. Since Features should not span that long, there is probably not a need for explicit progress tracking as a function of time.

But, if you want to, the steps to create a progress metric for Features are exactly the same as for Epics.

As for Sprint burn-ups, pick your team, filter based on label, look up the cumulative flow diagram and there you have it.

Anything else?

So there you have it – possibly the simplest possible way to run SAFe with Plain Vanilla Jira. If you think I have overlooked something important, feel free to drop me a note and I’ll try to accommodate it.

Mr. Framework, tear down this wall

Here’s my shot at comparing the two currently most popular frameworks for large-scale agile, SAFe and LeSS. Looking beneath the surface, how do they differ?

– Agile, Scrum, xP, Kanban, Lean: the same elephant, different points of view
-Ron Jeffries 

Having looked at the R&D scene since 1999, I’ve worked with many organizations which have tried to adopt some form of multi-team agile with planning horizons beyond the next two weeks. I was also, back in 2001, one of the authors of the first framework that attempted to capture elements common to lightweight methods – as they were called before the second and more famous Snowbird meeting.

More recently,  I’ve been stymied how many evangelists who teach scaling agile tend to ignore, or at least disregard, the existence of “the other frameworks”.

When asked to compare, most proponents mostly say that they don’t know much of ”the other ones”. Or, they simply refuse to do an analysis of the similarities and differences of the frameworks as the other ones are “something completely different”.

In 2018, I had the chance to obtain both the SAFe Program Consultant as well as the LeSS Practitioner certificates. After having conducted some ten trainings of Leading SAFe and the SAFe Product Owner/Product Manager courses and putting together a non-framework -based product owner training of my own I’ve started to get an eerie feeling.

SAFe and LeSS actually are quite close to each other. At least in terms of essence, if not in terms of emphasis, presentation, and packaging.

To me it seems the stances are a bit like in the case of Scrum versus Kanban in the 2000’s – a silly thing already then – being brought back to the present. And funnily enough, the discussion of Kanban vs. Scrum is still ongoing, though it’s mostly carried on by tool vendors, PMI folks, and those practitioners whose understanding of both Scrum and Kanban is a bit off.

Perhaps, if there’s a wall between the frameworks, it has risen as a side-effect of the commercial aspects, misunderstandings, and a tad of ethical dissonance?

In any case, the prevailing dichotomy does little to serve the industry. And based on what history teaches us, it is not going to be dismantled any time soon – unless we who are less vested in a particular framework take action.

A comparison of SAFe and LeSS

So, enter my version of the comparison!

Yes, there are other comparisons out there, better, worse, list-like and those which are a nice read but remain on a superficial level. But simply saying for example that “LeSS has no portfolio management” does not quite hit the mark. There are deeper aspects and differences – as well as essential similarities – which deserve attention.

Before delving deeper, let’s first look at the ‘why’ behind both of the frameworks’ existence.

As put forward by Scaled Agile Inc.’s president (2019) Chris James, SAFe’s approach is to collect all “proven good practices and patterns” and from there you can “tailor down according to your needs”.

In turn, according to the co-creator of LeSS Bas Vodde, LeSS attempts to offer “a barely sufficient” methodology and suggests to build up your methodology, as, quoting Barry Boehm,  “tailoring down does not work in practice”.

In the sections below I’ve compared and contrasted some aspects in SAFe and LeSS. I have attempted to focus on the most interesting ones, as a run-through of all the elements in SAFe and reciting that ”LeSS does not contain such a thing but of course you could add it” would hardly be meaningful.

In particular, I’ve discussed:

  • Principles
  • Organization design
  • Team and organization size
  • Adoption steps
  • Cadence
  • Requirement meta-model
  • Content management
  • Cross-team coordination, and
  • Portfolio management

If you’re curious about a particular aspect I have not addressed, feel free to reach out and I’ll try to add, or at least share some comment about it.


SAFe: Take an economic view; Apply systems thinking; Assume variability, preserve options; Build incrementally with fast, integrated learning cycles; Base milestones on objective evaluation of working systems; Visualize and limit WiP, reduce batch sizes and manage queue lengths; Apply cadence, synchronize with cross-domain planning; Unlock the intrinsic motivation of knowledge workers; Decentralize decision-making

LeSS: LeSS is Scrum; Empirical process control; Transparency; More with less; Whole-product focus; Customer-centric; Continuous improvement towards perfection; Systems thinking; Lean thinking; Queuing theory

SAFe’s principles are largely based on Don Reinertsen’s book on product development flow. Still, the principles of both of the frameworks, with the exception of “LeSS is Scrum” and “More with less” seem – at least to me – essentially the same, with SAFe’s version being more verbose.  

The main difference seems to be that two of LeSS’s principles – whole-product focus and customer-centricity – are explicitly concerned with organizing around customer value. SAFe’s principles contain that as well, but it can’t be discerned by just looking at the “headlines”.

Organization design

SAFe: Mapping the value streams and identifying Agile Release Trains

LeSS: Identifying product owners and restructuring the organization into feature teams.

SAFe implies organizing around customer value delivery. However, SAFe remains somewhat implicit about this. For example, there’s no mention of feature teams in the big picture, and one can find material which describes trains organized around subsystems as “architecturally robust”, adding that in such a case “there will be many dependencies and lots of Work-in-Progress”.

Interestingly enough, rather many SAFe adoptions I’ve seen have ’agile release trains’ organized around subsystems and are incapable of releasing to production.

I had a chat about this with a Certified SAFe Program Coach Trainer who at the time was employed at Scaled Agile Inc. Like I had suspected, the idea behind this rather ambivalent stance is to get a foot into the door in order to start helping organizations at the level where they currently are. 

While SAFe’s material on value streams is still at points slightly superficial, these concepts from lean were first presented in the context of software development in books by Mary and Tom Poppendieck and you can read more about them there.

LeSS emphasises the importance of changing the structure of the organization into feature teams and eliminating all outside-of-the-team roles except the product owner. As an example, DevOps is considered to be to be a harmful misnomer, as the “original idea was to eliminate ops”. In fact, Bas Vodde rather refers to LeSS as ‘an organization design framework’ than a ‘scaling framework’. While in large organizations the change in organizational structure can happen gradually, organizations with 50 people or less can and should be flipped in a single go.

As for LeSS adoptions … I have yet to see them. And yes, it is quite easily imagined that a LeSS consultant, after rubbing the total structural changes needed, the abolishment of titles, removal of career paths and dismantling the reward systems in the management’s face, might get shown the door.

LeSS does, however, has a concept which would be useful in improving your typical SAFe adoption: Undone Work and the Undone Department.

Team and organization size

SAFe: Teams are 5-11 people, and an agile release train 5-12 teams + the other needed roles (50-125 people)

LeSS: Teams are 5-9 people, and the dev org 3-8 teams + product owner (16-73 people)

For those development organizations which are larger than those stated above, SAFe employs multiple trains for the same solution. In similar fashion, LeSS employs multiple requirement areas (called “LeSS Huge”). In the large solution case, SAFe’s solution management corresponds to the LeSS product owner, whereas program level product managers match LeSS’s area product owners.

Looking for differences, while the team size in both of the frameworks is based on Scrum, the overall numbers in LeSS are smaller. Likewise, the split into multiple requirement areas and area product owners is recommended in the range where according to SAFe, a single train would still be enough.

Otherwise, the approaches match each other quite closely.

Adoption steps

SAFe: a) Train lean-agile change agents; train executives, managers & leaders b) Identify value streams and ARTs c) Prepare and launch ARTs d) Coach and launch more ARTs e) Extend to the portfolio

LeSS: a) Educate everyone involved in the transformation b) Define the product, define done, have appropriately structured teams c) Only the product owner gives work to the teams; keep project managers away from the teams d) Repeat until entire organization transformed

As you can see, both of the frameworks start from training everyone and both emphasize the importance of training the top management. SAFe talks about value stream identification, whereas this is essentially the same thing as defining the whole product in LeSS. Then, the notion of forming ARTs (SAFe) and restructuring teams (LeSS) are very close to each other, and both start with a part of an organization and repeat until done.

The difference is that while LeSS suggests transforming a part of the organization at a time (end thus, creating implicit portfolio management for that area), SAFe “extends to the portfolio” only after launching all the trains.


SAFe: Synchronized 2 week sprints and 8-12 week program increments

LeSS: Synchronized sprints; does not dictate length (but 2 weeks is often implied). Emphasizes that “the sprint is for the product”, not the organization

In SAFe, teams can also “operate in kanban”, but “adhering to SAFe specific rules” where teams plan, demo and do retros together. This does in practice make it quite similar to operating in sprints.

At least when first starting with LeSS, you can do “release planning” in a very similar fashion to SAFe’s program increments. And what’s to say it should be dropped later on?

To quote my LeSS certification course teacher Ran Nyman: “Sure you can add a construct similar to SAFe’s program increment to your methodology – but only do so if you’re persistently in great pain without it”.

As the goal in both frameworks is to be able to ship the working and tested solution (roughly) every two weeks, their take on cadence is very much the same. At least in theory, for in practice the concept of PI planning tends to drive batch sizes up. Compared with sticking to plain two-week Sprints, that is.

Requirement meta-model

SAFe: Epics (do not fit into a Program Increment), Features (should fit into a program increment but not into a 2-week iteration) and Stories (should fit into a two-week iteration).

LeSS: No explicit requirements meta-model; try to use a flat list, and if you can’t, stop at three levels maximum

The notion of requirement meta-models dates to somewhere around 2005 in the work of a group of Swedish researchers (see publications 57-59). While around 2010 other models were also introduced, SAFe’s three-level Epic-Feature-Story model, based on a white paper from Nokia written by Juha-Markus Aalto, has emerged as the most popular one.

LeSS advises to avoid backlog structures with many levels of splitting and recommends that one should definitely “stop at three levels maximum”. This is because having many nested levels increases complexity, as well as tends to result in diverting from customer-centric requirements.

While SAFe and LeSS differ slightly, I think they both are a bit off here – at least when it comes to tree-like splitting.

I’m inclined to think that most of the challenges in dealing with nested levels of requirements actually have to do with inadequate tooling, which in turn stems from physical boards, index cards, and considering the backlog as a flat list.

My two cents is that if you go for tree-like splitting, you should allow for infinite levels as well as abolish explicit taxonomies. Otherwise, you end up driving up batch size in subtle ways which in turn lead to very tangible problems.

Content management

SAFe: Product manager owns the program backlog and team product owners own the sprint backlogs. In addition, there are program-level PI objectives, summed up from the team PI objectives which are in PI planning scored by the Business

LeSS: Product owner owns the product backlog, the team owns the sprint backlog. Optional Sprint goal, devised by the team and the product owner

I’ve divided the discussion into two sections: backlogs and content ownership and goal setting.

Backlogs and content ownership

Despite SAFe’s distinct portfolio level, the ultimate decision on what goes into the program increments resides with the Product Manager role. This holds true for LeSS’s product owner as well.

Overall, SAFe’s product manager and LeSS’s product owner roles are quite similar. While SAFe explicates further content owner roles such as Business owners and Epic owners, I interpret this as a way of actually making the product owner more specific – and similar to the role as originally defined in Scrum. LeSS leaves such details out and talks about product ownership being a deeply collaborative activity with the stakeholders.

But the real differences come at the sprint level.

SAFe recommends that each team should have a product owner, and that at least most of the sprint level work items (stories) should be connected to parent work items (features). LeSS, in turn, advises against both of these things. The creators of of LeSS consider that having a product owner per team promotes local optimization.

In LeSS, Product and Sprint Backlogs are also intended as separate and independent artifacts. The teams should be able to choose their own way of keeping track of sprint-level work. They should also  be trusted to understand and communicate about their progress without explicitly using a tool to tie sprint content to product backlog items.

Goal setting

In terms of goal setting, aside from the vision, SAFe has PI objectives and iteration goals, whereas LeSS has sprint goals.

The obvious difference here most likely stems from the differing cadences put forward by the frameworks. As a Program Increment contains several sprints by several teams, and each team has a set of their own PI objectives, summarizing those into program level PI objectives is only natural.

The collection of LeSS’s Sprint Goals (one for each team) are essentially the same, but for a shorter time period. Thus, summarizing is not needed.

But a less obvious, and to me a rather interesting aspect here is that SAFe has the construct of PO objectives in the first place. Also, there is a degree formality related to their use (compared to e.g. the rather vague definitions of sprint/iteration goals which have lingered around since the early 2000s).

Team level PI objectives are scored by the business people, and are then used to calculate the PI predictability measure at the end of a program increment.

Let’s take a moment to discuss this. The original intent in the manifesto for agile software development was to have the business and development work together daily. Also, user stories, as originally intended, did contain the expected benefits in terms that the business understands.

Now, in your typical real-life large-scale setting, the business people are hardly participating in development decision-making at all – at least before “the transformation”. They have too much important management stuff to do.

Also the use of stories at the team level has surprisingly often degenerated into something akin to “As the system, I want to have a button so that I can press it to print” silliness.

The PI objectives in SAFe seem to me like a tailor-made mechanism to pull the business into the discussion at least every quarter or so, without having to force them completely out of their comfort zone and join the discussion of these “agile stories” on a bi-weekly – or God forbid – daily basis. Interestingly enough, in the cases where I’ve seen PI objectives used by-the-book, they very much resemble product backlog items as they were originally intended.

Whether having – in addition to the backlog(s) – such a scoring wrapper in the long run is the safest (pun intended) route to take – as opposed to actually pursuing daily collaboration, spreading the knowledge about the proper use of a product backlog, collaborating with user stories and learning to do vertical splitting together with the teams, I’ll leave aside for now.

Having said that, the PI predictability metric is good in the sense that it’s harder to game than for example measuring velocities, function points, or some other silliness.

Cross-team coordination

SAFe: The Release Train Engineer role and Agile Release Train sync meetings

LeSS: The teams are responsible for cross-team coordination; in addition, you can have “town hall meetings”, “problem solving open space meetings”, “scrum of scrums” and whatever you need

According to SAFe, “agile release trains won’t steer themselves on autopilot” and the release train engineer role is there to facilitate cross-team coordination.

LeSS does not have an explicit coordinating role, because its creators considered that having such a role would unnecessarily take away responsibility from the teams.

Portfolio management

SAFe: Explicit strategic themes, portfolio canvas, rolling-wave funding of value streams, budgeting guard rails, a kanban for prioritizing and managing Epics, and the Epic owner role

LeSS: Portfolio management happens via backlog prioritization

Understanding LeSS’s stance on portfolio management would require a bit of explanation, but a piece about this is already out there.

Essentially, LeSS suggests that in the case of a correctly structured organization and a broad enough product definition, portfolio management is de facto reduced to backlog management. In the case of LeSS Huge, ‘portfolio management’ also includes shifting teams from one requirement area to another. And the demand for such shifts comes from…  yes, backlog prioritization.

On the surface, SAFe portfolio management looks quite different from that in LeSS. Despite the added number of elements and artifacts, I find it essentially the same. For example, if value stream funding changes, surely the number of teams working in the trains – or the number of trains – are the variables which change as well.

Having said that, limiting the number of work-in-progress on the portfolio level is the most effective way to improve an organization’s performance – even without changing the structures and practices in the development organization.

To look at this from the perspective of offering an organization an easier path to transform its portfolio management, SAFe does, by describing a ready-made set of artifacts and roles offer better novice-level guidance here. Again, whether such a path is on the long run safer and faster is unknown to me.

What about the other scaling frameworks?

You might be wondering why I haven’t included other scaling frameworks to the comparison? First of all, SAFe and LeSS seem today to be the most popular, as well as best described.

To scratch the surface of the other approaches out there, Ken Schwaber’s Nexus is very close to LeSS with a bit more structure around how to do cross-team coordination. The so-called “Spotify model”, as originally described – I have no clue what Spotify’s doing today – was structure-wise also very close to LeSS.  Likewise, Jeff Sutherland’s Scrum@Scale is quite close to LeSS – but actually has even less structure to it. On the surface it seems to simply recommend that everybody in the company should do Scrum.

Perhaps in the  future I might take a deeper look into Nexus and Scrum@Scale.

The kettle and the pot

I’ll end with quotes from both frameworks’ proponents:

“SAFe is based on the Lean-Agile principles and the agile manifesto. […] It would be great if big companies who build important systems could start from scratch and start with a team of five, ten or fifteen and build it. But often they already have thousands of people in place and SAFe provides a bigger picture of how they could operate with a different mindset and what the principles, the practices and the roles could be.” (Chris James, COO of Scaled Agile Inc. @ Panel on Agile Scaling Frameworks And Their Ecosystem – Boon or Bane at #AgileIndia2017)

“LeSS is true to agile development and the origins of Scrum and is about creating the bare minimum and more ownership for the team. It is about moving away from heavy-weight processes and roles within organizations. Complex organizations are slow, and in LeSS you want to create a simple organization, which can better make the product(s).” (Bas Vodde, co-creator of LeSS, @ The Agile Standup Podcast)

Perhaps one of these resonates with your transformation efforts? Or perhaps not? Remember that you don’t have to – or perhaps even should not “choose” either!

As it happens, both frameworks have strong roots in Finland, from companies such as both of the Nokias, F-Secure, and Ericsson – among others.

And not-so-coincidentally, Nitor’s Transformation Engineers – myself, Maarit Laanti, Rami Sirkiä, Kirsi Mikkonen, Rauno Kosamo, Marko Setälä, Juha Itkonen, Antti Tevanlinna and Kati Laine – just to mention a few – have, since early 2000s, been involved in the work which has since resulted in both SAFe and LeSS. 

So whether you pick one framework, the other, both – or wish to go your own way, we can help you transform your organization.

A fixed-level requirements hierarchy drives batch size up

Have you recognized that having a fixed number of levels for story splitting – such as the “Epic-Feature-Story” model popularized by SAFe – inherently drives batch size up? In this post, I present a short history of story splitting taxonomies in agile and demonstrate why three levels of splitting is not really enough. I also propose a remedy for the problem: allow for tree-like splitting for the highest level items, but go for cell-like splitting whenever “inside” a time-box.

christian-bisbo-johnsen-38240-unsplash.jpg– Avoid a complex requirements meta-model (Larman & Vodde, 2010)

In the later part of 2000s, authors and thought leaders in the field of agile software development started applying agile beyond the context of a single team, and at the same time, proposing requirements meta-models to better structure planning for a longer term than a sprint.

Some would say it all went south from there.

But for the sake of not hiding our head in the sand and pretending tree-like work item splitting isn’t already being practiced in every other company striving to become more agile, let’s suppose it would make sense.

Let’s first recount how the idea came about.

A short history of work item splitting

In the beginning, there was the product backlog. A flat list of what was seen as potentially useful for a team to do, with smaller and better understood items at the top, and bigger, more vague items at the bottom. The product backlog was taken care of by the product owner, refined together with the team, and with the team, the contents of the next sprint were selected.

Tracing back, before the notion of requirement abstraction models in agile software development, there came the notion of levels of planning. Rautiainen et al.  (2002) presented the first attempt at generalizing levels of planning beyond the context of a single agile approach (such as xP or Scrum). However, it wasn’t until 2005 until levels of planning in agile were popularized by Mike Cohn’s planning onion in the book Agile Estimating and Planning.

As an example, the picture below depicts different levels of planning. That particular picture is from 2012 and drawn by yours truly. In it I combined ideas from Smits 2007 and Cohn 2005. Based on a quick googling it has, verbatim, spread to become a popular picture to depict planning levels:


Progressive refinement of work items has of course been part and parcel of agile all along, But planning levels models do add structure to better understand work item splitting. In progressive refinement, as development proceeds, the bigger and still vague work items are split into smaller and smaller – according to the planning horizon in question. Often, large items split into smaller items that have “mixed priority”. Thus, when possible, splitting should proceed to identify just those small bits that add the most value. Then, only the most valuable “bits” should be implemented.

Tree-like vs. cell-like splitting

SAFe, the most popular scaling framework today – as well as many other authors on the topic before SAFe – propose a tree-like splitting model. In tree-like splitting you retain the original work items as well as the trace to the resulting work items.

To contrast that, early agile thought leaders such as the manifesto authors seemed to pay little attention to the notion of tree-like splitting. This is particularly well exemplified by the following excerpt from Mike Cohn’s book Succeeding with Agile (2009, p. 178)

After an epic is split into smaller stories, I recommend that you get rid of the epic. Delete it from the tool you’re using or rip up the index card. You may choose to retain the epic to provide traceability, if that is needed. Or you may choose to retain the epic because it can provide context for the smaller stories created from it. In many cases, the context of the smaller user stories is obvious because the epics should be split in a just-in-time manner.

Like Cohn, Larman and Vodde (2010) also prefer cell-like splitting. They propose that loss of context and ancestor information in cell-like splitting (where you get rid of the parent item) may be a speculative rather than a real problem.

Whatever the case may be, tree-like splitting has, largely because of SAFe, ended up popular enough to warrant a deeper discussion.

Tree-like splitting and work item taxonomies

With tree-like splitting often comes the idea that it could be useful to have a taxonomy – or a meta-model, whichever name you prefer – to refer to the different sizes of work items on the different levels.

The first such taxonomy I’ve come across – and coining of the term requirements abstraction model – was in a research paper by Gorschek et al. in 2005. In the years that followed, many different abstraction models by different authors, among them Dean Leffingwell’s Epic-Feature-Story, were proposed.

While for example Mike Cohn warns of the pitfalls of using “complicated” requirements abstraction models, it is not difficult to accept the idea that at least in some situations, having a taxonomy for discussing the items on the different planning levels would indeed be useful. Also, the little empirical research out there on the matter (for example the work of Gorschek et al. and Lehtola et al.) supports the usefulness of such taxonomies in the context of product development.

How many levels of splitting is enough?

SAFe’s requirement abstraction model has three levels: Epics (which do not fit into a program increment), Features (which should fit into a program increment but take more than a single iteration to complete) and Stories (which should fit into an iteration). While SAFe does not talk about having hierarchy inside these levels – perhaps to keep it simple – it has an additional term, ‘Capability’, to refer to a group of related features.

The authors behind LeSS, Larman and Vodde have recommended two levels at most, and in their 2014 book they were very clear on the matter: if you go for tree-like splitting, “a maximum of three levels is enough”.

But where does this number three come from? Why not two? Or four? Or five? How many levels are enough, and when?

To me it seems that sticking to three levels stems from historical reasons.

In the physical world of walls, post-its and index cards – where it all started – the notion of many levels of work item splitting certainly does not seem feasible. Indeed, a key goal of the manifesto authors – including those who came up with the concept of the product backlog in the first place – was to make a programmer’s life simpler. Perhaps because of that most of them implicitly advocate cell-like splitting.

In the realm of electronic support for work item management, tree-like splitting would certainly be feasible. However, implementing infinite work item hierarchies presents a considerable amount of usability as well as technical challenges. As a result, an overwhelming majority of electronic tools for work item management has not tried to actively divert from the flat list / cell-like splitting approach. Also, in those tools which have some sort of work item hierarchy, the higher levels are, instead of a true hierarchy, either like ‘glued’ on top of the existing model (think of JIRA’s Epics) or simply have a pre-set number of levels (for example AgileCraft).

Does fixed-level splitting drive batch size up?

It’s fair to propose that ‘three levels’ of splitting may be a legacy notion. Thus, the fact of the matter in how many levels of splitting would be enough remains an unexplored territory.

I personally question the need to limit the levels in the breakdown. This is because in my experience, fixed level splitting drives batch size up. And keeping the batch size small is undeniably one of the pillars for rapid feedback – which in turn is the heart of agile.

With fixed-level splitting, what happens is that you easily end up having items that are too big on the higher level(s) (the case where “nothing moves”) and/or items that are too small on the lower level(s) (the case where “business loses sight”). In my experience, you will end up with either scenario – or both of them. And they both effectively undermine the benefits being sought for with tree-like splitting.

Another, a more subtle dynamic which I’ve seen take place is getting ‘attached’ to the tree-like breakdown, and ignoring emerging new and possibly more direct ways to tackle the original problem. In such a case, tree-like splitting effectively drives towards waterfall-like thinking. It may also be that the “original problem” is discovered to be no more relevant, but because of the work breakdown and the attached governance mechanisms there is a tendency to simply keep going at it.

A tale of progressive refinement

But perhaps an example would illustrate this better? Take a look at this white paper: it presents a real-life tale of progressive refinement, which explains the dynamics taking place in detail. 

What just happened, and what to do about it?

Throughout the tale you were able to read of all the details that go on under the hood. While a three-level breakdown would have looked clean and simple, the progress made would remain invisible even though a lot of work both necessary and valuable was being carried out beneath the surface. Still,  with three levels, even the lowest, 3rd level items would in the example seem immobile. 

In the context of product development this dynamic most often manifests so that the gap between abstraction levels gets so wide that those ‘in charge’ of the higher level will lose grasp how the contents of the lower level relate to the overall goals.

In the same way, those in charge of implementing the lower level items may lose sight of “the why” – and missing that, it may affect “the how”, leading to sub-optimal solutions that would have seen avoided had the big picture been in place.

What about metrics?

You may wonder that as the Story tree gets pruned and reshaped, isn’t information about what has been achieved in the previous PIs lost? If you reformulate the story tree in such a manner that the past achievements melt into each other or disappear, what happens to the possibility to draw burn-ups, burndowns, measuring epics’ and features’ lead time, progress and so on?

While most of the tools out there are not very good in supporting the merging and splitting of work items, there are tools which can retain the past to anguishing detail. Just last week in a workshop of a corporation’s RTE and their #1 tool expert, we tried to straighten out the configurations of a 5000 item story tree (done using JIRA Structure) to act so that when new items are created anywhere in the tool, they’d be sucked into the story tree to the correct place when the correct  ‘child-parent’ link is added.

Nearing the end of the time we had at our disposal, it was decided that the best course of action would be to ‘forget the past’ and rebuild a new story tree from scratch taking only the important items which are now or in the very near future to be acted along. There may be sentimental value in all the garbage collected over the years, but I’ve yet to see a case where it would have been needed later. Likewise, any possible metrics drawn from a heap of garbage items hold no value either.

Instead of progress metrics, aim for daily collaboration and value delivery

The key to successful iterative refinement – and indeed, agile – is in rapid feedback, value delivery and the daily collaboration of development and business.

When that works, detailed history, metrics and graphs – as well as the taxonomy for the items on different levels in the story tree ultimately matter very little.

Tree-like splitting needs more than three levels

The example in the white paper, while real, most likely a straw-man compared to the challenges you face in real-life product and service development. After all, while the domain here could be considered equally challenging, we can in theory deliver an end-to-end solution with a single person, and we already know what the end result should look like. We merely don’t know the exact steps to get there or how long it will take.

Just like tree-like item splitting helps you to avoid variability and batch size problems you’d have with a flat list, if you don’t allow for item splitting of arbitrary depth you’ll just run into the same problems a little later.

Allow tree-like splitting for work items outside a time-box

For tree-like splitting you need is easy reformulation of the story tree and as many levels you think you need whenever you need them. Most electronic tools don’t do a good job of supporting you there, so if you are going for an electronic tool, choose carefully.

But you don’t have to go for an electronic tool. If you allow yourself to ‘drop the past’ and focus on what is the plan right now, you can well do that with pen, paper and two walls. But how exactly, that will be the subject of a future post.

But still, in this straw-man example, using more than three levels seems very useful. This is why resorting to a fixed number levels will not be optimal in all but the most trivial cases. In fact is never has been optimal. I believe that is one of the reasons why the original signers of the manifesto for agile software development did not venture into that direction at all but swept it under the rug of ‘the product owner should take care of it’. Their goal was to make the life of developers simpler, and the only way they could see that happening was by fostering Business-Development collaboration on a daily basis.

And that’s what I have seen working as well. If you don’t have that in place, you are dealing with alleviating managerial phantom limb pain. And for that, fake metrics are just as good as the ones you could with a great deal of effort draw from the mess that is the stuff in your tool-of-choice.

Sure, you can in retrospect prune the story tree and force it into only a few levels. But during the process and in the collaboration, you need room to think and discuss. Constraining that discussion with a fixed set of levels and taxonomy of names and roles in charge of the levels will only be a hindrance and level s is hardly useful.

For example, recently I spoke with a development manager heading a 100 person dev organization with the tooling allowing for a three-level breakdown. They had about as many “Epics” as there were developers. Now how’s that for a landscape for the Business to prioritize?

As you probably will have to deal with tree-like splitting, a final word of advice: what I’ve found useful is to allow for tree-like splitting for those items which are not supposed to be completed in a particular time-box. Using SAFe as an example, you’d allow tree-like splitting for Epics, but whenever Features or Stories are split, you go for cell-like splitting. Don’t go making a taxonomy for your Epics-on-top-of-Epics, it is hardly useful in reality. Too big is too big, and more gemba is what you really need.

It also makes little sense to have Features which are supposed to fit in a Program Increment – which have sub-Features which also should fit into the same Program Increment, and the same goes for stories.

Or what do you think? As always, comments and experiences are most welcome.

A kingdom for a decent tool review

Backlog tools are seldom the first-order problem in an organization. And even the best ones can’t solve the first-order problems for you. However, bad tools do get directly in the way of your transformation efforts. That’s why it’s useful to tell one from the other.



– God bless me, but the backlog, is very like a list! (adapted from John Godfrey Saxe)

Having been involved in the development of a backlog tool (that’s Agilefant, nowadays known also as Nektion) since 2004, I’ve been a long time dismayed by the quality of the tool reviews out there.

I know, it’s individuals and interactions over processes and tools but bear with me here. Tools are seldom the first-order problem and even the best tools can’t save you. However, bad tools do get directly in the way of your transformation efforts. That’s why it’s useful to tell one from the other.

Unfortunately, most tool reviews seem to be camouflaged marketinghuge tables or lists consisting of extremely shallow observations of the tools’ capabilities and/or copy-paste from the vendor’s sites. I honestly don’t know why these are done in the first place! Perhaps virtual name-dropping gets you traffic?

Gartner’s magic quadrant reports seem to come the closest, but they, too, suffer from staying at a superficial level.

Another confounding factor is that as SAFe and the like spread further, the vendors’ marketing folk pick up that this is something their product should be able to do as well. And they go and change their website to say that surely their product supports SAFe whether or not that actually is evenclosely the case in reality. Of course similar things tend to happen to everything which has demand – like it has for AgileScrumLean or Kanban.

If there was a clear upside to doing good tool reviews, surely someone would have done so already. And kept at it, because whenever I have found something that might be useful, it’s cut short after some two posts.

So, while producing useful tool reviews will probably prove to be a futile effort in ways I don’t yet foresee, I’m willing to take my chances and try it.

But before going into the actual reviews, in this post I’ll lay some necessary groundwork.


In my experience, the “goodness” of a tool really comes down to three things:

  1. The conceptual strength of the tool
  2. How easy it is to get started
  3. To what degree you can tailor and adapt the tool as you learn more of what you need

I’ll try to elaborate a bit on what I mean by these below.


At the heart of the challenge is the concept of ‘product backlog’ and being able to support how it’s supposed to work. While that might sound simple – “just list the most important items” – taking a closer look at what has been said about it will reveal a vast landscape of needs.

Exploring that further would be a subject of another post itself, but you can get a taste of what I mean by skimming through chapter 2 of “Towards Agile Product and Portfolio Management”.


The ease of getting started is in direct contradiction to the conceptual strength of the tool. This makes things challenging.

I’ve seen cases where people want to start by getting a board-like view for the company’s high-level initiatives (a ‘portfolio kanban’, if you will). But equally crucial is the need to support a single team in its daily work.

While Trello might, with individual boards, cater to both of these needs, its conceptual strength stops short when people start wanting to combine these views into a coherent whole.

From the portfolio perspective this can expand into wanting swim-lanes for ‘strategic themes’, roll-upped progress metrics based on the epics’ breakdown and so on.

Likewise, on the level of the individual team, being able to tie the team-level work items to the big audacious hairy goals of the company is something that may help guide the decisions. As expert work such as programming is essentially problem-solving, and there are many ways to solve problems, an understanding of the big picture helps the team align their solutions to the company goals.

Either way, you have to start somewhere, and if the conceptual strength gets in the way of just jotting things down as you would on post-it notes or a paper notebook, it will cripple the drive.


To be able to combine both the easiness of getting started and the conceptual strength, you need to be able to adapt and grow the tool as you need to, creating new concepts and relationships and renaming the old ones.

This makes it possible for the tooling to grow with you. Otherwise, you have to force your way of working to the model enforced by the tool. This could be a “big hairy proven framework” which incarnates the latest version of the Unified Software Development Processes or Capability Maturity Models of late 1990s – or something else which doesn’t quite fit your reality.

No matter how enlightened, if a big model is forced on the organization too soon, the result will be co-optation: your system projects will be cast as ‘release trains’, your component teams as ‘feature teams’, and your non-customer facing business units as ‘value streams’. In such a scenario, the tooling wille become a strait jacket. In such a case, if you are going through with your transformation, not only will you have to change the organization, but also dismantle the tooling.

An important but fairly simple as well as often overlooked part of tailoring is being able to rename the concepts in the tool.

While choice of names will matter in the long-run (think of for example, ‘projects’ vs #noprojects), in a transformation you want to be able to pick your fights.

Will you, from the get-go, have to convince your C-level managers to talk of Epics, Sagas, Novels and Steam Trains or simply Business Value Proposals and Projects like they’ve used to?


At the time of writing this, I’m considering to take the following tools under a closer scrutiny; in alphabetical order, these are:

  • Agilecraft – the self-claimed leader which to date has not lent itself for easy sign-up and tire-kicking
  • Agilefant – the open source version from 2014 – as a baseline
  • Favro – the offspring of Hansoft from Sweden
  • Google Sheets – not because spreadsheets are that good but because they just might be better than anything else
  • Leankit– I’ve heard good things about this, though nowadays it has been acquired by the more traditional vendor Planview
  • CA Agile Central (formerly known as Rally) – first IPO, then going to CA to die?
  • Taiga – the other open source tool worth mentioning
  • Targetprocess – long-standing original thinking from Belarus
  • VersionOne – besides Rally, the other U.S. based ‘enterprise agile’ vendor; nowadays acquired by CollabNet, which already many years ago swalloved an early player, ScrumWorks

Of the obvious possible choices, I’m skipping JIRA, at least for now. This is because of my customer engagements. I am anyhow in the process of writing a separate thread of posts covering it.

I’m also skipping big software houses’ such as HP’s, IBM’s and Microsoft’s offerings, even though nowadays they, too, claim to support “agile”. I may be wrong in doing so, but for some reasons I can’t quite verbalize, I don’t feel it’s relevant to address them. And you can read how they by some strange mechanism get put up as leaders anyway from any Gartner or Forrester report.

So that’s it for the groundwork, and stay tuned for the first review. I will be backlinking the results to this post, and following Nitor on Twitter you’ll hear about it among the first.

If you have suggestions for tools which I should take a closer look at, or want to affect the order in which I go through the candidates, get in touch!

Scaling agile safe and sound

maatuska revefrsed.png

“Never argue with a fool, onlookers may not be able to tell the difference” – Mark Twain

Back in the day as researchers we pushed Agilefant forward with a versatile-model-first approach. While it lacked bells and whistles such as attachments or detailed user access rights, it had the concepts needed to support large scale agile already in 2007.

Fast forward to today, its latest incarnation is known as Nektion (the proliferation of the A-word tends to repel executives whose organizations might need it the most), and its entire ontology can be configured to fit the convoluted structures of large complex organizations you might run across.

Despite that, or perhaps because of it, I nowadays find myself rather agnostic with respect to whether agile should be scaled using frameworks such as SAFe, LeSS or DAD – or if it should (or even could) be scaled at all.

However, many of the lean/agile thought leaders out there do have clear opinions on the matter. If you’re in the process of “scaling agile” or considering it, my advice is that you should explore these opinions, and consider how the views expressed may or may not apply to your context.

To help you get started, I put together a table of some of the writings around the topic from the better known writers of the field I’ve run into. They are ordered starting from the most recent.

Many of the posts I’ve raised are critical of frameworks for scaling agile. Some are even critical about the notion of scaling agile in the first place. I made this choice because the organizations and people who are in the business of providing frameworks, tools and consultancy for scaling agile already cover the upside quite well.

By exploring the material below, you’ll hopefully become aware of the tensions around the topic – and thus are better able to steer clear of the potential pitfalls in your own transformation efforts.

All of the authors there are surely worth following, and to dig deeper, check out also the commentaries of the posts linked below.

Author Post Quote
Dan North (2018)
In praise of SWARMing Scaling methods are not unhelpful per se, rather that they are neither necessary nor sufficient for successful transformation.”
Duncan Nisbet (2018)
SAFe systems thinking? “The cultural aspects […] are the overriding blocker to systems thinking. Merely talking about it briefly in a 2 day workshop is not going to overcome that challenge.”
Renee Throughton (2018)
Why SAFe is not the scaled approach you need “It encourages massive batching […], old world thinking on estimation […], doesn’t change leadership behaviours [ …], doesn’t force a change in organizational structure”
Marty Cagan (2018)
Revenge of the PMO “If you were an old-school PMO missing your classic portfolio, program and project management, you would probably love it.”
Steve Denning (2017)
What is Agile? The four essential elements “The emphasis […] is more on descaling big complex problems into small pieces than on scaling up the organization to match the complexity of the problems it is dealing with.”
Mike Cottmyer (2015)
Let’s acknowledge SAFe for what it is…and move on “You either create the conditions to do Agile well—Agile as it was defined 14 years ago—or you do something else. That something else is called SAFe.”
Jacob Creech (2015) @JacobCreech SAFe: How I learned to stop worrying and try the Scaled Agile Framework “Suffice to say, I have a reasonable perspective on SAFe in real life, which I prefer to the typical theological debates that arise when SAFe is discussed.”
Ari Tikka & Ran Nyman (2015) @aritikka, @ran_nyman Scaling Agility or Bureaucracy “Good consultation often helps to get results, also with SAFe. However, there is the risk that the systemic conditions are not changing, and the change remains superficial.”
Kristian Haugaard (2015) @haugaards Interview with Dean Leffingwell about SAFe “Many of [reviews of SAFe] have been written by authors who never spoke with anybody who had been involved in a SAFe implementation…”
Ari Tikka & Ran Nyman (2015) @aritikka, @ran_nyman LeSS-SAFe comparison “[Both LESS and SAFe use Nokia as a reference, but] LeSS was and is mostly used at Nokia Networks […] while SAFe was mostly used at Nokia Mobile Phones”
Jeff Sutherland (2015) @jeffsutherland Q&A with Jeff Sutherland on Agile Leadership “scaling frameworks are often used to provide scaffolding for the legacy organization until they can evolve”
Ron Jeffries (2015) @ronjeffries Dependencies, Scrum of Scrums, and SAFe “[…] a huge fraction of the dependencies between teams are artificial. They are due to poor allocation of work from above, and to the existence of unnecessary silos of responsibility.”
Mike Cohn (2015) @mikewcohn You Don’t Need a Complicated Story Hierarchy “When teams are forced to use complicated taxonomies for their stories, they spend time worrying about whether a particular story is an epic, a saga or merely a headline.”
Sami Lilja (2014) @samililja The case against scaling “The problem is NOT that we lack ways to scale agile. The problem is NOT that we fail with agile in large organizations. The problem is that we are large. […] The frameworks take “large scale” as given, and do very little to reduce that.”
Lyssa Adkins (2014)
The Agile Coaches’ Coach Shares Her View on SAFe “Rumi urges us not to become too attached to one “grain”; one teacher or one way, or, in our world, one agile framework or one perspective. I urge the same. Rather, let us look out wider and farther.”
Mike Cohn (2014) @mikewcohn Introducing the LAFABLE Process for Scaling Agile “some of [scaling approaches have been] even tested on real teams before the marketing machinery spun up to promote them”
Ron Jeffries (2014) @ronjeffries SAFe – Good But Not Good Enough “SAFe is good. It’s just not good enough. It provides some benefit, but endangers an organization’s progress toward really high functioning”
Ron Jeffries (2014) @ronjeffries Issues with SAFe “Release Train is an example of a remedial practice presented as an ultimate solution. […] SAFe does not push hard to eliminate the problem: it just gives a way to accommodate it.”
Peter Saddington (2014) @agilescout The Scaled Agile Framework (SAFe) – A Review “thoughtful and well-intentioned [but] takes it a bit too far and defines […] almost too much”
Charles Bradley (2014) @ScrumCrazy Is SAFe(tm) Bad? Is it unsafe? Is it Agile? Are there alternatives? “To date, no Agile Manifesto author has endorsed it. That should tell you something right there.”
David J. Anderson (2013) @f4p_dja Kanban – the anti-SAFe for almost a decade already “in 2003 I decided to focus on […] reducing or eliminating resistance to change. A process-centric focus wasn’t working without a lot of money, positional power and fear to motivate individuals to fall into line.”
Amr Elssamadisy (2013) @samadisy Is it safe? “The question is not whether SAFe should be used as the strategic basis for large Agile adoptions. The question is this: What will make those adoptions most successful?”
Ken Schwaber (2013) @kschwaber unSAFe at any speed “The boys from RUP are back, […] partnering with tool vendors. […] Consultants are available to customize [SAFe] for you, just like RUP”
Neil Killick (2012) @neil_killick The Horror Of The Scaled Agile Framework …” a horrible, money-making bastardisation […] of Scrum, Agile and Waterfall…”

P.S. Curiously enough, I was not able to find posts of sufficient depth, quality or otherwise of interest (subjectively, of course) from 2016. But surely there are some lying around! Can you point me to any?