Remote Work Is The New Black – Part V

Remote work is the new black
Standard
All "Remote Work" Posts
IntroductionInformation IInformation II
GamblingPrioritiesPart VI

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.

Remote Work Is The New Black – Part IV

Remote work is the new black
Standard
All "Remote Work" Posts
IntroductionInformation IInformation II
GamblingPrioritiesPart VI

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.

Remote Work Is The New Black – Part III

Remote work is the new black
Standard
All "Remote Work" Posts
IntroductionInformation IInformation II
GamblingPrioritiesPart VI

We’re considering how remote work tends to slow us down, and how we can pick up the pace without losing quality, or steam. Last time, we’ve talked about the lack of availability of information with remote work. Let’s dive into that for a bit.

As we all know, things change all the time. A lot. Remember when we used to laugh at Corona beer jokes a couple of weeks ago? Who’s laughing now?

The toilet paper manufacturers. But that’s another story. Anyway.

The way we interact in the office, the culture, the process of delivering and receiving information – we’ve grown accustomed to how things work, when everyone’s around. That changes a lot when we do remote work.

Say for example, you’re really good with visualizing data in your team. You have dashboards all around you, and you can’t miss an update, even if you try. Things are not like that now.

Or, let’s say you’re really lousy with visualizing data, but depend on people documenting everything. Whenever you go to Jira (after saying a short prayer), you always find your tasks prioritized.
Things are not like that now.

Or, say your team is really lousy with communicating. You always need to dig and investigate for more data. You file a bug, but is it really a bug? You expect some answers within a reasonable time period.
Even those things are not like that now.

When you remote work, and miss out on information, or work on tasks based on wrong information, you’ll make mistakes and then go back to fix them. Or just wait for the right information, then do something with it. That slows you down.

So what can you do? Set some ground rules:

  • Set communication time slots, where people are available for questions.
  • Assert roles in the team, so people know exactly who to turn to for answers.
  • Pair online, so you know better, get answers quicker and more people have answers.
  • Agree on where and how to document stuff – requirements, bugs, anything of importance.
  • Review every couple of days if the rules work, and adapt.

Next time – more about how lack of information slows us down.

But you don’t have to wait: Get your remote team working again . Check out my First Aid Kit plan.

Remote Work Is The New Black – Part II

Remote work is the new black
Standard
All "Remote Work" Posts
IntroductionInformation IInformation II
GamblingPrioritiesPart VI

Early morning, off to do some remote work.
Just kidding, Early? Right. Anyway

You got your task work ready for you. You know exactly what you’re going to work on today. You start coding, or writing a doc, or testing an app. And then stop.

You have questions, or some great ideas. And there’s no one around to ask. Sure, there’s going to be in a few minutes when they come online, on their own sweet time. So you wait a few minutes, have that conversation. Hopefully not texting, or slack. That would slow us down even more. And a few more minutes go by.

Then you continue to work. Until the next bump.

If you’re not used to remote work, the first thing you notice is lag in accessibility. We take availability of information and people for granted, but when everyone’s remote, things bog down. We slow down.

So tip #1 in the communication field doing remote work: Over-communicate.

You need to talk more with teammates. More than before. Set working times when everybody is available and working on the same things. And if you haven’t yet – set them as ground rules.

And notice the lag. Try to count “stuck moments”. See how they accumulate and affect your remote work.

We’ll get back to ground rules a lot. To be effective, the team agrees to play by the same rules. Soon as next time.

In the meantime, get your remote team working again . Check out my First Aid Kit.

Remote Work Is The New Black – Part I

Remote work is the new black
Standard
All "Remote Work" Posts
IntroductionInformation IInformation II
GamblingPrioritiesPart VI

I looked around the office, and there was no one working. No typing. No staring confusedly at code. No arguments about where to eat lunch. Empty rooms.

There are more and more workplaces like that. People start remote working, or on leave. Or worse.

But how does work continue? Slowly. Very slowly.

We believe we will live through this. No, not the virus.

The period until victory and when life resumes. But as a team, and as team leaders we want to continue working with the processes we had success with before. Now it’s a whole new world of remote work we didn’t prepare for.

We don’t know how to make the jump. The result is work slowing down.

I’m going to write for a while about different problems I see happening, from the remote worker’s perspective, but mainly from the whole team’s perspective. It’s how to keep the team development standards as much as possible in a remote world.

The next post is going to be about the first thing we notice: Lack of accessibility, and how to counter it.

In the meantime, if you want my help to get your team working again in the age of COVID-19 check out my First Aid Kit program.

The Zen Tour Continues – #TestIL Meetup Tel Aviv

Gil Zilberfeld at the Test IL meetup.
Standard

Once more unto the breach, my friends. Once more.

This time I took the Test Maintenance presentation to Tel Aviv. The presentation is right there below.

Test maintenance is something nobody loves doing, but everyone must. The presentation is about what we do when we’ve accompanied lots of tests, some of those tests are old, some new tests we’re writing. How to organize those tests, add tests in a smart way so people can find them. The we looked at different types of tests and smells in them and how to fix them.

The one-hour presentation is a very compressed version of a full-day workshop on Test Maintenance. That’s right, you can have the “Test Maintenance” workshop experience, including many hands-on exercises in your workplace, on your code.

Check out the workshop page.

TestIL Presentation: Zen and the Art of Test Maintenance

Gil Zilberfeld and friends at the Test.IL Meetup on maintenance presentation
Standard

Making the “Zen and the art of Test Maintenance” workshop into an hour long presentation, I made way north on a dark and stormy night. It was lovely to see old and new acquaintances.  I saw a nice demo of  new-ish open source tool called Oxygen, presented by Nick Dimer. Thanks for the organizers of the meetup, Nitzan Goldenberg and the hosts in Bar Lev HiTech Park. And to Bar Gothertz for the photographs like the one on top!

This will come in soon to the Israeli center soon. And as always, if you want to experience the full workshop, test refactoring galore, let me know in the comments.

Here are the slides:

Let’s Test 2019: “Zen And Test Maintenance”

Art of Test Maintenance Workshop
Standard

Last week I came back from Let’s Test South Africa. As always, Let’s Test stood up to its name. It’s a small conference, with a lot of hands on-learning, and a focus on community. It’s about testers meeting other testers, learning, and feeling good about it.

My workshop “Zen And the Art of Test Maintenance” went great. (See picture for testers working on refactoring tests.) Unfortunately, immediately after the session the bug I apparently picked up on the plane hit me hard. I spent the next day either in bed, or trying to keep awake at sessions I didn’t want to miss (Hi Paul Holland!).

I’ve also re-met friends (Simon Berner, Gerlad Mucke, Beren van Daele, Regina MartinsJoanne Perold, Elizabeth Zagroba and Paul Holland ) and made new ones. I want to thank especially Alison Gitelson for drawing the poster for my workshop (the main picture on top). And to Louise Perold and the rest of the crew for an awesome conference. I’ll be coming back. Healthier.

Zen and the Art of Test Maintenance Workshop with Gil Zilberfeld at Let's Test

After that, things got better. I got back to eating the awesome food provided by the conference. Then I became a tourist for a couple of days, plus going to a karate class in a local dojo. I felt a lot better then.

Anyway, that’s 2019 testing schedule. I got one more training on agile and estimation this week at Sela Developer Conference.

Then it’s on to 2020. I have a good feeling about next year. Stay tuned.

Technical Debt Considered Harmful, Part II

Technical debt and code entropy - same same, or different?
Standard

Last time, I gave you the short-short version of thermodynamics. We talked about how entropy grows rampant, as well as creating waste in the system, if it doesn’t have constant energy input.

Let’s get back to technical debt. The technical debt metaphor has two parts: First, it slows us down in the long term. The second part is that it can go away – for a price.

You can already see the resemblance to our energetic system. The code has growing entropy. Chaos, or our inability to control the code, keeps growing. The chaos creates energy-wasting traps, and we deliver slower.

What are these traps?

If we don’t have tests, we tend not to refactor. If the code is not readable, we’re very cautious about adding new functionality. If the code is one giant method, we tend to add parts of the new functionality within the giant method, otherwise we risk breaking stuff. These are the time-sucking traps we need to avoid, instead of going forward fast.

So the code grows, laying more energy traps for us, which slow us even further the next time we go into the swamp.

We need to invest energy in the system to remove the traps. We need to take care of the code – spend time in refactoring, improving it, so the next time the swamp is easier to navigate through. In the long run we sustain velocity, instead of losing energy. The swamp gets clearer, but never gets clear.

The second part of the metaphor is where I think it fails – since it’s not really a loan, we’re never going to fully repay it. There’s not going to be an endpoint where it is repaid. There’s not going to be a single point of repayment. There’s always something more important to do. And since we never stop and “repay it” – we’re stuck in a downward spiral.

In the real world, the best we can do is keep things under control the best we can. We do that with clean code, refactoring, adding tests and code reviews and design reviews. Those reduce the energy traps, and maintain sanity. Entropy does *not* grow unchecked. But since entropy wants to grow, we will keep doing the work, putting energy in, but there is no end in sight. Or at all.

In some situations we believe we can repay the loan fully. We later discover we got to a “good enough” point. If we continue after that, the way we worked before, we see that the “good enough” point is not only good enough, it was just a temporary mirage.

I’ve stopped using technical debt as a metaphor, because it doesn’t correspond with reality. In real life, the business people have no problem sacrificing long term costs for short term gain. The loan can never be repaid.

Instead we should continuously lower the code entropy, get rid of the black holes, and putting energy, into clearing the code swamp.

Technical Debt Considered Harmful, Part I

Gil Zilberfeld explains how technical debt is confusing, and instead using thermodynamics to explaining the benefits of clean code and refactoring
Standard

Goodheart’s Law states that when a metric becomes a goal, it is no longer a good metric.

I don’t know when technical debt became a metric. But SonarQube calculates and reports it as such. If this calculation is correct (you must be scratching your head right now) people may assume that once they eliminate it, according to the calculation, they are debt free.

Of course, they are not. The technical debt metaphor (yes, there’s no real metric) was supposed to help explain the idea of comparing technical tasks to feature tasks, which are considered more valuable. Technical tasks, like adding tests, refactoring and simplifying the code and architecture don’t have an immediate value, compared to “real” features (I know, it’s perceived value, not necessarily an  actual one). But not doing the technical stuff makes adding feature value slow in the long run. The deeper the debt, the slower you get with the new features.

Business people, however, don’t understand how “not working on features” helps features get built. Organizations that have evolved beyond that don’t require technical debt use, since they already understand the impact.

I don’t use technical debt in my vocabulary anymore. So I needed an alternative. When I studied engineering I took a couple of courses in thermodynamics. Little did I know then, how well they relate to coding.

Ready to learn a bit?

A system has different kinds of energy in it. They can be kinetic, electrical, or potential energy which can transform into other types energy. Energy can be transformed into “work”. In physics, “work” is the implementation of potential energy. In a closed system, energy is conserved, but as we all know, no system is really closed, and therefore every system cannot conserve all its energy, unless we add more energy into it – like heat it, charge it, throw it real fast. You get the idea.

Next, there’s entropy. Entropy is basically the chaos in the system. Another way to look at entropy is from a perspective of energy. Entropy is the amount of energy that we cannot use to do work. We can’t transform it into useful kind of energy, because it gets wasted.

Now, if left unattended, given enough time, chaos takes over. In energy terms, we lose the energy, since it cannot be conserved. Entropy grows, unless we put more energy into the system.

Reminds you of something?

Part II is all about energy and entropy in code.