There it is. 5th and the last theme. “Crave for clear rules”, as the official description says.

What kind of rules could it be that I crave? What challenges can the rules bring?

Consistency as a programmer – 10 symptoms

1. Process is good

Processes have negative connotations. They are on the right side of the agile manifesto. And I claim myself agile. How come?

To me, a process doesn’t have to mean a big and slow corporate machine. Process is a visible extract of how we do things in our team. Visible! That’s the missing part of almost every “process” I ever saw.

Process is a communication tool.

Processes can and should be automated. But first, they need to be visible.

And yes, individuals and interactions can trump processes. These situations should lead to improving the process. Not to anarchy!

2. Communication rules

Communication might be the bottleneck of software development, yet nobody really tries to address this problem.

Here is my attempt to address it. Full of simple rules to follow.

3. Web Team Manifesto

## Next developer happiness-oriented
- We care for a reliable test base. If the tests pass, there’s a high chance it will work on production
- Our code is self-explanatory
- We keep README concise, up-to-date and informative
- [NEW] We commit to `main` at least once a day

## Visibility in Communication-oriented
- We don’t rely on esoteric communication channels like offline, meetings or Slack.
- Each important information is moved to proper long-living place - documentation, Pull Request, code, knowledge base
- We overcommunicate our progress. No micromanagement is needed.

## Client’s perspective-oriented
- We don’t play with your budget. When considering new technologies, we take the risk into account.
- We solve problems. You tell us what’s yours and we will solve it time-efficiently. 
- We don't just move issue from one column to another. We make sure that the problem is solved. 
- We proactively suggest best solutions and alternatives

## Next actions-oriented
- In discussions and meetings, we aim for action points: Who does what and when.
- We constantly ask ourselves: what's important now?- matrix eisenhower
- We focus on fixing instead of blaming

I like proactivity in establishing rules. Here is a manifesto that we came up with when working in a small team, even though nobody ask us to do it.

4. The simpler the better

Back then we also had a rule that I loved – during code review, each comment should have an urgency – could, should, or must:

  • Must – I won’t accept until you fix it
  • Should – I would change it but will accept if you disregard
  • Could – food for thought

I love this but I would simplify it. There is no real difference for the author between should and could. Therefore I would get rid of one of them, leaving only two levels – must and could.

5. Expectations

I like clear expectations and I tend to give other people clear expectations too.

The problem with no expectations (or rather implicit expectations) is subjectivity.

Funny thing is that on a personal note, as a stoic, I tend to make no expectations whatsoever.

6. Pyramids – higher-level rules

Sometimes you just can’t follow all the rules. Many known rules contradict each other. You show the realization of this when you order them in a pyramid.

I always liked “Make it work, make it right, make it fast“.

My own pyramid is even better.

Another pyramid that speaks to me is 7 habits.

7. Respect for definitions

If we estimate in story points, don’t estimate in days and translate to SP.

If we have a sprint goal, don’t ever make it “finish all the tasks”.

If we have a brainstorming, don’t ever say “there is no stupid idea except yours”.

We should follow the definitions even (or primarily!) if it pains.

The biggest distortion of the definition is…

8. The lie of agile

I’m not saying that all should be agile. I’m saying that, if you claim so, you should do so.

There is nothing wrong in admitting “we’re not agile”. In fact, this is the only acceptable way if you really aren’t.

Being agile (instead of only saying so) and forgoing agile are two 100% legit options.

And from what I know, that’s typical among people with high Consistency. We do or we don’t. Either way, it’s ok! But don’t mix yes with no.

9. We need (some) metrics

I think we need objective metrics that measure our code. Best effort is not enough.

On the other hand, if a good metric outcome is the only expectation, we’re doomed to follow a common pattern. Disregard all other values than metrics.

Metrics like velocity, burndown, and test coverage are not bad. The best however is time to market.

10. How to measure anything

I love this book. It gives a framework that can square Individualization and Consistency.

The biggest selling point of the book is that you can indeed measure anything. The hard part is that you (personally, or as a group) have to define it first (that’s Individualization).

Once you figure out what matters to you, you have to create an objective metric (that’s Consistency).

Summary

Look at the combination of Consistency + Responsibility. I should have become a policeman. The funny part is that I don’t consider myself very lawful.

Another strange combination is Consistency + Individualization. The two seem to contradict.

More Gallup

For the record, here are my top 5 CliftonStrengths themes.

  1. Responsibility – read more
  2. Individualization – read more
  3. Developer – read more
  4. Ideation – read more
  5. Consistency – this post