Remote Work Is The New Black – Part VI

Remote work is the new black
Standard
All "Remote Work" Posts
IntroductionInformation IInformation II
GamblingPrioritiesAnarchy 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.

Remote Work Is The New Black – Part V

Remote work is the new black
Standard
All "Remote Work" Posts
IntroductionInformation IInformation II
GamblingPrioritiesAnarchy 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.

Remote Work Is The New Black – Part IV

Remote work is the new black
Standard
All "Remote Work" Posts
IntroductionInformation IInformation II
GamblingPrioritiesAnarchy 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.

Remote Work Is The New Black – Part III

Remote work is the new black
Standard
All "Remote Work" Posts
IntroductionInformation IInformation II
GamblingPrioritiesAnarchy and Order

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
GamblingPrioritiesAnarchy and Order

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
GamblingPrioritiesAnarchy and Order

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.