On one of the projects I’m working on right now, we’re building a front-end with a heavy usage of React components. We’re doing our testing with Jest, which is a wrapper on Jasmine.

Now, as mindful programmers, we like to write nice clean code. A linter isn’t the complete answer to writing clean code but it does help a lot. It can also help to trap simple errors, particularly if you don’t have deep experience in the framework ¯\_(ツ)_/¯.

Sweet, let’s add a linter then! With a bit of investigation, I’ve found that ESLint has the right plugins for React and JSX as well as some other tools that we’re using. I’m using Grunt for our build pipeline. There’s a Grunt plugin for ESLint, so let’s add that to our package.json by using npm install:

1

$ npm install grunt-eslint --save-dev

Then in our Gruntfile, we add the ESLint task:

1
2
3
4
5
6
7
8
9
10
11
12

module.exports = function (grunt) {
  grunt.initConfig({
    eslint: {
      target: [
        'Gruntfile.js',
        'app/*.js',
        '__tests__/**/*.js'
      ]
    }
  });
  grunt.registerTask('lint', ['eslint']);
};

Whilst there is a command-line option for ESLint to initialize some configuration (--init), I like keeping specific configuration out in a separate file. ESLint will automatically search for a configuration file if you don’t specific options in your grunt configuration (you can optionally specific a different filename for the config file but the default is .eslintrc). Let’s add an .eslintrc to our app. The .eslintrc file can be YAML or JSON but I found the YAML version more readable.

1
2
3
4
5

---
  extends: "eslint:recommended"
  env:
    browser: true
    node: true

The extends call implements the recommended rules and gets us up and linting.

Great! Now we can run grunt lint and we’ll get the STDOUT output of our linting. If you’re writing React code though, you’ll see a whole bunch of errors about React and the HTML inside the JSX blocks (or files if you’ve separated your JSX out).

We’ll need to add the React plugin to ESLint (it’s plugins all the way down):

1

$ npm install eslint-plugin-jasmine --save-dev

Now for our .eslintrc we can add the react-specific rules, as well as let ESLint to expect that it’s operating in a React-Jest-Jasmine environment. We also set some ECMA features because we’re using JSX.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

---
  extends: "eslint:recommended"
  rules:
    react/display-name: 1
    react/jsx-boolean-value: 1
    react/jsx-curly-spacing: 1
    react/jsx-max-props-per-line: 1
    react/jsx-no-duplicate-props: 1
    react/jsx-no-undef: 1
    react/jsx-quotes: 1
    react/jsx-sort-prop-types: 1
    react/jsx-sort-props: 1
    react/jsx-uses-react: 1
    react/jsx-uses-vars: 1
    react/no-danger: 1
    react/no-did-mount-set-state: 1
    react/no-did-update-set-state: 1
    react/no-multi-comp: 1
    react/no-unknown-property: 1
    react/prop-types: 1
    react/react-in-jsx-scope: 1
    react/require-extension: 1
    react/self-closing-comp: 1
    react/sort-comp: 1
    react/wrap-multilines: 1
  env:
    browser: true
    node: true
    jasmine: true
    jest: true
  ecmaFeatures:
    jsx: true
  plugins:
    - "react"

Now, you might still have some errors thrown when you grunt lint if you’re using Browserify or one of the other require helpers like Webpack or requirejs. We can get around this by letting ESLint know that some things are global. We’re also using React-Router, so we should let ESLint know about that as well.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

---
  extends: "eslint:recommended"
  rules:
    react/display-name: 1
    react/jsx-boolean-value: 1
    react/jsx-curly-spacing: 1
    react/jsx-max-props-per-line: 1
    react/jsx-no-duplicate-props: 1
    react/jsx-no-undef: 1
    react/jsx-quotes: 1
    react/jsx-sort-prop-types: 1
    react/jsx-sort-props: 1
    react/jsx-uses-react: 1
    react/jsx-uses-vars: 1
    react/no-danger: 1
    react/no-did-mount-set-state: 1
    react/no-did-update-set-state: 1
    react/no-multi-comp: 1
    react/no-unknown-property: 1
    react/prop-types: 1
    react/react-in-jsx-scope: 1
    react/require-extension: 1
    react/self-closing-comp: 1
    react/sort-comp: 1
    react/wrap-multilines: 1
  env:
    browser: true
    node: true
    jasmine: true
    jest: true
  ecmaFeatures:
    jsx: true
  globals:
    React: true
    TestUtils: true
    routerHelper: true
  plugins:
    - "react"

I’m also using the BDD and Jasmine plugins for ESLint to improve some of the wording and operation of our test suite. There’s no shortage of ESLint plugins for you to add, which is the beauty of the plugin architecture of ESLint.

If you’re having trouble resolving your linting errors, a great resource is JSLint Error Explanations. Despite the name, JSLint Error Explanations actually explains ESLint errors as well with live examples that you can play around with to see how to fix the error.

Happy linting!

Headway is a measurement of the distance and time between vehicles. For the railway industry, it’s a way of measuring the time it takes a train to come to a complete stop. Too little headway? That means a train could hit another train because it can’t stop in time. Too much headway? Then your train service is slow and choked with angry customers.

For software development, we try to measure the time it takes to finish something. Depending on your metrics, this could be the time to deploy some new code, or the time it takes to launch a new feature, or the time it takes to finish a project.

If we continue using our train analogy, then it’s interesting to note that most of the railways around the world are trying to move from a timetable based schedule to headway based structures. Similarly, modern software teams have moved away from waterfall delivery methods with rigid schedules to more flexible delivery methods, incorporating lean thinking and other software development patterns to allow them to do things faster.

This is all great, right?

Actually, the move from scheduled to headway structuring in the railway community often uncovers higher levels of complexity. Rather than being able to dictate where trains are, based on a rigid schedule planned ahed of time, headway based travel means constant adjustments based on availability of trains, availability of staff, customer flows, maintenance needs, emergencies and a whole other raft of factors. If an organization isn’t ready to handle this level of complexity, or they’ve always assumed that another part of the organization was dealing with it, then the complexity hit can be quite high.

And as railways deal with this ever growing level of complexity, customer satisfaction can take a hit. Why? Often, as railways get caught up in internal factors rather than monitoring customer flows thand journeys, they lose sight of what actually makes customers happy with their commute.

Decreasing headway and being able to run more trains to a station doesn’t mean you’ve solved customer satisfaction, or increased the chance that a member of the public is able to use public transport for their journey. You need to spend time understanding how people use public transport and seeing what they value. They might be willing to trade off a newer train for a faster service. Or maybe an express train can get people there faster. Or maybe a whole number of people have switched train lines, and we need to read to a change in traffic. We need to be able to react to emergent patterns guided by a clearer understanding of what value our service delivers.

In software delivery, it’s easy to lose sight of why a team exists, as a company grows or a project drags on. The team exists not to do more things in a week (increasing headway, or our velocity), blindly chugging through a backlog of work, but to ensure they are building a product that their users truly value.

Great teams do things fast, but they don’t start as fast teams. They work out what a great service looks like, then they get good at making things faster. First you have to lay the tracks, then work out what trains people catch, and only then start getting fast. Don’t just watch the velocity number that Scrum tells you to. It’s a useless value if people don’t want your service.

Here’s a thought experiment for Tuesday:

No-one actually cares what your code looks like or how clean it is.

Now this might be a somewhat controversial viewpoint for me to take, given my background and experience.

But hear me out. After all, this is just a thought experiment.

As QAs, our primary focus is actually ensuring that a product meets the needs of our users [1]. Now we might often get pulled into manually testing an app, or building test frameworks, or helping improve code quality, but the very best tested application that doesn’t meet the needs of our users is a failure.

So if you spend days/weeks/months improving your code quality, or rewriting your app’s backend, or implementing microservices, or refactoring a whole bunch of functions, all without creating something that improves the lives of your users, then what’s the point? You’ve just wasted a whole bunch of time (and probably had a lot of arguments on Hacker News).

A big frustration for me is watching companies and teams of all sizes spend a lot of time talking about how they’ll implement a bunch of features, or how they’re going to do a big rewrite, or implement some new framework, without defining why they’re doing it. 99% of the time, it’s because a) they got told to build a feature by someone else or b) it’s a purely selfish exercise to scratch an itch or reduce some pain. But it’s essentially a waste of salary.

In terms of the most important things you can do:

1. Build a product that let’s your users do a job they want to do
2. Build a product that removes steps in the process of the job that your user wants to do
3. Design a beautiful/engaging product
4. Make the product scalable
5. Write clean code and infrastructure that helps you with 1-4.
6. …
7. …
8. Implement hot framework x.
9. Do a rewrite in hot language y.

But if you aren’t constantly working on at least #1 and #2, you’re dead, and everything else is pointless.

If you want to spend your time learning and building something useful, the best framework that you could implement is one that lets you get out of the building!

Why do you get out of the office? To learn what your users actually need.

So stop asking your QA to write code, or automation, or do manual tests. Get them out of the office and working out what you could be building!

[1] A lot of people would disagree with this viewpoint. Some QAs think their job is about finding bugs or breaking things. Other engineers might think that we’re just there to write and execute manual tests, or write automation frameworks. But all of this is a means to the primary job of the QA: ensuring that a user can complete the job that they want to do, no matter what context they’re in or device they use.

I’ve recently switched to a project where the temporary product we’re building is built in Java 7 using Maven as a build system. As a productive developer and tester, it’s great to have a continually running set of tests as well as compilation to make sure things are working. It’s particularly awesome for TDD-flow and gets you thinking at a higher level [1].

On previous nodejs projects, I had grown accustomed to using grunt watch to run a set of commands (usually, build then unit test then a small smoke test of contract tests). When I looked into Maven, there didn’t seem to be a great plugin for auto-running commands.

I came across this Stack Overflow thread which pointed me to a number of options, including shell scripts, nodedemon and entr. Googling also turned up filewatcher.

I’ve been trying out entr or Event Notify Test Runner to use it’s full name and really like it as part of a continuous testing workflow. To quote from the entr site:

The Event Notify Test Runner is a general-purpose Unix utility intended to make rapid feedback and automated testing natural and completely ordinary.

That sounds like my kind of tool. Let’s give it a go!

To install entr, you can use Homebrew:

brew install entr

You can also download it from the entr homepage and install it manually.

Once installed, you can trigger entr file watching for a certain set of files using a pipe command:

find ~/some_directory | entr some_command

The find command lists all the files in the some_directory and then entr will run some_command if any of the files you listed change.

For instance, in our Java app’s directory I can run:

find src/ | entr mvn clean install

which runs mvn clean install if anything in our source code directory changes, saving me from having to trigger it manually. After starting it, you’ll really quickly get used to having your tests running constantly providing fast feedback to you. As a side benefit, you’ll begin to quickly feel the pain of a slow-running test suite and you’ll work to fix that!

There’s a lot of useful options available in entr, such as the -c flag to clear the screen before a run. There’s also an example on the entr page for tracking if there are new folders or files added (that’s because it’s triggered off the list that you piped in). You can also do crazy stuff with tmux to control other applications in other tmux panes.

In all, entr is a small, useful utility that makes your programming life much easier.

[1] Bret Victor is a big proponent of the argument that the traditional way that we program of writing code, hitting a compile button and then seeing the output is old-fashioned. This isn’t anywhere close to that (you should see Apple’s Playgrounds for a version of that idea) but it at least gets me away from using IntelliJ’s bastardised tools or having to run command line actions.

I’ve been around too long and learned from experience that technology has to prove itself. It should make us better. It should solve problems. And, we should consider these things before allowing any new tool into our daily lives. We should ask ourselves if it’s for us.

When we ask our users to adopt a new application, or a new process, or a new UI, or a new feature, we are asking them to invest an effort to adopting our way of thinking. Every change involves an amount of switching costs that some users just won’t be willing to pay. [1]

I’ve talked about it before: we should solve a single problem that our users have and solving it completely. The delight is in getting that right and making users awesome like Kathy Sierra says.

Make your users better or remove pain that they face. Otherwise it’s easier for your customers to do nothing and change nothing. They might even leave.

[1] Sometimes it’s not up to the user. Some companies just won’t care what the impact is on the user: in monopolies or locked-in environments where the switching cost is just too high (“I have to buy an iPhone to get this?”), or just not available (lack of supply), users are forced to take on whatever change is made to them. If you are dependant on a particular service (for instance your Internet provider), you’re forced to adopt whatever new process or tool is decided for you.

Culture is

• respecting your customers
• respecting your employees
• paying them fairly
• paying them equally, regardless of gender/race/background/country of origin
• giving fair equity in your company (if equity is part of your packages)
• paying people to relocate if you ask them to
• respecting their time off
• respecting their boundaries
• recognizing that we’re humans building things for other humans
• trusting your team
• building your team’s trust in you
• listening to them
• trying their ideas
• working hard for them, not for yourself [1]
• being flexible
• allowing everyone to work remotely if one person can work remotely
• offering the same perks to everyone
• not having one rule for employees and another for managers
• removing pain for customers
• removing pain for employees
• learning what your employees love
• learning what your customers love
• removing roadblocks
• building a learning culture
• supporting hack days
• encouraging hack weeks not hack days [2]
• establishing agreements not enforcing rules
• humans not recruitment
• practices not processes
• completing a task not half-arsing things
• important when your company has 1 employee
• important when your company has 10+ employees
• important when your company has 100+ employees
• important when your company has 1000+ employees
• important when you have no money
• important when you have money
• not cargo-culting
• not blindly following what the competition is doing
• not blindly following what other startups are doing
• listening to what your employees who may worked at other big companies (Google, Apple, Facebook, Amazon, etc) have learnt about working
• listening to what your employees who may have founded a company have learnt about starting companies and growing them
• solving the right problems
• solving big problems
• learning from your mistakes

[1] This idea is described in Australia to a certain extent as mateship of an inclusive nature. It is a term that has militaristic connotations as well for Australians, as the ANZAC story often revolves around thinking not necessarily of fighting for the broader goals (the war), or even the tactical goals (the battle) but fighting because your mates depend on you. In this context, teams that feel bonded and work for each other not individuals (selflessness not selfishness) builds mateship.

[2] Arguably you might even want to consider even longer than that because allowing people to solve problems that are more complete than a random hack. Also, this means that you could consider doing multiple hacks, or a non-work hack and a work hack.

Culture is not

• your product
• your platform
• your perks
• your benefits
• your marketing
• your elevator pitch
• your market
• the size of your company
• the countries that you operate in
• the countries that you sell to
• free snacks
• free soda (soft-drinks)
• free lunch
• free dinner
• a beer fridge
• a bar in the office
• buying rounds of drinks
• having Friday drinks
• having Friday snacks
• having a box of cereal in the office
• having a cool office
• having cool artwork in the office
• having a dog-friendly office
• having a cat-friendly office
• exposed concrete floors
• big windows
• an office in the Mission
• an office in the Valley
• an office in Manhattan
• an office in Brooklyn
• Aeron chairs
• bean bags
• Apple laptops
• big monitors
• big Apple monitors
• big TVs
• fancy phone-conferencing units
• fancy video-conferencing units
• wearing hoodies in the office
• wearing tshirts in the office
• wearing jeans in the office
• having a casual clothes policy
• free merchandise
• free t-shirts
• free hoodies
• having Slack (that’s different to how you use Slack)
• having Campfire (that’s different to how you use Campfire)
• having IRC channels (that’s different to how you use IRC)
• capital-A Agile
• just applying Scrum
• using Trello
• using Pivotal Tracker
• using Asana
• your funding
• having investors
• seeking VC funding
• having VC funding
• recruitment
• having an HR team
• using version control
• using Bitbucket
• using GitHub
• using open-source
• having data
• having big data
• having big data visualizations
• being on Hacker News
• being on Product Hunt
• having a Twitter account
• having an Instagram account
• having a Facebook page
• having an MBA
• having attended the right college/university
• having employees who used to work for Google
• having employees who used to work for Facebook
• having employees who used to work for Amazon
• having employees who used to work for Apple
• having employees who have founded a company
• what parties your founders go to
• what conferences your founders go to
• what your employees on weekends
• working on weekends

I’ve written about how Australian ultimate frisbee players can improve their personal and team defensive skills before. It summarises what I believe what good defenders and good defensive lines do.

But what about Australian ultimate as a whole? What happens when we look at the state of defensive play across Australia? This is particularly important when we are trying to select players to represent Australia.

Even if we know what good defense looks like, we still struggle with:

• that it’s hard to measure some of these defensive qualities. How do you measure innate abilities fairly (objectively without bias) across a large set of players?
• the reality that team selectors in Ultimate, right now by and large, are prior players. Prior players don’t like the idea that the selection criteria that got them onto the team was, at best, a random process with little to no scientific process. The status quo reigns.

Unlearning the learnings

Like most things, learning the basics of ultimate frisbee is pretty simple. There are any numbers of ways to get involved (pickup, college/university games, social league, friends, etc), and they will teach you the basics: the rules, the force, the basic gameplay.

As you progress from beginning to a more experienced player, you acquire knowledge about the strategies, tactics and plays that teams and players use to succeed. There are more detailed and rigorous training programs, skills sessions, more scrimmages. You’ll learn about a whole number of different defensive and offensive plays, which will get tweaked and refined by each individual club and/or team captain to his/her liking, and have a whole laundry list of things you’ll have to remember everytime you play.

However, when you get to the elite level and you’re competing at an elite level against international teams, a lot of this no longer matters. It’s a given (or should be) that every single player is fit, understands a whole range of plays, and has superior catches and throws than 95% of the ultimate frisbee community. There is an implicit understanding that players at this level have seen enough frisbee that no play will be that hard to work out. Turning up to a World Championships expecting to suprise teams with your ‘new’ defensive structure and magically create turnovers is just silly. This might work for a low-level or inexperienced team but it won’t work against the depth of experience of the USA or Canada. In fact, it’s likely that those teams have already thought of your defensive structure, played it before, played against it before and learnt the strengths and weaknesses of it. They probably have their own very version of it.

What differentiates great ultimate players at the truly elite level is often a few things, some obvious, some not so much:

• sheer physical ability (height, strength, vertical leap, speed, dexterity, reaction time)
• the ability to execute the play correctly
• the ability to read the play and make the correct split-second reaction
• the ability to adapt to changing structures, plays, weather conditions, team composition
• the ability to ignore the set play and go with your gut
• your level of cohesiveness and bonding with fellow teammates
• endurance (the ability to play explosively for 3-4 games a day over 4-5 days is unlike any other sport’s requirements)

Let me clear here: being a world-class team has less to do with your learnt abilities (plays, structures, etc), and lot more to do with innate ability.

The reality is:

Poor defensive teams let their opponents execute Plan A. Whatever play they worked out on the line (or previously) is easily executable.

Good defensive teams force their opponents to execute Plan B. The original play didn’t work, so the offensive team falls back to a dependable strategy they’ve used before.

World-class defensive teams force their opponents to dream up Plan D on the spot mid-way through a long point after trying to execute Plans A through C. It’s here where you create turns. Note the difference between getting turns and creating turns. Getting a turn may mean that your opponent’s Plan A didn’t quite come off (usually a symptom of poor execution), whereas creating a turn means that you forced your opponent into a position that they weren’t comfortable with, and maybe hadn’t drilled as well, and maybe had to take the 70% option in Plan D. They had to reach further past the mark to throw that huck, so it came out a little more bladey than they originally planned. The throw was a bit late because they saw the cut later than they needed. The cuts dried up because the cutters couldn’t understand what the handlers wanted. They couldn’t throw the easy IO break that always get them open even in times of trouble.

Australians don’t know good defense

Whilst watching the World Ultimate and Guts Championships 2012, held 2 years ago in Sakai, Japan, I was struck by something about the Australian teams at WUGC2012 that marries up with what I’ve seen of US ultimate.

Side note: excellent live coverage was provided by NextGen Ultimate (albeit with rather unexcited commentary). Ulti.TV filmed games as well for later distribution. Being able to stream HD footage of ultimate games effectively live is pretty amazing, and a tribute to how far our sport has come in such a short time.

All of the Australian teams had excellent, strong offense … and pretty woeful defense. Sub-par to anything that other teams had. Australians spent most of their time chasing their players in circles, often shocked their player was always free, and suprised how easily their ‘new’ defensive structure was destroyed.

From seeing a number of games that the Australian teams played, there are two things to call out here and compare:

1. The Australian teams generally trailed their players, both under and deep. They chased their players, rather making than a concious decision to defend. If you are chasing your player, you are really not defending. You might as well not follow them and just get off the pitch. At WUGC2012, a lot of players marked almost 3 metres away.
2. There was no alteration of the opponent’s cuts or structure whatsoever. Offensive players were cutting where and when they would like to. They were directing the play around their desires, rather than being pressured into falling back to Plan B. If they wanted to cut deep, they went deep. If they wanted to go under, they went under. The handlers could go up the line, or backwards for an easy dump. The cutters could cut break or open if they want. It’s their choice.

The Australian teams did worse than they hoped (or maybe worse than they expected) not because of the strength of their offensive lines but because of their onfield defense. This is not a comment on the defensive line itself (although there are plenty of questions that have been asked about the selections of defenders, primarily around picking normally O-line players on the D-line).

Defense in Australian ultimate is a second-class citizen

I guess this may be a byproduct of the nature of the Australian ultimate scene: our limited depth in teams means that extremely strong offensive teams with not-so-strong defensive lines will generally still succeed through to finals. At this level, it’s actually more critical that your offensive team works than your defensive team.

An excellent defensive line at Australian Nationals will generate turnovers for your team, but if your offensive team cannot score 99% of the time, then it does not matter what the defensive team does.

So, how can Australia as a nation improve their defense?

Notice that very few of the points I listed above have anything to do with coming up with some shiny new defensive structure, or working on getting a ‘Japanese’ zone just right. In fact, I’m of the opinion that drilling new defensive structures or tactics, the typical tactic of the Australian national teams and clubs leading into a season, actually reduces defensive skills.

If we really want to build a proper group of defensive players to represent Australia, we should take our cues from other sports. Sports such as soccer, basketball, NFL and AFL all have individual and team level defenses and spend more time on individual defensive ability: footwork, reach, instinct, reaction are all tested, much more than any ability to play a zone. It should be assumed that you know the mechanics of a zone, or a junk, or a puppy fence. In fact, if players are being selected to represent Australia who don’t know how to play any position in any of the common defensive structures in Ultimate, there should be hard questions asked of the selectors.

This is equally a physical and intellectual problem: the best defenders are fast physically and mentally. They can read the play and have the capability of shutting down players. They can critically analyse a player and a new strategy to find what they need to cover, and what they need to stop.

So what can we do to fix this?

Well, first and foremost, we have to accept that we are going to suck at this for a while. Right now, Australian ultimate revolves around the offensive skill-set and it will likely do so for some time. It will take a concentrated development process, hand-in-hand with Ultimate Australia and clubs, to build strong defensive players. Much as basketball has development for point guards, we should develop defensive players and a defensive coaching structure for Australia that revolves around identifying and training individual defensive skills, and then selecting players based on those individual skillsets.

To be honest, a generational change may also have to take place. I have a sneaking suspicion that the current crop of Australian selectors and elite players subconciously believe that offense is the key, and that defense is merely a step in the path to success. How else can we explain the selection of strong, long-term offense players to the defense line? Merely through the belief that our opponents will turf the disc, hand us a turn and et voila we need excellent O players? Knowing when to switch to a zone and when to man defense is just one out of many skills required for excellent D.

Let me throw an idea at you:

One of the key practices of high-performing teams is that they have a lot of meetings.

What?!

Cue crazy riots, angry mobs, etc.

No, seriously. Great teams have lots of meetings. The difference is that they have great meetings, not painful ones.

A common agile smell to avoid are teams who blindly follow an Interation Planning Meeting (IPM), even though they’re not sure why they should do it. Mostly, they do it because Scrum told them to or they’ve seen other teams do it (there’s that cargo-culting again). The meeting takes hours, doesn’t achieve it’s aims (if it even had any to begin with), it’s unstructured, everybody hates it (you’ll see the looks of despair as they leave), and everybody hates it like the plague.

Then what happens?

• People avoid going to the meeting.
• it’s the first one to get rescheduled.
• it drags on even longer as people arrive late or find any excuse to not leave.
• eventually, it requires day-long sessions just to catch up (or week long sessions).

What do great teams do? They ask themselves why this is the case. And they improve it.

They hold more regular meetings with more focused outcomes. The meetings are shorter. Instead of trying to plan 5 weeks worth of work, they plan a week’s worth of work. Super mature teams may do this process for a single day’s work because they feel comfortable only planning a day’s worth of work.

They also have meetings up front of doing development work because they know it’s worse to have the meeting afterwards trying to understand what was built.

If you walk into a very mature agile environment, you often see huddles of people chatting, or pairs of people busy pair programming. It’s hard to grasp at first, but these people are meeting. Constantly meeting.

Meetings don’t require formal start times or meeting rooms to be meetings. Meeting are about close collaboration to solve a problem.

Don’t avoid meetings. Just avoid having the wrong ones.

One of the hardest things to build is pride: in your product, your team, your people, your organisation, your industry, your vision. I’ve written about building great teams, products and organisations but I haven’t written as much about tracking how you’re going.

So how do you measure pride?

A really simple measure to start using is the Net Promoter Score idea. It was originally developed as a measure of loyalty but it’s useful as a measure of pride

NPS is based on a direct question: How likely is it that you would recommend our company/product/service to a friend or colleague? The scoring for this answer is most often based on a 0 to 10 scale.

There’s two advantages to using the Net Promoter Score to track satisfaction:

• It’s simple: I just have to tell you a number between 0 and 10.
• The situation requires my personal endorsement and a personal connection, which means I have an element of being attached to the score.

Most organisations have come across this idea before: they have surveys about their product, they include ratings on products. A lot less use it internally to assess how teams are performing and how their people feel.

But it’s actually works at every level of your organisation.

Want to track how proud your team is of their team? Ask them how likely they would be to recommend that other people join the team.

Want to track how proud your team is of their product? Ask them how likely they would be to recommend that a friend use their product.

Want to track how proud your employees are of their tech stack? Ask them how likely they would be to recommend the technical choices to a friend.

Strong (high) scores manifest as a measure of pride. And you can learn a lot about the correlation of problems. for instance, seeing a lot of low scores across teams in recommending their tech stack could mean you’re carrying a lot of technical debt, or the technical leadership is lacking, or the technical stack is just not easy to work in.

I certainly wouldn’t use it as the only measure of satisfaction, but it is a very low-effort simple way of tracking pride. I also wouldn’t overdo it - don’t ask 1000 questions about every possible aspect every day, but you can use it every week very simply (max 1-2 questions). If you need to dig deeper, you can ask again in more detail later.

You should be using other quantitative and qualitative measures to determine pride as well. Things like 1 on 1 meetings and retrospectives are great for hearing about how things are going.

Low scores will manifest alongside things like high rates of annual leave, sick leave, people arriving late/leaving early, high churn rates, low levels of employee recruitment referrals, or just lots of people quitting. But those are lagging indicators, and NPS can be useful as a forward indicator. And if you have low scores, then you know that it’s time to bring a lot more focus into those areas.

But what about shame? Shame works out as the emotional cost of working somewhere you have a negative Net Promoter Score. You actively discourage people from joining you. You’re ashamed by your product. You’re ashamed by your technical stack. You don’t want to be associated with it because your friends or colleagues will think badly of you.

If you’re hitting close to 0 in the scores, or just getting low scores across the board, it can be just as important to begin wondering if people are actively dissuading their friends or colleagues from joining the company or the team, or from using the product. You may want to try asking the the inverse question, “How likely is it that you would actively discourage a friend or colleague from our company/product/service?”. This is super scary stuff for most organisations but finding out how your team feels sooner is much better than having them all quit on you.

Net Promoter Score is a simple measure to use to measure pride and morale in your product, team and company. Try it out and let me know what you think.