Last time we’ve talked about counting the number of tests. That’s a pretty good indicator of how the team is adapting the new practice of writing tests. But how do they treat those tests? Do they see tests as a helpful technique to their code quality? Or do they write tests because they follow the scrum master’s orders?

(If there’s a master, there are probably slaves, right? Never mind).

So let’s take a look at our next metric: Rate of failing tests.

Should I track it?

Oh yeah. All the time. Its meaning changes over time, though.

Why should I track it?

There will be failures. That’s why we write tests – to warn us if we’ve broken something. But then we review those failures and discuss them, and we expect results – the overall test failure rate should drop (to zero if possible), and existing test failures to be fixed quickly. Sometimes the review of the failures may lead to have an affect on the rate – it could be that flaky tests should be handled differently. But overall, the metric tells us about attitude.

What does the metric mean?

Remember, we’re counting those failures in the our CI system.  We expect very few test failures, because we expect developers to push tested code. The tests should have run on their machine prior to pushing.

Always working tests in CI means the code quality is respected. Seeing the failure rate go down shows adoption.

To take it further: it’s about respect to other team members and their time. When the test failure rate goes down, the build doesn’t break so much. People don’t waste time to get it fixed, or waiting for it to be fixed.

In the long run, after the team has adopted automated tests, if the rate doesn’t drop to zero, it’s a sign of the codebase’s quality – the team doesn’t take care of consistent failing or flaky tests. You can then make decisions – remove tests, improve the code, or do something completely different. Your choice.

How to track it?

Easy, any CI tool will show you the number of failures for every build. We want the number to be as close to zero averaged over time. Put a graph on the wall and review at the retrospective.

Is it comparable?

Nope. This is a team specific metric. Different people, skills, experience and codebase make numbers different for different teams. There’s no sense comparing failure rates.

Want help with visualizing and measuring the quality of your code and tests? Contact me!

I’m working on an interesting project for a client about showing different, somewhat advanced metrics on their code quality. So I decided to write about metrics, what they mean and how you can track them, and much more importantly, how to use them. And yes, even though I talked about a lot about coverage before, I’m going to mention it again. And again. But we’ll see.

The first metric I’m going to talk about is… number of new tests. Well, that’s not really a surprise based on the title. You’re still impressed, right?

What is it?

The number of new passing tests added between builds or over a period.

Should I track it?

Yes. For a while.

Why should I track it?

At some point in your life, or your team’s life, there comes a time where you’ve had enough of those returning bugs you find really late, and are really a pain to debug. Then, you get a couple of insights: We need automated tests. And we need testable code. And we need code reviews. And by golly, we have arrived!

So people need to start writing and running automated tests. What is the indication of people adding tests? The number of tests! It’s not rocket science, and if it’s easy and simple, you just use it.

And remember, like any important metric, you publish it, visualize it, and talk about it, and the progress the team is making. Because otherwise it’s just a number that doesn’t carry importance.

What does the metric mean?

The simple answer is “do people write tests”. But once you start digging in, you may find interesting stuff. For example, for most teams, the findings would not be “holy velocity, Batman, they are producing more tests than a test factory on drugs”. But hey, let’s say they do. You didn’t expect that, so you can ask more questions: Are those good tests? Are those tests easy to write? Are they cheating me? And if not, why haven’t they started 3 years ago?

Ok, I haven’t seen this happens.

Most of the time the number either doesn’t change, or grows painfully slowly. Then you can ask things like: Why does it take so long to write tests. You’ll find there’s training missing. And knowledge about the system. And that testability of the application sucks. And then you can do something about it. Like call me for training or coaching. Or do some refactoring in those painful points. And truly understand the true meaning of development.

How to track it?

That’s easy. Whenever you build your project and run the tests (I’m assuming you’re using some kind of continuous integration system, like Jenkins, TeamCity, CircleCI or whatever flavor), you can see the number, right there for each build. If you’re running a nightly build, that’s fine too. Weekly not as good, but still works.

You’ve got the number. Show it and discuss it. Ask “what can we do to improve it?”.

Once you see a steady rise in the number of tests, you have achieved one or more goals – people are writing tests on regular basis, and that means they have the know-how and the system doesn’t resist tests. Then you can stop tracking it.

One more thing. The metric is not comparable across teams, projects or even the same team on the same app one year later. Don’t compare those numbers, it leads to pain, which leads to suffering, and doesn’t end well in most trilogies.

Want to learn introduce a dashboard for your team? Get in touch!

Conferences are rare these days, like a meteor shower in Animal Crossing (or so my daughter tells me). However, the online conference market has evolved considerably as an alternatives.

And so, I was invited to do a session, on the agile track of Project Management Day, in Kiev. But borders don’t matter now.

It’s on one of my favorite subject – agile estimation. This is a short one, but if you’re interested, register to the squeeze course. Of course.

Here is the recording.

There are unit tests, integration tests, API tests, end-to-end tests and other “test” animals. (No animal was tested for this post).

These types of tests are based on what they test. Unit tests test a code unit – a method, a class, a small set of classes. An API test checks our API behaves properly.

Micro-tests can be understood the same way: They test a very small portion of code (sort of a unit test). However, that’s not really what they are about.

Speed

They improve our speed of producing working code.

Micro-tests are small tests that test small code. But if you write them incrementally, you make a large piece of code faster. Which also works. You just don’t waste time on writing extra code that gets in your way of adding more code later. You don’t debug.

Think about it: Continuous work of adding code that works.

TDD focuses on adding just enough code – enough to work, and enough for us to focus on. We then move to the next bit. The smaller the bit, we move faster. We focus on the current small problem, solve it and move on to the next one.

We don’t debug, because that’s a big waste of our time. If we don’t understand what’s going on, we’re not in micro-land anymore. If we get stuck, we can (and should) revert. We haven’t written too much code since we were green anyway.

The smaller you cut your “feature”, with micro-tests, you’ll implement “all the features” – faster.

Imagine: You’re on a ship, sailing the endless ocean. You’ve been on this voyage for a while now. You don’t remember since when, and you’re not sure how much time will pass until you see land again. The weather report says it will be like this for a while. You keep going.

Are you on the “Corona” ship too?

We’re not used to these long periods of time. Remember deadlines? We used to live by them. We checked our velocity by deadlines.

No matter how you measure it, velocity is down. What did we do in the pre-corona days?

“Ah, we’re late again. We were sure we’ll have these features ready by now. We better push what we have now, and press forward with more features.

Quality? We’ll take care of that when we have time”.

We’ve been there, and we’ve paid the price. We called it “technical debt”, but let’s call it for what it is: short term wins, paid for by future slow down.

Jump

So why am I telling you all this?

Well, reality has stepped in and gave as a choice. Because of the slow down we can do one of two things: Use the less time we have to push what features we can, and throw quality even further out of the window. Staying on the ship, until the food supply runs out.

Or we can do something surprising – jump.

We can use the slowdown to invest in the future. For example:

• Automate the things we did a hundred time manually because we didn’t have the time.
• Pay up some technical debt.
• Add tests around that mess of a code.
• Refactor that mess.
• Learn some new skills (check my online courses).

Technical debt is an economic term. And investing when the market is down make sense both economically and technologically. When we go back to “normal”, velocity will pick up because your code, your tests and definitely you are better.

This is an opportunity. Don’t waste the time we’ve been handed.

Jump.

It was great doing a short “Better Estimation and Planning” presentation on the Kiev Project Management Day, which was online this time, considering the coronavirus roaming the streets.

In these times, both planning and estimation the way we used to is changed, and the data we’ve used as the baseline for our future estimates is no longer reliable. As work gets slower and our processes need reinventing, we need to start collecting data and metrics again. I’ve talked about this in short in the presentation, and I talk about it in depth in my online courses (especially the Better Estimation course, of course).

Remember: Take-Two of My Courses and Get the 3rd One For 50% OFF, OR Take three Courses and get the 4th one FREE OF CHARGE!!!!

Here are the slides of the presentation:

All "Remote Work" Posts
Introduction	Information I	Information II
Gambling	Priorities	Anarchy and Order

There were days, before the last decade (that started last month), where I would laugh in the face of formalities. Sometimes even on purpose to annoy my managers. I really enjoyed complaining on procedures we had, that I knew they didn’t like either, but had to abide by.

I was a rebel and liked it. Today I like to repent.

Let’s talk about the big picture. The processes we had are crumbling. Like society in general, in these trying times.

We have processes for a reason. These are tried and true ways of making things work. And I’m not talking about just “formal bureaucracies” I used to complain about.  The ones we blamed on slowing us down. We have lots of informal processes, that we’ve learned as a team, as a group or organization, that help us work better. They may be formal or not, but as humans we gravitate toward things that help us achieve our team goals, and I call those processes.

Now we have anarchy. Not on purpose of course, but we’re starting to re-learn how to work. And since we’re apart, everyone develops their own brand of “working”. The uniting processes are gone. Welcome to MyProcess™ (patent pending).

That’s MyProcess™, not YourProcess™ . And we’re not sure which one is better. Just kidding, mine is definitely better.

Total collapse is coming. So what do we do?

• Pair. Online, of course. Do more work together. The more you work in a group you’ll slide down back to the “way we worked before”. Even if it isn’t completely that way, you’ll both be working in agreement the same way, and that’s a win.
• New may be good. That’s right, you may have hit a new process that’s better than before. Anarchy has its good sides too. Document and explore what worked and what didn’t.
• Do Retrospectives. Remember the most important meeting in agile? Need to do more. Review how you work, make suggestions and ask questions. You may learn something new that works, and benefit others with what you’ve succeeded doing.

The situation is not quite optimal, but a team’s success is built on the team’s process. Not the individuals’. Sure you can complain, but please not to me.

Want to learn more?

Check out my new online Squeeze Courses (agile, testing and development). These are short, interactive online sessions, where you can learn the (freshly squeezed) essence of effective work, like remote working.

All "Remote Work" Posts
Introduction	Information I	Information II
Gambling	Priorities	Anarchy and Order

We always say we don’t have enough time. Then something like our corona crisis happens, and we have a lot of it in remote work time. I mean, without all that pesky meetings, and 16 coffee breaks a day, we have a lot of time. So what do we do with it?

We still need to work on the important stuff.

Some of us have it easy. We get a list of tasks to do and go do that. That is, we assume other people see the whole picture (our product owner, our team leader, or their manager) and they decide what’s best to work on first. Which works well enough in the beginning.

Then things start to be a bit blurry. As we disconnect from the team and remote work for a longer time, we start to build our own vision of what’s more important.

We start to go off track. We gamble, even if we don’t think that’s really gambling, we’re just making decisions. When we find out, it’s too late. We have wasted time working on something less important, or now need to catch up.

The consequences of these decision include conflicts in the team. I thought that you’ll be ok getting feature X by next week. But you’re ready for integration for the last 3 days, wondering how I don’t see what’s really important. It may be better that we’re kept apart.

And that’s in a tidy environment. If work is messy around the office in regular days, you can see how things just fall between the cracks with remote work.

So what can you do?

• Communicate more. Create more opportunities to discuss who’s working on what and who is expecting what when. (I’m pretty sure that’s real English)
• Continue doing daily meetups. They make more sense when people don’t see each other all the time.
• Visualize tasks, blockers and priorities. Use the tools you have or find better ones (Looking at you, Jira)
• Define a sprint goal (yeah, that thing from Scrum that Jira forgot). If someone’s wondering what should be done next, that’s the guiding light.

I can help you work on what’s really important. And that’s really important. Register for my First Aid Kit program.

All "Remote Work" Posts
Introduction	Information I	Information II
Gambling	Priorities	Anarchy and Order

My Sister works in an online gaming company. She has a lot of work these days – people stay at home, got plenty of time, and play online. Which brings me to another topic that slows remote work down. Gambling.

It’s not really gambling, but it’s close to that.

Most of our work in and out of remote mode, is making decisions. How to write the code, which aspects to test, what to do next. But with remote work, we don’t have guidance, direction or availability for information, it becomes harder, because now, we’re gambling with decisions.

There are basically two groups of people: The do-ers and the wait-ers. Usually we don’t see big difference but the remote situation makes it more extreme.

The do-ers make decisions by themselves, moving forward, consequences be damned. Sometimes the decisions work out well, sometime not. But in our remote work situations, it usually takes longer to get feedback if the decision was the right one. If it wasn’t, it takes even longer to go back and fix those consequences.

The wait-ers, usually don’t take initiatives, and move slower than the do-ers. When there’s not enough information to make decisions, in our remote work, they delay implementation of decisions, which obviously slows work down. But even more so, when NOT making decisions is not reported (which is easier to spot when everyone is at the same place) – blockers are not resolved, and work slows down.

So what can you do?

• Communicate more. Create more opportunities to discuss these issues
• Create an issue board to visualize blockers, and use it not just for regular blocker, but also decisions waiting for solutions
• Make more demos and early. Demos show decision we’ve taken. With more frequent demos, we’ll find problems early
• Award making decision early, and don’t punish “bad decisions”. We want people to make more decisions early.

These are just a few of the things you can try. I can help with the implementation bits for your. Check out my First Aid Kit program.