My Company – Nitor – Empowered the Nerds

Nitor has a great culture where all employees take initiative way beyond normal expectation. Some volunteer to plan new wonderful office space. One is a superb party planner. People take initiative, and they swarm around ideas and needs. It just happens without poking or forcing.

We’re now 10 years old and we total more than 100 people. We’ve only a few designated roles. There’s two companies in the group and two CEOs, who are the bosses of everyone. The people ops keep the office and money running. We’ve two guys focusing on hiring. And we have two part time senior party architects.

The company was founded by 6 founders who are still around – doing stuff. You probably might not notice who they are before you are told or you get curious. And that’s all there is.

There are DevDays, clubs, and all kinds of stuff happening all the time. So where does all stem from? I’ve come to conclude there’s two factors.

Firstly: there’s no management to give orders to people. The only direct order I’ve heard is to “clean up” the office a bit better. Beyond that, there’s just no orders. Zero.

Secondly: We make things visible, available, and simple. We give thanks to those who contribute on the company level. Sometimes it feels weird how much kudos there’s flying around. Even things that might feel ever so small get noticed. But the thank-you is what is keeping the people moving.

100+ people, no orders, and thanks. That’s one way to empower the smartest people you can hire. We have proven that.

Advertisements

Weighted Shortest Job First (WSJF) with Jira

WSJF? Read this short intro. How to do this with Jira, read on.

It took me 1.5 hours to get this working on a fresh Jira Cloud evaluation version. On-premise Jira has a different set of plugins, so a slightly different path is needed. It however is quite simple to get this running – provided you can bribe your Jira admin to install a new plugin ūüôā

This is how it works

Screen Shot 2017-06-20 at 11.58.45

In the listing

Screen Shot 2017-06-20 at 12.03.33

This all was done with the¬†Abacus plugin that allows you to do math based on values “fields”. All of the above is automatically calculated by the Abacus plugin. Any time you change any of the WSJF components, then the calculation is redone automatically.

The summing of Business Value, Risk Reduction/Opportunity Enablement and Time Criticality was the first calculated as the “Calculated total value” column. The WSJF result had also division by job size/duration included.

Pricing of the plugin was IMO bearable. If you need similar with on-premise Jira, then look at JIRA Misc Custom Fields.

So that’s short and sweet, hope this gets you started.

Then I spent a bit more time to visualise this. As usual, to get something you need in Jira, a plugin was again needed. This time it was the easyBI plugin, and that gave me a nice bubble chart of how the items relate to value vs size.

Screen Shot 2017-06-20 at 15.37.29

 

Goal-setting fallacy: more gets more done

Goal-setting is a two-edged sword. If you don’t say where you want to go, you’ll never get the troops moving¬†that way. The other way to say this¬†is that: if you don’t ask, you don’t get. This leads¬†leaders thinking¬†to set goals is a very suitable way “to get there”.

Any large organisation has multiple goals. Maybe that’s just how life is, but I’ve never seen a bigger organisation that has a single, only goal. At least in the development sense, and not the mission/vision sense.

Suppose you are a leader, and you add a new goal. The chances are that you have some weight and something starts happening toward attaining that goal. Some people work on it and there’s progress.

Therefore the act of adding the goal makes total sense. It truly does. Yesterday there was no progress, now there is.

Add one more goal. And the next.

And BAM: the WIP goes up and productivity goes down.

Only solution therefore is: finish, finish, finish. Bite the lip: don’t add goals.

 

Post-scriptum: I came to realise why “focus” works in large companies. I also now better understand why ruthless project managers are golden in high-WIP environments. They will mercilessly remove other non-relevant goals on people – for productivity.

A simple #noestimates priority board

Last year I¬†was managing a small team that was managing software delivery. We were doing small-scale software development. It was nothing fancy but coding, stories, and priorities were needed anyhow. I had decided that we’d do it in the spirit of #noestimates. I needed a way to structure the stories.

I ended up with a board like this. Let me explain how it works. noestimates

First of all, it is based on the notion that cheap and valuable is great. That’s of course a no-brainer.¬†You’ll have to figure out yourself what is valuable, but I’m sure you can hack it.

Second, the cheapness is the inverse of how much time you guess you’ll spend there. However, here’s the #noestimates twist to avoid excessive estimation.

All stories¬†on the board are forced-ranked on the two axis: value and cost. You’ll all the time rank the stories¬†against each other. That is: story¬†A is more valuable than story¬†B. And the same on the cost side. That’s how you end up with a two-axis forced rank. The green dots would be your stories.

Once you start doing that, you’ll quickly realize that it is quite doable. For instance a simple bubble sort will put the stories¬†where they “belong”.

The top right corner is “magic” (the green area).noestimates2 That’s what you want to do next. It is sorted¬†to be your best options. You can quickly trash anything on the bottom-left (the red area), and anybody can see why you did that.

Then we have two quadrants which are not as obvious. The left-top (cheap, not that valuable; yellow area) gets also rather quickly trashed as you see that there’s so much better stuff on the right side. Again, people are quick to agree on that. If there’s no agreement, maybe you missed some point in the value-sorting. Revisit the forced rank on value of that story.

The right-bottom (again green) is the “very valuable, very hard” corner. You’ll want to achieve them, but you either don’t know how to do it yet or you know it is going to be costly. For the latter category, try splitting the prime value out with different cost. These stories¬†should bubble upwards. For the dilemmas, spike them. Maybe the cost isn’t as bad as you thought. For those stories¬†that don’t seem to yield any options with less cost, you’ll end up keeping there as reminders of the great ideas.

The #noestimates development engine is all the time fed with the smallest possible stories. I personally noticed also that the selection becomes biased towards making the small stories¬†with demonstrable benefit. Maybe it is my personal preference on that, but I think it could be even universal. It is easier to bet on a item that has low cost and some benefit, rather than a larger more undefined item with possibly more benefit. Those you want done for sure, but you’ll split them first so well that also the cost side is in control.

So, you’ll end up:

  1. Throwing out all fluffy and non-valuable stories from your board quickly
  2. See visually where to focus on the splitting work (likely the right hand side, just below the magic corner)
  3. Making the most value out of your efforts
  4. Doing it without the need of formal estimation as all you need to know is the rough relative size of the effort

Okay, one will argue that there is estimation going on here. Yes there is. However, that’s going on pretty much only in the top-right corner. And there as well to the extent that which of these stories¬†is smaller. It doesn’t really matter if the rank on cost (or even value) is precisely right outside of the magic corner. Those items are not getting to development without splitting and re-evaluation. The ranking (i.e. cost estimation)¬†rather simple for stories¬†that take a few days to complete. And it doesn’t really need to be accurate again as you’ll end up doing all the stories¬†on top-right corner sooner or later.

Scaling and Tyranny

I’ve lately wondered plenty on the essence of scale in companies and agile development. I can’t escape that most of our current approaches are about tyranny of the few. The tyrannies of the ones in “charge”.

The tyranny comes forth firstly that¬†you’ll have to solve problems that other people defined as “priority items”. The product owner or the customer proxy decided that it should be done. All in all, all that is “given” is a sign of a tyranny of sorts. The larger the environment, the more there are things given.

Consider the following by Drucker. I think it holds the answer.

Management as the Alternative to Tyranny

The alternative to autonomous institutions that function and perform is not freedom.  It is totalitarian tyranny.
If the institutions of our pluralist society of institutions do not perform in responsible autonomy, we will not have individualism and a society in which there is a chance for people to fulfill themselves.  We will, instead, impose on ourselves complete regimentation in which no one will be allowed autonomy.  We will have Stalinism rather than participatory democracy, let alone the joyful spontaneity of doing one’s own thing.  Tyranny is the only alternative to strong, performing autonomous institutions.
Tyranny substitutes one absolute boss for the pluralism of competing institutions.  It substitutes terror for responsibility.  It does indeed do away with the institutions, but only by submerging all of them in the one all embracing bureaucracy of the apparat.  It does produce goods and services, though only fitfully, wastefully, at a low level, and at an enormous cost in suffering, humiliation, and frustration.  To make our institutions perform responsibly, autonomously, and on a high level of achievement is thus the only safeguard of freedom and dignity in the pluralist society of institutions.  Performing responsible management is the alternative to tyranny and our only protection against it.

The institutions are the communities, not line management or product management. They are the places where the individual can affect the future – communities like the “UX community in your company” or the “test automation community in our department”.

I can’t formalize to a full thought yet, but it must be that we must strive for pluralism at work. It is the management’s responsibility to enable the pluralism, and to support it. It means relinquishing a part of one’s control at the same time.

I’ve seen it work. I’ve never seen the full of it. The more I look at it, it is the better alternative to the scaling.

The SAFe System Team Is an Anti-Pattern

I’ve watched by a few Safe-like large-scale agile endeavors. I’ve personally been “in the system team” for a period of time. I’ve never seen it work optimally. The idea is logical, but it just doesn’t seem to work. Let me tell you why. In case you don’t know what I’m referring to visit the official description

The root of the problem seems to be the classical system pattern of the Tragedy of the Commons.

The tragedy of the commons is an economic theory by Garrett Hardin, which states that individuals acting independently and rationally according to each’s self-interest behave contrary to the best interests of the whole group by depleting some common resource.

The tragedy of the commons manifests in SAFe and any multi-team endeavor in the common resources, as in any system. A long while back I tweeted the following:

  1. #tragedyofthecommons in #multiteamagile: Poor system-level test automation
  2. #tragedyofthecommons in #multiteamagile: shitty build systems
  3. #tragedyofthecommons in #multiteamagile: Who gets the short stick and fixes the cross-component bugs?
  4. #tragedyofthecommons in #multiteamagile: Reaching the necessary level of quality, not just something “put together”
  5. #tragedyofthecommons in #multiteamagile: Who handles the coordination across the teams?

First of all, it is a total competence-whammy in any serious program. To able to lead, direct, and maybe even to “have control”, one needs to have skills on all the domains of the program. There’s most of the time databases, connectivity, user interfaces, architectures, integrations, testing, and releasing to worry about.

It quite quickly becomes established that any problem, which does not belong “inside one team”, is a system problem. The system team gets invoked to fix it. And once they fix it once, they become often responsible for it permanently. Unfortunately, programs are ripe with system-level problems so there’s always plenty to do.

Unfortunately in systems, interventions from outside often lead to diminished capacity for the system to fix the problems by itself. That is teams become reliant on external help, facilitation, and management.

The sustainable solutions to #tragedyofthecommons involve local participation and participatory decision-making. Let me touch upon that more a bit later.

The system team is like the reserves in the army, usable only very sparingly. And they are never the sustained fix.

And still for future writing: The system team is often deployed to fix messes in the system. These are pretty much caused by actions of a few teams. Have a look at the video on “spills and how to cope with them”.

Big Movers and Strategic Bias

Some big bosses get to change the company, others are stuck with status quo. The more I watch, the more I’m seeing how the big movers blatantly have 2 bias. They are the Planning Fallacy¬†and¬†the Optimism Bias.

So, you are at your twice-a-year strategic planning event. “How do we become great and have wonderful results?”, “We really need to do something big this time”, and “I want us to be bold”. Great pep talk.

There’s a clear purpose to the process: we need to choose X strategic projects/changes/initiatives. At the same time, somebody reminds that the budget will not grow, at least much. It is a game of selection. Which criteria will you use? Most bang for the buck, most output¬†for the least investment. ¬†The strategic bias arises when the respondent provides a biased answer in order to influence a particular outcome. The Optimism bias causes us to overestimate our achievement. The Planning Fallacy causes us to underestimate the hardship of getting there. Funnily enough: the one with most bias is most likely to gain.¬†The biggest exaggeration¬†occupies the focal ground in selection.

“The biggest exaggeration¬†occupies the focal ground in strategy work.” Luckily not always…