Surface Acting: bad for business and your health

Angry Twins by Pelle Sten (http://www.flickr.com/photos/pellesten/8286639449/)

Angry Twins by Pelle Sten

Have you ever been in any kind of meeting that made you angry, sad, excited, disappointed or frustrated? Sure you have (if not, I want to work with you!) and you’ve also probably tried, on occasion, to mask that emotion. If you’re British, there’s the idea of the stiff-upper-lip and there’s probably similar in other cultures. However, this is bad for your long term emotional balance.

‘Surface Acting’ is a means of managing ones emotions. This technique allows you to pick the right emotion for whatever situation you are currently in. We do it in all kinds of situations; doctors, waiting staff, the police. Any situation where we’re unable to generate any kind of sincere empathy means we resort to acting the correct emotion.

A recent study highlights that we even do this in meetings. The study claims that 15% of of personnel budget is spent on meetings, yet up to a third of all meetings are a waste. They make links between surface acting and the perceived effectiveness of the meeting. Because an attendee is expending energy on portraying an emotion they might not be feeling, that’s energy that isn’t being spent on the purpose and outcome of the meeting. It requires self-control and limits our ability to attend to what is going on, as part of your attention is turned to acting.

It’s also exhausting. Those who reported high levels of surface acting, when quizzed three months later, exhibited higher emotional exhaustion, or burnout, scores and an increased intention of quitting altogether!

So, next time, you feel an emotion, let it out. Be truthful with the way you feel about the world around you. Be mindful that you’re not being a dick and ensure you’re meeting the needs of the people around you, but don’t mask emotions. It’s unhealthy and, usually, untruthful. I’ve blogged about lying before, so this study further supports the idea that politicking around the office is not only bad for business, but also bad for your health.

——

Shanock, L. R., Allen, J. A., Dunn, A. M., Baran, B. E., Scott, C. W. and Rogelberg, S. G. (2013), Less acting, more doing: How surface acting relates to perceived meeting effectiveness and other employee outcomes. Journal of Occupational and Organizational Psychology, 86: 457–476. doi: 10.1111/joop.12037

Are you intelligent? Do you do intelligence?

Well, are you? Are you intelligent? Or perhaps you do intelligence. Do you? You do? No.

No, you don’t do intelligence just as you don’t do clever and you certainly don’t do agile|Agile|aGiLe.

I read this article today Kanban Is Not Agile and I’ve read a few others like it in the past. No, Kanban isn’t agile. But neither is scrum or DSDM, or crystal or SAFe or whatever.

You cannot DO principles and values, you are principled and you hold values. When someone says “We’re agile!” challenge them, ask “What does that mean?” because I can almost guarantee they’ll say “We do scrum|kanban!”. You’re following practices that stem from upholding the values and principles of the manifest, but you’re not doing agile.

What’s more and what will hold business back until they realise it, is that while these values and principles are software-centric, they certainly aren’t software dependent. If you distil the values and principles, you get things that any one can uphold, regardless of industry.

You don’t DO agile, you ARE agile.

Is it feedback, or signoff?

Keyboard Jumble by Lynn Friedman

Grubby sign off. Photo by lynnfriedman at Flickr

Many groups suffer from having too many levels of sign off: designers seek sign off on UI changes from the head of their department and, potentially, the studio manager. This is after UX have sought sign off from their functional head. After that, we need stakeholder sign off, product owner sign off, marketing, brand and communications sign off (to ensure the message is correct) and who knows who else will need to have a say?

“With all this signing off going on, how will we ever get the damn thing launched!?” said the frustrated team members.

Perhaps you’re conflating “sign off” with “feedback”. Ultimately, there is usually only one or two people who are accountable for the success or failure of the thing you’re working on. Pragmatically speaking, this would be the product owner. For the sake of argument, we can also extend this to key stakeholders too. It’s these people that give “sign off” on whether something is ready or not.

Everyone else is just giving feedback, which can be taken on board, or ignored, as the product owner and key stakeholders see fit. If it’s a decision between pixel perfect designs and getting it in front of customers, let the PO decide. If you’re one of these functional heads and you’ve employed people whose work you need to “sign off” before it sees the light of day, perhaps you’ve employed the wrong people?

As Roy Castle sang, “Delegations what you need.” (He didn’t, he sang “Dedication…” but, whatever). If you’re building websites, your mistake won’t be live long. The more time you spend in the cycle of sign off, the less time you spend with your product creating value for your users.

Sorry, It’s Company Policy.

Possibly the most frustrating, emotionally bankrupt and redundant four words you’ll ever hear in the workplace.

I recently had the displeasure of hearing these words. Not, thankfully, said to me however. What made the whole situation worse was the person who uttered this charming sentence had allowed the policy to be bent only the day before.

“Policy” as described by the OED is:

a course or principle of action adopted or proposed by an organization or individual

“Policy” as described by most companies is:

a rule which we can use to bash you over the head in order that you do our bidding.

Policies are usually created as a sledge-hammer answer to a walnut sized problem. In the past, someone (or many someones) have done something which was bad for the company (or, another company) and this has resulted in their being a policy.

As a general rule, humans work for, or with you. As we all know, each human is a unique a beautiful snow flake. Trying to apply a “policy” to govern the actions of behaviours of your workforce as a whole is pointless and demeaning. Take the time to understand the people who work with you instead of putting your fingers in your ears and going “lalalalcompanypolicylalala”.

The only policy you should have is one of common sense and decency. Treat your staff like the people that they are, not the resources that Taylorism would have them be.

“OH HAI, THE 1950s CALLED, THEY WANT THEIR IDEAS ABOUT HOW TO WORK BACK”

(Also, beginning the statement with “sorry” is also disingenuous – if you really were sorry, you wouldn’t have to say it in the first place…)

Does It Need to Be Said? Don’t Lie.

I recently watched Liz Keoghs “Let’s be honest…” YouTube that she did at the goto; conference. It was a fun and engaging talk, but I was frustrated and, frankly, surprised that there are companies or individuals that need to be told don’t lie. She used examples from previous positions to illustrate her many points, but there were two that stuck out for me (well, most of the points were salient, but these were the two that had the most impact on me).

The first was her statement that we’re no longer finding better ways to build software, we already know how to build software, we’re finding better ways to discover. Liz had the sentence from the agile manifesto on screen when she said this. Now, while I’m still not entirely convinced that a nearly 12 year old document is as valid now as it was when it was written, I believe that, if any of it is true, then that be is – we’re still finding ways to build better software. The constant evolution of our industry is testament to that. Don’t get me wrong, we’re much better at it now than we’ve ever been, but it would be arrogant to announce that we’ve reached the pinnacle of software development. Even if you’re a super-duper, high perfoming, cross-functional team, if you stop trying to improve, you’ll rot from the inside out.

This doesn’t mean that the rest of Liz’s statement is wrong, we’re also finding better ways to discover what our software should do, the fact that BDD is now more popular than ever means we’re trying harder to find out more about our products, not just how we build them.

The other thing Liz said in her talk was about user stories and how, we’re lying if they’re not actual stories for the user. Gojko said the same thing in his angry Monday blog post and it got me to thinking. Gojkos was a better example in that “As a user, I want to register, so I can use the site.” is probably a lie – no user ever wants to registers, it’s a necessary evil we perpetrate over and over again in order to provide some persistence for the users’ experience – however, we have the story because we think we should. It might be better phrased as “As marketing, I want the user to register, so I can send them email” or similar (Gokjo has other examples).

But, for me this misses the point. The stories are a catalyst for conversation, what they actually say should really be irrelevant. They could say “Login” and just a a placeholder. This will force the people involved to talk about what that means and how they should build it. It’s this conversation that needs the to be focussed and honest, not the story card. It also needs people to think differently about how they go about the discovery process and this, for me at least, is key to what both Liz and Gojko are saying.

I believe that, for the most part, we lie without knowing we’re lying (is that even lying?). We make verbal assertions about thing X to move us passed that to get to thing Y. The danger then, is that you don’t revisit thing X to work out whether or not your assumption was correct. Do the quickest, most expeditious thing to move you from nothing to something in order to find out if you were right, if you spend too long worrying about whether your story card says the right thing you’re going to miss out. After all, it’s all about the users, get it in front of them and let them tell if you’re lying.

Finally, I believe in starting from a position of trust, this means that I cannot entertain the idea that people are lying until it’s proven they are. The people around me (and, hopefully, you) don’t lie. They’re professionals and adults and shouldn’t lie. If we ever find ourselves in a position where we have to point this fact out at a conference, we’ve got much bigger, darker problems than what we write on story cards.

Is Legacy Code Actually Technical Debt?

Technical debt can come in many forms, but is your legacy codebase really technical debt? If you make decisions based on the knowledge you have at the time, can the problems these decisions cause later (either weeks, months or years later) be called technical debt? I don’t believe so. If we’re going to use the analogy of taking on a financial burden, then you wouldn’t be able to take on a financial debt without knowing about it and, if you somehow did manage to do that – would you even be responsible for the debt (if we think about how those who took on a credit card with PPI are now claiming all that money back)?

There is plenty of discussion about what technical debt it on the internet. For example,Wikipedia sez:

Technical debt (also known as design debt or code debt) is a neologistic metaphor referring to the eventual consequences of poor or evolving software architecture and software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete. As a change is started on a codebase, there is often the need to make other coordinated changes at the same time in other parts of the codebase or documentation. The other required, but uncompleted changes, are considered debt that must be paid at some point in the future.

Martin Fowler describes it as:

 In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice.

My question is then, if you write code, or architect an app to the best of your ability, with the best code you can – no cutting corners, or missing tests – is it technical debt when you come back to the code months (or years) later, and it requires huge refactoring because it’s out of date?

I would suggest that no, it isn’t.

If it’s part of your system that hasn’t required work since you wrote it, then it’s simply legacy code. Technical debt is smelly code that you create deliberately. That is, you need to cut corners, or hack stuff, to get your code out of the door quickly. If you know you’re not writing the best code or architecting your application correctly, but you do it anyway, that is technical debt.

Accruing Interest

The thing about technical debt, like real debt, is that over time, intrest accrues. Let’s say that on day one, you deliberately create some smelly code in order to get something deployed quickly. You decide to fix it the following week. A week later, it takes you two days to write the code correctly.

Let’s say, however, that you couldn’t fix it a week later – something more important came up – instead, you could only fix it a month later. Now, because the codebase has moved on – other devs have committed code, you’ve committed code etc etc – what would have taken you two days to fix a week after you wrote it, might now take you five days to fix (assuming that for every week, the code gets complex enough to add another day to fix it). This means, your interest on this technical debt is roughly one day a week. So, if you leave technical debt for months, it’ll take much, much longer to fix and, depending on your position, every new dev you add to your team will compound that interest, until it spirals out of control and you end up declaring bankruptcy and re-writing the codebase from scratch.

Sound familiar? Might as well do it properly the first time round…

BDD: Starting With Quality

By Shannon Kringen @ flickr

Quality with a star and stuff

Quality isn’t defined by a lack of defects or bugs. You wouldn’t get a cup of barista coffee and exclaim, “This coffee is quality because it doesn’t have a problem with it.” (No bugs in my coffee). You can get a cup of coffee from a petrol station that doesn’t have any problems with it. It’ll be hot, wet and coffee flavoured – there are no defects with this coffee. So, where does this idea of the “quality” of something come from? It’s a subjective thing. A quality cup of coffee to me may not be the same quality cup of coffee to you. If you favour a black americano, your definition of quality is not going to involve a milky heart drawn into the top of it, which is how I like my coffee.

When we talk about the quality of a feature, the fact that it doesn’t have any defects is an implicit part of that quality, but it’s not where quality starts or stops. What makes the quality of a feature is whether or not it does what it’s supposed to do and whether it provides the amount of value to the user that they expect. Again, this is different depending on your context: what you application does, who it does it for and why.

Quality Assurance (QA) plays a fairly key role in any software development team. I know some schools of thought suggest that there shouldn’t be a QA role, and while this is probably the subject of a separate blog post, I feel that this is wrong. We have a QA in the team, just the same as we have a designer in the team. It’s a specialist role that requires certain skills I don’t expect engineers to necessarily have.

That said, I’ve always been troubled with the way that the QA role is executed in a team. Let’s suppose that we’ve got a scrum team that performs well. They commit to a given number of independent stories, work on them sequentially, so they finish the first story before starting the second and so on. Once the feature has been completed, the work of the QA starts in earnest (until that point, the QA will put together a test execution plan and a strategy for dealing with the tests during the sprint). They will begin exploratory testing and creating or updating automated tests. This is all well and good and will ensure that the feature meets the minimum, implied, level of quality. In most cases, it’s enough that it’s free of defects.

For me, this is where the problem lies. But how do we solve the problem?

We realised that actually, we never really discussed what quality meant to a particular story or sprint. We had made assumptions about the quality based on the content of the story and the acceptance criteria. As long as the story met those acceptance criteria and didn’t have any defects, we assumed we were done. In reality, we weren’t really thinking about what constitutes quality but just what constitutes the feature.

So we decided to start with quality. It made sense to talk about what we thought quality meant to any particular story before we talked about anything else. At the beginning of planning a story in sprint planning, we would spend some time discussing what quality meant to this feature. Using the example of a login screen, the story might be:

  • As a user,
  • I need to log in to the site,
  • to access all the features.

Before we chose to start with quality, we might discuss what the feature looked like, or we may already have a design for it. But then we’d just jump straight into the technical planning: how do we implement it, what code do we need, database schemas – that kind of thing. Instead, now we talk about the feature from a users’ point of view:

  • What happens if they get their password wrong?
  • How do they reset their password?
  • How long should the password be? Should it have characters?
  • What happens if a user doesn’t have an account, how should we direct them to sign up?
  • What kind of error messages do we want to show?
  • Etc.

This opened up a whole new discovery phase. Product Owners cannot think of everything when writing stories and this discovery allowed us to offer our insight into how the feature works, ask questions about how it should work and these are often based on technical knowledge of the platform that the Product Owner may not have. We began by adding these new requirements to the conditions of satisfaction, but they soon become long and arduous to check. So we looked for a better solution than acceptance criteria.

The solution we chose was to use a new tool. BDD (Behaviour Driven Development) is a method of functional testing which allows you to describe the functionality of a feature in a “scenario” file in plain english:

  • Given I am on the login page
    • When I enter ‘mikepearce’ into the username field
    • And I enter ‘butteryballs’ into the password field
    • And I click “login”
    • Then I should see my dashboard.

We can then use a BDD framework to run these scenarios against our web application. We use Behat as a framework and it works really well (apart from our problem of data fixtures…). It pretends it’s a browser (and, will use Firefox if it needs to work with javascript) and does what your user would do with your system. This allows us to have automated functional testing too. Awesome.

So, when we’re doing this extra discovery step, we record our findings as these step definitions, instead of acceptance criteria:

  • Given I am on the login page
    • When I enter ‘mikepearce’ into the username field
    • And I enter ‘wrongpassword’ into the password field
    • Then I should see the message ‘Sorry, your password is wrong’
    • And I should see the link ‘Did you forget your password?’

We slowly build up a specification file for this feature, which is mostly centred around the “happy path” and add edge cases or problem scenarios if we think of them. It’s important to note that we don’t expect to think of EVERYTHING in this session as we time box it to ten minutes and expect other features or ideas to emerge during the sprint.

Once we’ve finished, we’ve got a specification file that we can run against the web app with Behat. The first time we run it, it will fail, because the feature isn’t there – but this is good! This is Test Driven Development for the masses! As the team slowly builds the feature and keeps running the Behat tests against it, it will slowly become more and more green. If new things emerge during the sprint, we add extra steps to the scenario file. By the end of the sprint, all Behat tests will be green and we can have confidence that, not only is the feature defect-free, but it also does what the user expects it to and provides them value.

So, now we have a way of assuring that our software has quality. Not only do we have a slick set of automated functional tests, but we’ve also added a low-friction, low effort step of discovery that allows us to really understand AND define what quality means to us in the context of this feature for our product.

I’d encourage you to try this in your teams. Actually having Behat (or any other BDD framework) isn’t really a requirement to get started. You can start by just writing your scenario file as the first step of your team planning a story and storing it somewhere for future reference. The value is in the discussion you have to define the quality. The artefact you create is useful afterwards for checking that you meet those requirements. The added benefit is that it’s written in a language that anyone can read – from your team and product owner, to stakeholders and anyone else in the business who is interested to learn more about your product.

(The benefits of using BDD are outside the scope of this article for more than I’ve described, there are plenty of articles on the web to suit your style, language and infastructure and I would encourage you to learn more about it. Start with this presentation from Gojko Adzic and this from Dan North)