Oh, what a rush!

So many people overcrowded the room, it seems so many have problems with estimates! But that didn’t deter them, they got through playing with dice and arguing about cheeses. Got very good feedback, and if you want – I can do it in your venue. Just click the Contact link.

In the meantime, the slides are below.

It’s Nordic Testing Days time again!

And this time I’m wearing my agile hat (The TDD hat gets a rest until ExpoQA two weeks later). I’m going to talk about the dreaded planning session. Or in other words – estimates hurt so much, can we stop?

Well, if you’re lucky, the answer would be yes (that’s #NoEstimates), but even if not, and estimates are not going away, we’ll make sure we’re using them wisely.

This workshop is about experiencing all kinds of estimates, starting with agile oldie-but-goodie planning poker, but soon move into more “accurate” and “precise” methods, like using historical data for projections.

In the end I’ll even show you tools you can take home and use with your teams for making planning sessions less hurtful, and even shorter.

God may not play with dice, but we will. I’m bringing all kinds of dice, and we’re going to make history. Literally.

This is going to be fun.

But Nordic Testing Days is also about, you know, testing. I’m looking forward to meet old and new friends and discuss testing, TDD, BDD, Clean code and all kinds of ways to make sure software does what it should.

Check out the full abstract of the workshop on the Nordic Testing Days site.

Gil Zilberfeld presented on user stories at Agile Mancheseter 2018

Had a blast presenting at Agile Manchester.

Attached is a killer pony.

And the slides below.

I like this game as a platform for  exercises: It doesn’t seem to need any requirement specification.

People know the game, and assume that they know exactly how they need to code it. Most of them skip the design phase. It illustrates, every single time, how developers just rush out to “get the job done”, rather than think, design and then code.

One of the first exercises is to start writing code for the game, mostly focusing on names and operations, rather than on actually making it work.

At the end of the exercise we review the code of one of the students. It looked something like this:

public class Game{
  public Game() {
    Board board = new board();
    Player playerX = new Player();
    Player playerO = new Player();
  }
  ...
}

Looks innocent enough, right? I’ve done the exercise more than I can remember, and many times a Game class starts out just like this.

Here’s the thing: Notice that the Game creates the Board? That means there’s a new board for every game.

You know, in real life, there’ll be multiple games on the same board. If we actually thought about modeling the relationship between the Game instances and the Board instances, it would be many-to-few (or even many-to-one, if we’re reusing the board).

Next, the Game creates the Player instances. Since there’s no indication in the requirements who manages the players, the Game is an viable design choice. I’m not going to discuss where it is a good or bad one, but it is a viable one.

Still, as we can read the code, we see that not only does the Game class contains the Player and Board entities, it actually creates them.

Now, would you describe a game like that to a friend who doesn’t know what’s that everyone’s playing?

No. You’d probably describe it like this:

A game is played by two players on a board.

Although the code reads like:

A game creates a board. It then creates the players.

Mincing Words

One of the things I talk about (repeatedly) in the Clean Code class, is the importance of ubiquitous language. That means we use as much as we can names and operation terms from the real domain (the product language) across the requirements, design, code, tests, documentation and operations.

Since we’re dealing with code, what you already see is a dissonance. We see that the relationship between the objects in the model is not as we describe it in the real world.

Of course, it can be a lot more basic. Many attendees who do the exercise describe the Board in the Game like this:

public class Game {
  boolean [][] multi = new int[3][3];
  ...
}

I don’t know about you, but never have I heard the game described using the word “array”. Even by developers. Go ahead, ask them.

Mind Your Language

Of course English and Java (or whatever persuasion you come from on either) are different. Languages have differences inherently.

However, what happens when we have translations errors? Sometimes, we understand, no harm done. Sometimes we end up with a weird Hungarian to English dictionary.

In software, we end up with bugs. Some of them are inconsequential. Some of them are built on the wrong assumptions and backed up by the wrong translation.

How do we fight the translation errors? Well, first acknowledge that programming is a translation activity, and as such prone to translation errors.

Second, don’t skip the design. Use the terms from the domain in the code.

But also, tell the usage story. If we describe the game like this:

A game is played by two players on a board

Then maybe the code should look like this:

public class Player {
  public void play(Game game) {...}
}

public class Game
  public void setBoard(Board board) {...}
}

There are only a few that read as the game is described. If you want easily maintainable design (and who doesn’t) start with as less translation as possible.

You’ll thank yourself later.

“Well, we’re really glad that you’re helping us with TDD, and we see a lot of progress. People not only continue to write tests, they get annoyed when others don’t.”

Excellent. And we’re meeting today because…?

“The tests people are writing are good, and they definitely increase the coverage, but we’re so far off our goal. What can we do to increase our coverage?”

I see. (Smiling on the outside, crying on the inside)

So I begin my coverage rant. Including (but not limited to):

• How coverage of 0% is definitely bad, but 100% doesn’t mean much
• How you can get that 100% coverage in a very costly manner, and still it won’t mean much
• How you can get that 100% coverage in a very cheap way (skip the asserts), and it won’t mean much (obviously)
• How you can cover code completely, and it would be a big waste, since the feature is not used by the users
• How everybody uses coverage tools, because frankly that’s the easiest thing to measure

I would say that they were amazed at my logical explanation, and finished the meeting early, promising to remove all coverage metrics from their system.

But of course, that is completely false.

Fresh out of silver bullets

“But management wants to see the coverage numbers going up”.

Of course they do. And why is that?

“Well, that’s a simple proxy for quality, isn’t it?”

I could see the disappointment in their eyes. They expected other answers. Simpler, easy to implement, expert answers.

In Cynefin language, our friends were asking for a solution for a complicated problem, but they live in a complex system. In the complicated realm, we ask an expert how to solve a problem, and the expert gives you the solution. If not, we find another expert, but the answer has to be out there, since the knowledgeable expert has seen and solved this problem a million times before.

Alas, we’re living in a complex world, where there is no “right” answer. No silver bullet for you.

In the complex domain, we need to find our own solution, the one that fits our context. Applying the expert advice as “best practice” which doesn’t take our context into consideration, is asking for trouble, and sets us up for disappointment. Trust me, it’s a nice, big disappointment, covered with lots of tears and pain. Just waiting to happen

But it can get even worse, when we ask the wrong question. Our friends asked “how do we get our coverage numbers up”. I’ve mentioned a few options during my rant, but hopefully they won’t take those suggestions too seriously.

What do we really want?

The hidden request behind “how can we increase our coverage” can be either:

1. We want better quality.
2. We want to be seen as having better quality.

And now we have to decide.

If we seek better quality, we need to work at it. The real question we should ask is “how do we improve”. Since we’re in a complex world, there are no recipes, but there are suggestions to try. Our concept of quality and improvement may differ wildly from others’, and so there may be different paths to get there.

(By the way, there is no one tool that will solve our specific problems, because tools are built to solve “everyone’s” problems. Since there are no silver bullets, we have to work at it hard – define what matters, define the metrics, track the metrics, and decide based on the findings if you’re going forward, backwards or sideways.}

If however, it’s the second goal we’re after, that’s a completely different story. We can improve our statistics in many creative ways. In fact, one of them is actually going through improvement.

But that would be too much work, right? All we need is to get management off our back so we can get back to “real work”.

There are cheaper methods to make us look like we’re improving. It just so happens, that those methods don’t align with the project’s quality goals.

No big deal, is it?

To finalize the series on stress and agile, let’s talk about what we can do to lower distress.

But who are “we”?

Leaders and managers are responsible and accountable for creating a safe work environment, that allows individuals to feel respected and motivated.

We should make it safe to discuss the messy stuff. It maybe uncomfortable, but it beats finding out when everything blows up in our face.

Individuals and interactions

We should respect, empathize and above all create safety. Safety for people to talk freely, without fearing repercussions.

Here are ways to acheive it.

• Leading by example
  Part of the safety comes when people start talking. But they won’t, unless they see what happens first to those who do, and this is where leaders come in. They show that it’s ok to talk about stress, and how it affects work and results. They show in action that safety is important to them, the organization and the work. Because it is. Leaders and managers discuss the uncomfortable things, as if they are regular, day-to-day matters, because they are. Addressing stress once a year, is not really addressing it, it is just sweeping it under the rug. We continue to discuss it, and we hammer this message on, and people would respond.

• Listening
  In a safe environment, when people start talking, leaders actively listen. This includes one-on-ones, retrospectives and even watercooler talks. When people don’t talk about the issues, leaders ask about them to get their perspective and to do something about it. People who know there’s an open ear will open up.

• Responding
  Talking is not enough. People feel distress when they feel they are not in control. Leaders need to give workers more control to solve issues by themselves. Leaders also try to help them when the issues are outside their control. Yes, some things will fall into the “it’s out of our hands” bucket, but they should be the minority.

• Intervening
  When we notice something that may compromise safety, we don’t wait. Leaders fix and pre-empt, if possible. We say out loud that some behaviors are not allowed. And if behaviours become patterns- we make sure that those behaviours are not tolerated.

• Monitoring
  We need to know how people really feel, and in our context, how they feel about work. Relationship between workers, managers and their peers are important to improve safety. This is not easy to do, because we need to make it safe for people to talk straight (closing the circle with leading by example, listening and responding).

• Educating
  As we continue to create and maintain the safe environment, we continue to explain the principles of safety and why it is important for everyone. As new people come into the team and to the organization, we make them feel safe by doing all the above.

Rinse. Repeat.

With safety we lower distress, and create an environment that encourages action, results and creativity. We improve on the organization, team and, of course, on the personal level.

So when people say that “ever since they moved to agile they are more stressed”, it’s time to take a good look at the work environment.

• Does the team work with the product owner or does whatever she says, no arguments?
• What happens if they miss their “estimation”?
• Is there continuous communication between everyone?

Agile does not create distress. It reflects it and shows how safe the environment really is.

That’s a good place to start.

Last time we talked about eustress (the good kind of stress) and distress (the bad kind). How does one turn into another? And what can we do to stay on the light side, rather than turn to the dark side?

The stress we feel is in our head. We translate how we see the environment around us, to predictions of what might happen. For example, what might happens if I don’t finish coding on time, what if I miss something while testing, and what if I don’t get the next customer.

What can we do about it?

Let’s start with the bad news. Stress is not going away. We’re all working in a business environment, which dictates deadlines and keeps an eye on results. (I know, I know, some of those are misguided and unrelated to the business goals, but they too will remain with us for a long time). Agile methods just raise the bar.

To tell the truth, in the waterfall era, what we did was really unprofessional. Hiding the actual status of our work, working on what *we* thought was best, and delayed decisions sometimes until it was too late to change back. The shroud was a stress reliever (at least until just before release).

Agile methodologies try to align the development processes with the business goals. Increased visibility helps there. Incremental releases help as well. They allow the business to confirm going forward, or change course. With extra visibility comes some stress.

Regardless on how we feel, this is mainly good for business.

Until we leave, because we’re overstressed. Then it’s not so good for the business.

We forgot something on the way to agile

One of the agile manifesto 12 principles talks about “motivated individuals”. You know, the same ones from “individuals and interactions”.

Scrum also puts motivation in the spotlight. Two of the values of scrum are “respect” and “courage”. While the other values “openness”, “commitment”, and “focus” is what we expect people to give, respect and courage is what we want to feel.

Stress is something we feel. How we deal with it lies in our hands: Our experience, maturity, relationship and skill level.

But mostly, it’s up to the managers and leaders, who set the tone by creating a safe (and sometimes unsafe) environment. With more safety, our distress goes back to eustress.

How do leaders create a safe environment? That’s in the final part of the series.

This series of posts is about stress, specifically in agile environments, where it comes from and what to do about it
Part 1	Part 2	Part 3

“Me, and everyone I know who started doing agile, are stressed”.

If you ask around, people are feeling a bit more stressed than before the big agile arrived. Why is that, and is good, bad or ugly?

Now, where is this stress coming from in agile teams?

In the good ol’ days of waterfall, life was simple. There was a release once a year, and that last release month was really stressful. It was stressful because everyone was interested in what we were doing, what the status and quality of the release was, and if it’s actually going to happen on time (spoiler – late and full of bugs).

Very stressful release month, but mind you, this stress came with a discount. Because in the preceding eleven months, we felt no stress at all. Nobody was intereseted in what we were doing, and in fact, we contributed to the fog of war by not discussing anything with each other.

Agile is completely different.

There’s a deadline every couple of weeks. There’s the pressure we feel to show we made progress. People expect this from us, and we don’t want to let them down. Within these two weeks, there’s no hiding either. Everybody knows everything about the status, and what’s the probable outcome of the sprint. Even worse, because of the short time span, and extra visibility, we actually need to make decisions in broad day light, instead of deferring them to a later more suitable time, pushing them out of view.

Recurring deadlines, increased visibility, accountability and uncomfortable decisions – all contributing to a more stressful life.

Damn stress

Didn’t some agile manifesto principle say something about sustainable pace? Instead, this stress seems like it’s working against us.

Stress makes us feel we “need to do” something, because if not, there will be consequences. And depending on how we perceive these consequences (and perception plays a big role here) we respond in kind.

There are really two categories of stress. While they are not “good” or “bad”, they split based on our response.

Eustress, is the “good” kind. It’s the one that gets us out of bed in the morning. The one that springs us to action. It’s the motivator, the energizer. When we’re making the decisions, we’re in control and those “stressors” as they are called, move us forward.

Distress, the “bad” kind, sits heavy on us, and more so. This kind of stress stifles us, demotivates us and depletes our energy. We’re more occupied with how we feel, so we either do nothing, or make mistakes due to the perceived consequences. We also feel distressed when we’re not in control. When things are handed down to us, and we need to deal with them.

When eustress turns into distress, we’re in trouble. And agile is the srtess agent.

All the deadlines, extra visibility and transparency – we didn’t ask for them. Hence we feel the distress. even more so, it’s mostly inflicted on teams without choice. And that stress is consistent, all the time. That’s not easy to live with.

Can we do something about the stress?

Does agile cause only distress?

Is ice cream the only answer?

We’ll see how to handle stress next time.

Last time we talked about the different mechanisms and practices we put in place in order to get us to working software, the main metric in agile delivery. We talked about how “working software” means not just that software is functional, it’s built to last. One of the most effective of these practices is code reviews, and we’ll start, as always, with “Why”.

Code reviews with benefits

Usually while we write code, we’re in “functional mode”, getting the code to work. We’re problem solvers, and we try to translate a design we have in our mind (or the one that we’ve reviewed with the team), into code. We’re not just typing, we’re eager to see that it’s working.

While the focus means we’re go forward, we miss out on things on the way. The things that jump at us when we look at the code a week later, and we either don’t understand what we did there, or think “I could have done it differently”. On top of that there are the things that we still miss completely. As agile people, we need feedback.

This is where the code reviews come in, and it brings some awesome benefits.

• Finding problems early

We have other people look at our code, before it gets into production, testing, or even an integrated environment. These problems we’ve missed, when we focused on “making it work”. The impact of the things we didn’t cover can range from holding back development because the build broke, to sneaking bugs into production. Having other sets of eyes on what we think works can uncover issues, and give us an opportunity to fix them before any damage is done. Agile development is about reducing risk, and early feedback does that.

• Fight complexity

Any code we write is already complex. It carries with it not just “what it does” and “how it’s written”, but also mountains of invisible assumptions, multiple dependencies, and personal preferences. Unless a miracle happens and we happen to write the code once and it’s so good it will stay like this forever, we (or someone else ) will get back in there. The more complex it is, we (or they) will have longer time understanding it, maintaining it, and our chances of inserting a bug or two increases.

Code reviews are the opportunity we have to reduce complexity. Make things simpler, readable and isolated. Understand the assumptions and make sure that “the new guy”, coming in to the code in a few weeks doesn’t miss them. And that further maintenance is less costly than rewriting the whole thing. This is another type of feedback we need in agile development, which goes under technical excelence.

• Knowledge sharing

In big projects, we are so focused on “what I write”, and forget that all the other people on the project are also thinking the same. The more people we have, the more assumptions on “how other people think” there are. These differences between how we think, and how they think cause all kinds of shenanigans. They result in longer integrations, unexpected bugs, and fun-filled post-mortems.

Spreading the knowledge of design, requirements and “how things should work”, is a great way to reduce the number of those social events. The more we do it, we’ll save ourselves the heartache involved.

Code reviews are a way to show other people (hopefully people who we integrate our code with theirs) our code. An opportunity to discuss what we were thinking when we were building it, how it solves the problem, and what is still open, or what we should be thinking about next.

Regardless if you’re a junior or a senior, and if your partner in the review is junior or senior you’ll both learn something every time you review code.

We’ll talk about how to do code reviews effectively in future posts, but here’s a spoiler: They are short and frequent, so there are multiple small opportunities to spread the knowledge. Knowledge sharing goes under the agile principles of technical excelence and sustainable pace.

• Promote collective code ownership

One of the principles of Extreme Programming is Collective Code Ownership. There’s no one person responsible for a piece of code, even if she’s the writer of that code. It also means that when she’s on holiday in the Caribbean, and there’s a production problem in that code, we don’t wait for her to return, or even worse, start pressuring her to cut her vacation short so she can come and save us. Everyone on the team should be able to step in and change the code.

We’ve already discussed knowledge sharing in general. But this benefit of code reviews goes a bit further. Encouraging other people to “step into your house” (confirming that it’s not really yours) creates an environment where people don’t protect “their” code from others. They are actually encouraged to make it habitable for other people. And when the partner says “I understand”, that means that the house is ready to be lived in. Collective code ownership is part of agile’s technical excelence principles.

• Maintain conventions

Part of the “I can live in this house”, says “I understand what’s written, and why it’s written like that”. If and when I’ll be called in, I can make changes in the code. The things that make it easier to understand and make changes are conventions.

Conventions can be stylistic, naming related, design, architecture related and more. They can be from where we put the opening braces, to deciding if inlining functions is good or bad, to how we split packages, to when we introduce a new service. They all fall into the “This is how we develop here” bucket. Conventions make our lives easy because there are fewer decisions to make, and therefore fewer things to worry about. The team conventions should always outweigh personal preferences.

There are no “best” conventions (including where to put opening braces). There are those that are good for the team. And code reviews are perfect opportunities to teach them, and enforce them. Once more pillar in agile’s technical excelence principles.

There are lots of opportunities

Code reviews as an opportunity for improvement seem to be a recurring theme. It’s not just chance, though. If we want to get those benefits we need to allot time and prioritize code reviews. More on that next.