Engineering Joy

What in the hell is engineering joy? Good question, I may not be 100 percent sure myself. Recently whilst having coffee with a good friend we got talking about work struggles. We started off with the usual, companies not realizing how to budget, and folks being put under pressure to deliver stuff customers don’t even want or need. So, we went down our usual rabbit holes of, bah nobody understands agile, nobody seems to get how software is delivered, etc.

It was then he stopped me and said what companies are lacking is Joy. Thinking back to the best places we both worked, that’s exactly what we had…Joy. We ENJOYED not just the work but the atmosphere, the fun, in Ireland we would say “the craic”. I know this might sound ridiculous, but it was in those environments where we learned the most, made the most friends, and even delivered the best work.

Why?
I think it all comes down to this, happier people produce better quality work. Big companies have figured this out, granted some have flipped it too far and nearly made it impossible to leave the place, I don’t think that’s healthy either. So, there must be a happy medium. You need to empower people not just teams.

How?
You can’t just force this. Throwing in some beer fridges and forcing mandatory fun time won’t work. If anything, this will turn people off, and make them resentful. Don’t get me wrong beer fridges are nice to have, along with free cereal in the mornings and even a free lunch day or something. But they are not real, it’s a forced fun time. It’s not any use when you are offering free lunch but forcing folks to hit nonsense deadlines and piling the pressure on after lunch.

So, engineering joy MUST start with your practices. It MUST be a top-down lead process. I have worked in places where we as a team got everything in place and were really enjoying how we were working and what we were doing only for higher level management to not realize the value, and to push back on it. This stopped the joy dead, and instead of allowing it to spread over the organization it killed it.

If you build good practices for teams, you will allow them time to learn and grow, thus enabling Joy in the workplace.

Let’s take the simple example of WIP limits. Just one small thing can generate happiness for teams. If you control the amount of work coming at a team and lower it, you get some side effects. One of them will be a higher quality output as there is less work so there is more time to make sure the work is tested properly. Another side effect is engineers have more downtime. This allows them to HAVE FUN AT WORK. Maybe they want to learn something or investigate something. They now have time for it, they can also pair and work together.

Next:
This is just one simple way we can start down the path to engineering joy. There are many others, and I will start to try and share more here. I and the friend from the start, Rob Meaney (yes he has at least one friend), are looking to collect stories and ideas and start a new drive for Engineering Joy in our communities. We look forward to hearing from you.

To reach out my twitter is: @dar_dar
Rob is contactable via twitter: @RobMeaney

We Are All Impostors

I recently started a new job. As usual with a new gig, it was and is great fun. But I knew it was coming. This time I got to the six-week mark before it kicked in. That little voice in my head that says, “Hey maybe you are crap at this, and YOU WILL BE FOUND OUT!!!”

Does anyone else suffer from this? If so, don’t worry you are NOT alone. It’s called imposter syndrome.

Imposter syndrome can be defined as a collection of feelings of inadequacy that persist despite evident success. ‘Imposters’ suffer from chronic self-doubt and a sense of intellectual fraudulence that override any feelings of success or external proof of their competence.

I think it comes from having a growth mindset. I don’t want to get caught up in buzz terms here, but I have noticed that people who keep trying to learn are more prone to imposter syndrome. I think it is because to fully learn you must be out of your comfort zone. You are in the area of I am not sure what I am doing, this is where you will make mistakes. But you NEED to make those mistakes to learn. As you are also making mistakes you can start to doubt yourself. 

So how does one combat this little doubt monster?

Honestly, I don’t have an answer. What I know has helped me is simply knowing what it is. I find if I start going down the dark road of, “I am not good enough”, taking a breather and realising this is in my head and not true has enabled me to keep going. 

I also think the best thing for this is talking. Tell folks who you work with about it, I guarantee they are feeling similar and may not even know what it is. The more we talk about it the easier it gets I have found. 

I also think not taking yourself too seriously can help here. Realising you will make mistakes and being able to laugh at them and learn from them is a big plus. 

A big win for me was discovering Paul McCartney gets it as well. One of the greatest songwriters of all time. Talking about his insecurities he said, “Just like anyone else, you have insecurities. ‘Cause everyone has them. And no matter how high and great and wonderful you get; there’s still something that will make you worry.” So, I figured if the guy who wrote yesterday still gets it, at least I am in very good company. Also, Pauls cure…KEEP BUSY!!!

Why Care About Releasing?

How often do you release software?

A lot of big projects don’t care, they scope and plan work for a big bang release in 6-8 months. Projects are seen as successful when everything is green on a spreadsheet for a 6-month end goal. Or after 6 months we release and there are only X amount of bugs, that’s seen as brilliant. But there is no way of showing if the customer is happy. Has anything changed in the 6 months?

What I have found to be the case with these projects, is that after the 6 months what we release is NOT what the customer wants, it is also buggy and usually requires extra time to “hotfix” big bugs.

So I know what you are thinking…..this is waterfall and nobody does that anymore…right??

Ok so SCRUM to the rescue. Awesome we are now breaking down massive projects into 2-3 weeks worth of work. But does any of that matter if you don’t release it? How about we don’t worry about getting X number of stories “finished” by the end of the sprint, and instead say, whatever we have ready to go in two weeks we release.

This will get rid of the stop/start sprint deadlines, and change the teams focus from worrying about finishing stories to getting work to customers.

But the big worry now is where is the value in what we are releasing? After 6 months and a big release, you don’t care about the value of the software. But if you are releasing more frequently, then you have to care.

You might find out some strange things when you release your software. Like maybe nobody likes it. Which is brilliant, you can then pivot the team, change what they are working on, and then run a new experiment to find what your customers want.

This shows us that a big project should not just be cut up into sprints. As when we do this, we don’t learn anything. What is usually asked for is a high-level estimate on when “everything” will be done for a project. So we have a spec doc for a 6-month project. It gets cut up into 2 or 3-week sprints, and then we have to have some estimation around when the whole project will be done. But what we miss here is any adaptability.

Take the problem from earlier. What if after releasing the first chunk we find out nobody likes the software? Well, we have to stop and start again, but we have already wasted time on estimating and breaking down work for the next 6 months. All that work is now no longer needed and gets binned. This is hard to do especially if you spend months working on it. Instead, we should have only the minimum amount of work ready to prove the value of the idea. So instead of having everything defined in a giant doc, maybe just take the first problem the customer has that we can unblock as a team to make the customer money.

Or on a more positive note, what if we release and realise the problem is solved. The customer is happy and we are making money, maybe everything else we planned was a waste of time. We need to realise that whatever project or idea we have is of NO VALUE until it is live. So the faster we get it in a customers hands, the faster we can learn.
Another nice feature of releasing frequently is being able to roll back quickly. So if a team releases and we find a bug? Our release process is fast so we can push out a fix very quickly. Nailing how often a team can release and rollback a problem helps get rid of the pressure to get stuff done.

If we focus on releasing frequently and then questioning the value of the release, we will start delivering software people need. Also don’t be too surprised if you notice your team asking questions like, “what is the value in doing this work?”.

DevOps….You’re Doing It Wrong

So everyone is moving to a DevOps world these days. It’s cool to say my company uses DevOps.

Do you have a DevOps team? Have you just hired someone who says they do DevOps and have formed a team? NONE of this is DevOps.

Do you have a DevOps role open currently? This is still not DevOps.

 

 

So then what is DevOps?

Well, we can all agree that integrating testing into a dev team was the right idea. No longer are there giant teams that argue all day and pass work over a virtual blame wall. Now we have testers that work alongside devs to deliver value to our customers. BUT how can we deliver that value if the teams can’t release software.

I have seen the world where a team is doing everything right. They are working together to produce value. They are visualising their work using a Kanban board, and they are even using pair techniques such as BDD to remove rework between the business, test, and dev. But the last lane on their board is, “Ready to release”.

The work piles up there forever. It then gets pushed to the “DevOps” team to fix the problem. In this case management just wanted to know how fast the team where getting work through the board. Not realising it didn’t matter if it took the team a week or a month to deliver a story, If the work was just going to sit on a test server for months waiting to be released.

This is a fall out from giant tech projects. The idea being that a spec doc is written up and a 6 month deadline is given. Once work is progressing inside that 6 months then boxes can be ticked green and everything is on time……nobody cares about actually releasing. Nobody cares about customer value.

So in the above teams case they had to wait on the DevOps team. Now the name DevOps was just used for what was basically an unintegrated ops team. This is NOT DevOps. DevOps is developers DOING ops work. It’s a collaboration between dev and ops. It’s not throwing the work over a new blame wall to the ops team and saying, look our bit is done it’s their problem now.

I was lucky enough to see Janet Gregory speak at the SoftTest conference in Dublin last year. She was kind enough to send me her slide on this which sums it up brilliantly. If you don’t know Janets work I urge you to check her out. (https://janetgregory.ca)

We can see here that it’s everyone helping. By doing the same as you probably have already done to integrate test into a team, you need to bring the ops folk along as well. Instead of having them separate why not go invite them along to your teams standup?

Also if there is pressure from the ops side as they feel there is not enough people to do all the work, what better way to fix that, than training devs or even testers on the team to be able to do the ops work.

Instead of building up backlogs for the ops team. How about assigning an ops engineer to sit with one of the agile teams. The ops person is then free to unblock the teams ready to release items. Together they can prioritise work like building a delivery pipeline so that the pesky releases can be automated.

Instead of having to waste valuable time manually deploying code to servers, these tasks can be automated to remove human error. Eventually much like what happened between dev and test a trust will be built between the ops side and the team side. Soon your team will be able to actually complete work. Instead of waiting till near the end of that 6 month deadline you can release as each story is complete. Think about the value that will deliver to the business?

If they release software that is not actually solving anybodies needs then brilliant. No need to keep working on that project. You can scrap the work that only took a few weeks to build test and deploy, instead of wasting more company time and money on delivering software nobody will use.

This is only possible if there is a collaboration between ops and dev teams.

Now there could be other blockers, what about security? Why not bring them in early as well. The sooner each department in the company realises we are all working together to deliver value, the better the software will become, thus the happier the customer will be.

As with anything I suggest starting small. Trial this on one team first. Monitor it closely to see what works and what doesn’t. Then take what works and roll it out to some more teams.

So DevOps is a team effort, and by team I mean everyone involved in the life cycle of software, not just the ops folk. Try it and let me know how you get on.

Remove the blame walls.

The Culture Of Busy

I have been reading Unlearn by Barry O’Reilly. Brilliant book, and a must read especially if you are a leader in IT.
To quote Barry, “We all love being busy. In fact, we celebrate and subtle enjoy telling our colleagues, collaborators, and competitors how busy we are. The question we don’t consider is this: What is the result of all this busy-ness?”

Are you always busy? Rushing from meeting to meeting all day?
it’s good right, cause if you are busy, then you are getting LOADS of work done yea?

WRONG.

What is happening is you are just bouncing from meeting to meeting and problem to problem not actually fixing anything. You don’t have time to try out new ideas, or worse yet THINK of new ideas. When you are this busy it is very simple to fall into the same old bad habits.

Are you getting anything done? Have you set yourself goals that you never seem to have time to get to? Or do you find yourself having to work long hours just to get the basics of your job done? I’d imagine there are loads of things that could be done to improve your current system but you just don’t have the time to even think up new solutions, let alone trial them.

Also, if you are a leader in your company are you expecting everyone to be as busy as you? If so you are wasting valuable problem-solving innovation time for your staff. Nobody has time to question why there are so many problems, or even why somebody is asking for something.

All you are doing is encouraging a culture of busy-ness, not of problem solving and fast learning.

So what can be done? Personally, I have tried personal Kanban. Just a little board beside your desk with post it. Next, In Progress, Done. Keep it small and simple. I imagine that visualising your backlog and in progress could be shocking. You may also be able to see that some of the work you are doing is a total waste of time. You will also become better at prioritising your work in progress. Focusing on what work is import and what work is just busy work and a time waste.

Now on to all those meetings. It could be time to examine the need for them. Maybe enforce a meeting policy. You can only have a meeting that has a clear agenda, there needs to be an outcome. Also, I have seen teams trial some cool ideas, only have meetings in the evenings leaving mornings free for work. Only have meetings one day a week. My favourite was only have meetings for max 45 mins. The team noticed that there was less time wasted when they forced themselves to focus on only important stuff.

What about constant reports you may ask? My manager wants all these reports, cause their managers want reports. Well what are you reporting exactly? Is it something that team is already visualising? If you have a Kanban board, start showcasing it. Instead of firing off work in progress reports just send a link to your board, or if its physical send a picture of it. Better yet invite your manager to the morning stand-up, and boom work in progress problem solved. Maybe its upcoming work, well if you have an impact map created with the team, hang it up where everyone can see it. No longer do you need meetings or emails for team work in progress catch-ups, or up next catch ups. Visualising everything is powerful.

Another thing that’s important is taking time to learn. So, plan in slack time. Maybe start by blocking an hour a day in your calendar for learning. If you are a leader this is VERY important. Make sure you are see learning. Read a book. I recommended Barry’s latest. If your team and staff seeing you trying to learn, it will encourage them to as well. You are thus creating a safe space to learn and grow. This will only help your company.

So start small, but start. Together we can remove the old school always busy office culture. Moving forward we can show that doing less but more important work is better and smarter. Also prove that continuous learning and self-improvement leads to more productive days.

I will leave you with this little YouTube video that explains why your time should not be constantly filled up.

Cooking With Kanban

A friend of mine used to be a chef, but he became a software developer. At the time he had just started on my team, and as an agile tester I used to help coach developers on testing. The idea being this was a team activity and everyone can test. The team where using WIP limits and BDD techniques to test first, and make sure all bugs found where fixed minutes later.

Now usually explaining the value in this takes some time to either new starts or to folks who are usually used to just firing work at testers and moving on. But this guy picked it right up, and LOVED the system. I had never seen someone take to the process so quickly. A lot of folks (myself included) tend to get stuck in their old ways of working. Learning is hard.

I was talking to him about it and he made me realise something. Kanban is EXACTLY how kitchens work. The goal of a kitchen is to get high quality food to the customer. Each team member whether chef or wait staff work together in a none silo’d environment to enable this to happen. This is exactly what we are trying to do as a software team.

An order comes in from the waiter, and the kitchen gets to work. They have systems in place to deal with each area. Eventually the food goes out to the customer. A wonderful example of this is in the film “The Founder”. The film focuses on how McDonalds become what it is today. A great watch, which I recommend. (Although you may end up hating the main character).

There is a scene in the film, where the owners of McDonalds explain their speedy delivery system. What they did was genius. They drew each area of the restaurant on the ground with chalk. Then got their staff to pretend to work on the various areas. By doing this they saw which area should be next to which, and how stream lining each section would best work. Cook the meat, prepare the bun, add the sauce etc etc. This is kanban in action. Visualise the process, test it to find waste, and make small changes to improve the process.

For coaches doing this is super important. Working with the team to visualise everything in your process is key, then you can start tweaking it to make it work. But also make sure nothing you try is permanent. In the McDonalds example they used chalk, as they knew they would need to make changes. It is important to be able to test your process. Make it part of your regular retro, run experiments by adding/removing lanes. Find what works for you.

So next time you are having a problem. Maybe your team is constantly fire fighting bugs, or maybe there is no way to prove value in your work. Try and think more like a restaurant. How can you work more like a chef? How can you improve your process? Give visualisation a go.

Impact Maps Are Fun

Do you work in tech and have to deal with pesky business analysts or project managers? Are you a project manager and have to deal with flakey development and testing estimates? Have you spent months working on a specification document only to spend more time arguing with everyone else? Worry not, there is an answer.

I suggest trying an impact map.

OK you may say, but I have already written a spec doc, is this not a waste of time? Well let me ask, who you are sending this spec doc to? Is it hitting the head of dev and possibly the head of test? Whats the usual plan after that? The head of dev allocates it to a dev team and they start writing code. At the same time the head of test allocates it to a test team and they start writing tests? This is the usual working way. But the main problem I have with all this, isnt really the handovers, or the time delay, or the confusion in requirements, it is, where is the customers needs in all this?

OK the argument could be that the needs are outlined in the spec doc, possibly in the inital page. But the more hands the doc goes through the more complexity gets added and the further away we are from getting the customer their needs.

So how can an impact map help?

Well the start of the impact map is the goal. The goal is a small simple outline of what the customer needs. Non techincal just a simple problem. It easily answers the question, why are we doing this? If any of the impacts or deliverables dont feed back to that goal, then are they really needed? Probably not, so why waste time developing, testing and building them?

Next we outline who the customer actually is, the user of our system. Here we may actually find out we have multiple users. That’s ok, once they all link back to our goal. Maybe the software we are building will have both internal and external uses, so we may have different requirements for each user.

This leads us nicely into part three of the impact map. The actual impacts. So what change can we make that will help our user achieve their goal? Don’t think technically here. Instead of saying “add a button to a screen that allows the user to access the next page of the app”, say “allow user to navigate the app”. This means that instead of getting bogged down in technical details, we are just outlining the problem that needs to be solved. The details can come later. If there is still a spec doc somewhere, now you can get impacts from it. You may actually realise that some of the things that where in the doc don’t tie back to the goal. Awesome, you have just removed waste.

Ok now you should have something that has a goal, a few actors and some impacts. Whats next? Well now we come up with deliverables.

This is where we can break down the impacts into smaller features or goals with customer value. The output of this could be epic stories. These can then be broken down into smaller stories. I suggest using specification by example to help break down these larger stories. Once you have smaller stories, you now have a backlog that your team can start working on.

Not only will this make sure every story you work on is adding value to your customer, it will also remove some other pesky problems with spec docs. There will be less misunderstanding over requirments, as everyone was in the impact mapping sessions and it’s visable to all. Also instead of having to deliver everything at once, you can now just focus on areas which will add the most value to customers first, then add the rest later.

So hopefully next time you either get a giant spec doc, or have to write one, you could try using an impact map instead. I have used them to great value, and hope you will as well.

Further reading on impact mapping can be found here: https://www.impactmapping.org/.

Lessons From Bob Ross

Recently my girlfriend has been watching a lot of Bob Ross. I never really knew much about him at the time. I vaguely remember him being on the TV when I was a kid, and also some references to him in shows like Family Guy. 

But I had never really watched him. Watching how he paints is incredibly calming. I was curious about his attitude to life as he uses expressions like, “We don’t make mistakes, just happy little accidents.” Or, “Talent is a pursued interest. Anything that you’re willing to practice, you can do.”

So I did a little research on him. It turns out he was in the military before paining, and used to have to shout at people all day. He decided when he left the military, he would never raise his voice again.

So years of shouting at people to do their jobs made Bob Ross become someone who people now watch to relax as he is so calm. So what can we learn from this?

Well, maybe being calm is infectious? People have actually done studies into Bob Ross and his recent fame resurgence. He has become very famous online, he was one of the most streamed artists on twitch recently. Folks have been using him to help with their anxiety. Bob realised that by being calm and helping others it would improve his own life.

Could we do this in our day to day lives? On the team you work in is it easier to blame others or try and help? Personally I would say it is much easier to blame someone else and pass along the problem. Do you ever catch yourself saying, “Thats above my pay grade,” or “thats another teams problem”.

I have definitely used that last excuse before. But it doesn’t fix anything, and it also doesn’t make me feel any better. I don’t get home from work feeling like I have done a good job.

It also doesn’t allow for collaboration in a company. So instead of quickly getting annoyed and blaming someone else. Maybe we could try Bobs approach and calmly turn the mistake into a happy little accident and use empathy to help solve the problem.

Instead of passing the problem, try and fix it by working with the other team. Maybe it’s a problem between test and dev, can we pair together and see if understanding each others view point can help? Or is it a problem between the front end team and the back end team, could we mix up the teams skills for a week and see what happens when we work together to fix the problem?

Yes, this is much easier said that done. But I think if we start small and try help others we will find our jobs to be much more rewarding.

I will leave you with some wise words from Bob Ross: “Didn’t you know you had that much power? You can move mountains. You can do anything.”

What Is A Test Coach??

Recently I have tried to move into the realm of test coaching. It’s an interesting field. Mostly cause nobody seems to have heard of the role.

I have had phone calls with recruiters looking for QA folk. They get in touch via LinkedIn mostly, and only one has ever asked me what a test coach was. I find it interesting that the people in charge of hiring QA’s don’t know what a test coach is, let alone does.

What I think most moving into the coach role do is just become a coach out of necessity. For example you are the only QA in the company, or there are not enough testers for the amount of work developers are churning out. So QA folk help teams to use collaborative techniques such as BDD and WIP limits. This of course introduces cool side effects like slack time, which testers can use to teach developers fun testing. I don’t just mean manually running through acceptance criteria or test cases (these can with help of the developers, be automated). I mean fun techniques like exploratory testing, which can be a very rewarding activity.

Once the developers understand HOW we test, they can easily sub in for an over worked QA. This then frees up the QA to get into a more coaching role. If you are the only QA in a company, or maybe one of very few over multiple teams, you can start helping other teams. Get one team working well together and testing upfront, devs testing other devs work. This means you can jump team and do it again. To me this is the role of a test coach. Someone who can teach others to test and once done, they can leave the team to work without them.

OK so what happens if your company has too many QAs? Maybe there is a tester per developer. On paper this looks AWESOME, right? But what can happen is the wall between dev and test remains, and in fact is harder to smash as developers can think it doesn’t matter how fast I get through work, there are LOADS of testers. But in reality even with more people trying to find problems, nothing beats helping to stop them from being started. So how can a coach help here? Well, the role of QA is quite quickly becoming, automation engineer. Which is cool, but in my opinion if you are writing code, you are a developer! A coach can enable automation engineers to become developers. They can do this using the above techniques and encouraging pairing.

I don’t understand the point of having some folk writing test code, and others writing production code. Surely coding is coding, and if paired up with devs, testers can become devs quite quickly. So now we have not just a multifunctional team, but multifunctional people.

Doing this you may hear something to this effect, “testers and developers are DIFFERENT people, they THINK different, testers will NEVER be able to code, and developers will NEVER want to test”. I believe this to be totally untrue.

In fact most software testers have a computer science degree and did not have a clue what a QA was until one day they got a job as one. When you do hear something like that, just ask to trial paring for a few weeks, and see if the team learn anything. What I have found enabling pairing, is a happier team. Yes, you get greater quality, but you also get testers who thrive as developers, and stop feeling like second class citizens to the teams developers.

Once you have coached your way through the teams, what next? You can start looking for waste in other places. Maybe security reviews are taking too long, or releases are difficult. Can you as a test coach help there? Of course you can.

This is what test coaching means to me, but it seems to be quite a new concept in terms of companies. What does it mean to you? How can we help more companies to see the value of a coach, and not just a box ticking QA?

Where To Start Part 3: Team Evolution

Part three of my where to start with BDD post. The first two parts can be viewed here:
https://thoughtsontest.wordpress.com/2017/03/22/where-to-start/
https://thoughtsontest.wordpress.com/2017/07/04/where-to-start-part-2/

So at this point your team has started using WIP limits and BDD.
Does your team now have a surplus of one role, maybe there are 2 or 3 testers who are not covered in you WIP limits as they are not developers.
Maybe its time to evolve a little and try blur some of the roles, or how about experimenting with your WIP limits?

Let’s talk through these two ideas.

In an earlier blog I talked about having WIP limits set to the number of developers in the team. So when a story is in test the developer is in slack time.

This is where we can start blurring the roles a little bit. Personally I like to invite the developer to test along with me. If our examples have already been automated then we don’t have to worry about testing them. Now we get to do some fun creative exploratory testing, this is great as a paired activity. Once developers see how you are thinking, they can then start doing it themselves.

For exploratory testing I tend to think of the least technical person I know and pretend to be them using the system. This is my dad (sorry dad). He has managed to find the most interesting bugs and get the best viruses over the years, and his answer is always the best for a tester, “Ohh yea I clicked on that cause I could”. If your system has a flaw no matter how small or silly you think it is, a user WILL FIND IT.

But pairing works both ways. After the 3 amigos session when a tester is in slack time, why not pair up with the developers. You could start doing a joint TDD exercise. The tester writes the tests and the developer writes the code to make the tests pass.

Eventually you could swap that up completely and have the developer write the tests and the tester write the code. You will have a true multi-functional team, where everyone can do everything.

So how does experimenting with your WIP limit work?

Well how about decreasing it. So if you have 4 developers, make the WIP limit 3. This frees up a developer to help the team. This means someone is always free to jump on code reviews, or to do some of that tech debt you can never find the time to get to. You can swap up that developer each story. It also encourages more pairing, as two developers can work together on a story.

There are loads of different things to try, use retros to see how they are working. Just don’t make too many changes at once, it will be hard to know what worked and what didn’t. (I’ve made this mistake before)

If you have any suggestions, or have run some experiments on your teams let me know.

Just make sure your team keeps evolving by trying new things. To quote Eddie Vedder, “It’s evolution, baby…Do the evolution”