Blog

Improve Your Culture with These Team Lunch Tips from 20 Startups

The importance of eating together has long been recognized in positive child development and strengthening family bonds. Eating together is a great equalizer and it can be a good way to help form better and more valuable relationships amongst teams of co-workers too.

I would encourage the companies to have rows of long tables. Having round tables means that when looking for a place to sit, you have to pick a group of people. But with long ones you just go and sit at the end of the row. You end up speaking to different people every day, helping to avoid cliques. It’s good for new hires too – they don’t have to sit alone or force themselves upon an unfamiliar group.

Like StumbleUpon, AirBnB, Eventbrite and others, you may have the lunch catered. It would be served up at the same time every day so everyone knows when there will be people around to go eat with. For the foodies amongst you, the employees would be sharing photos of some of the tasty dishes on company Facebook page.

team_lunches-1024x258
Others, like MemSQL and Softwire have hired in their own chefs. And of course, there are the likes of Facebook, with their own on-site Pizza place, Burger bar and Patisserie, and Fab, who have their Meatball Shop and Dinosaur Bar-B-Que.

It Doesn’t Need to be Expensive

It doesn’t need to be expensive though – you don’t have to provide the food, people can bring their own lunch. The important part is the set time and place to eat together. Make them optional, so that people don’t feel obligated and can get on with critical work if need be.

If space is a problem, then eat out. A group at Chartio for example, eat together at a different place in San Francisco every day.

Can’t do it every day? No problem. Take Huddle, they have a team lunch once a week. FreeAgent do too and they keep things interesting by picking a different cuisine from around the world each time.

Stay Productive

TaskRabbit, Softwire and Bit.ly have their ‘Lunch and Learn’ sessions. One team member presents on a particular topic of interest, whilst the rest munch away. Twilio use their team lunches for onboarding new hires, who demo a creation using their API to colleagues in their first week.

Small Groups or the Whole Team

It doesn’t have to be the whole team either. Warby Parker, for example, has a weekly “lunch roulette,” where two groups of team members go out and share a meal. HubSpot allows any employee “to take someone out for a meal that they feel they can learn from”.

Get Creative!

There are many creative ideas, too. Shoptiques provides lunch with its Book Club, LinkedIn gets in food trucks every Friday, and GoodbyeCrutches have themed lunches – “Jimmy
Buffet Day, Smurf Day, and Pirate Day” being amongst their favorites.

No Excuses

You don’t even need to be in the same country! Crossover holds virtual team lunches where its employees from the US, Russia, Brazil, Romania, Turkey, Uruguay and India gather together and eat whilst in a Zoom meeting room.

So there you go, there’s no excuse to have another sad lunch, sat alone at your desk reading some random blog post…

How have you improved team culture at your workplace? Tweet your tips to @fogbugzteam and we’ll re-tweet the best ones.

 

7 Ways to Get More Out of Beta Testing

The weird and wonderful bugs that get thrown up when real users first start using your code never ceases to amaze. There’s always some odd edge case that had been overlooked, despite you think about little else for several weeks. We’ve been through this many times and concluded that beta testing is the solution to our problems.

Here are 7 things you can do to get the most out of our your beta tests:

  1. Ask for a commitment to provide feedback:

Response rates will be higher if you ask your beta testers upfront to commit for providing feedback. This doesn’t have to be formal, it could be just a part of an application form. But having agreed to it, people are more likely to follow through.

  1. Do not release with known bugs:

Most beta testers will only provide feedback once so you don’t want to burn any tester to just hear about known issues.

  1. Allow enough time:

Use the following as a rough guide. For a major development effort, say about a year’s work, you’d want to spare 10-12 weeks for beta testing. Decrease as necessary – so if it took a month to develop, then, around a week will suffice.

  1. Be feature complete:

Only beta test when your feature complete. Adding in things as you go sets you back to the start. Otherwise, it just means the new code and its impact on existing functionality isn’t as well tested as the rest. Something you’ll regret later.

  1. Make it easy to get in touch:

You want to make it as easy as possible for your beta testers to provide feedback. Give them direct emails and offer to jump on a Hangout/Skype if they’d prefer.

  1. Follow up but don’t annoy:

While your product might be front and center for you, it’s not going to be that way for your beta testers. You’ll want to remind them along the way. However, don’t overdo it, they’re helping you out so you don’t want to annoy them with too many emails.

  1. Don’t forget to provide feedback:

Make sure to send them updates during and after the tests about how you are putting their feedback to use. People like to know that their time wasn’t wasted. And don’t be tight with the swag – a free t-shirt can do wonders!

 

9 Effective Code Review Tips

9 Code Review Tips

For everyone:

  • Review the right things, let tools do the rest

You don’t need to argue over code style and formatting issues. There are plenty of tools which can consistently highlight those matters. Ensuring that the code is correct, understandable and maintainable is what’s important. Sure, style and formatting form part of that but you should let the tool be the one to point out those things.

  • Everyone should code review

Some people are better at it than others. The more experienced may well spot more bugs, and that’s important. But what’s more crucial is maintaining a positive attitude to code review in general and that means avoiding any ‘Us vs. Them’ attitude or making code review burdensome for someone.

  • Review all code

No code is too short or too simple. If you review everything, then, nothing gets missed. What’s more, that makes it a part of the process, a habit and not an afterthought.

  • Adopt a positive attitude

This is just as important for reviewers as well as submitters. Code reviews are not the time to get all alpha and exert your coding prowess. Nor do you need to get defensive. Go into it with a positive attitude of constructive criticism and you can build trust around the process.

For reviewers:

  • Code review often and for short sessions

The effectiveness of your reviews decreases after about an hour. So putting off reviews and doing them in one almighty session doesn’t help anybody. Set aside time throughout the day including breaks not to disrupt your own flow and help form a habit. Your colleagues will thank you for it. Waiting can be frustrating and they can resolve issues quicker whilst the code is still fresh in their heads.

  • It’s OK to say “It’s all good”

Don’t get picky, you don’t have to find an issue in every review.

  • Use a checklist

Code review checklists ensure consistency – they make sure everyone is covering what’s important and avoid common mistakes.

For submitters:

  • Keep the code short

Beyond 200 lines, the effectiveness of a review drops significantly. By the time you’re at more than 400, they become almost pointless.

  • Provide context

Link to any related tickets or the spec. There are code review tools that can help with that. Provide short but useful commit messages and plenty of comments throughout your code. It’ll help the reviewer and you’ll get fewer issues coming back.

9 Integration Testing Do’s and Don’ts

Integration tests check whether your application works and presents properly to a customer. They seek to verify your performance, reliability and of course, functional requirements. Integration tests should be run against any of your developer, staging and production environments at any time.

Writing good tests proving your solution works can be challenging. Ensuring these tests to perform the intended actions and to exhibit the expected outcomes requires careful thinking. You should consider what you are testing and how to prove it works – both now and in the future. To help you create tests that work and are maintainable, here are 9 Do’s and 9 Don’ts to contemplate:

When Creating Integration Tests Do…

1. Consider the cost vs. benefit of each test

Should this be a unit test? How much time will it save to write this test over a manual test? Is it run often? If a test takes 30 seconds to run manually every few weeks, taking 12 hours to automate it may not be the best use of resources.

2. Use intention revealing test names

You should be able to figure out or at least get an idea of what a test is doing from the name.

3. Use your public API as much as possible

Otherwise, it’s just more endpoints and calls to maintain when application changes are made.

4. Create a new API when one isn’t available

Rather than relying on one of the Don’ts

5. Use the same UI as your customers

Or you might miss visual issues that your customers wouldn’t.

6. Use command line parameters for values that will change when tests are re-run

Some examples include items like site name, username, password etc.

7. Test using all the same steps your customers will perform

The closer your tests are to the real thing, the more valuable they’ll become.

8. Switch your system under test back to the original state

Or at least as close to it as you can. If you create a lot of things, try to delete them all.

9. Listen to your customers and support team

They will find ways to use your systems that you will never expect. Use this to your advantage in creating real-world beta tests.

When Creating Integration Tests Don’t…

1. Write an integration test when a unit test suffices

It’ll be extra effort for no benefit.

2. Use anything that a customer cannot use

Databases, web servers, system configurations are all off limits. If your customer can’t touch it, your tests have no business touching it either.

3. Access any part of the system directly

Shortcuts just reduce the quality of your tests.

4. Use constants in the body of your tests

If you must use constants, put them in a block at the top of your test file or a configuration file. There is nothing worse than having to search through all your source files because you changed a price from $199.95 to $199.99.

5. Create an internal-only API

Unless necessary for security or administration.

6. Create an internal only UI

You’re supposed to test what the customer will see after all.

7. Make your test too complex

No matter how brilliant your test is, keep it simple. Complexity just breaks later. If you are finding it hard to write, it will be hard to maintain too.

8. Test more than one thing

Stick to what you need to test. If you try to do too much in one test, it will just get more complex and more fragile.

9. Leave the test system in a bad/unknown state

This means a broken or unusable site, database or UI.

 

A Guide to Open-Sourcing Your Project at Work

Congratulations! You’ve written something at work that is amazing and you want to share it with the world! This guide covers three key areas that you should consider before making the leap: Why, when and how to do it.

Why Should I Open-Source My Work Project?

Open-sourcing your project at work can be a great idea. It can:

Help you build a developer-friendly brand

  • From those with a developer-focused product, like Stripe and Twilio, to those with APIs, like Facebook, Google and Square. Open-sourcing your code can be a good way to build your company’s relationship with developers.

Allow you to give back to the community

  • Just think of all the libraries and software you use on a daily basis that make use of open-source code. Adding your own is a good way of paying it forward so that others can benefit from your contribution. We’ve open sourced a number of libraries and even whole products.

Help you to recruit

  • Take Yahoo and LinkedIn for example. They’ve found that through their commitment to Open-Source projects (like Hadoop and Kafka), that they’ve been able to encourage developers to join them who otherwise might not have.

Gain more contributors than your project ever would have in-house

  • Like for example Square’s Dagger, a dependency injector for Android and Java. Having released it, many developers are contributing to it, including those at Google. In fact, Google developers have been contributing more than Square’s developers do themselves.

When Should I Open-Source My Work Project?

There are two conditions that you would want to meet before open-sourcing your project. You want to make sure that:

It won’t hurt your business

  • It may be an impressive, complicated bit of code that would be useful for other products beyond your own. Yet if that development is your secret sauce, then giving it away would be bad for the business. Likewise, if your library is an integral part of what makes your product unique or even what makes it possible, then you might want to keep it in-house.

Your code is helpful to others

  • Consider whether anyone else would actually want what you’ve created. Is it so uniquely tied to your workflow or infrastructure that it wouldn’t be useful for others? As a rule of thumb: if making it suitable for general consumption would make it less useful for yourself, then it’s probably not worth the effort.

Ok, so you’ve met those two requirements. Then let’s move to the mechanics of open-sourcing some code.

How Do I Open-Source My Work Project?

Step 1: Audit your code for security leaks

  • Chances are higher than you might like to admit that you or a colleague have left some passwords, usernames, IP addresses, machine names, personal contact information or other security hazards somewhere in your code. Keep in mind that this applies not only to your final master code but also to all the changesets you’ve had in the past.

For that reason, we recommend you do two things:

1. Make a brand-new repository
    • Chop off all the history of the code up to that point. There will be a new history and it saves you having to audit all the historical versions of your code. Plus, no one needs to know that it took you two weeks to wrap your head around C++11 lambda syntax.
2. Audit the code for security problems
    • This will take a lot less time than you think. Look especially at test suites and any places that are near connection points to other systems.

Step 2: Strip your code of profanity and immature pot-shots

  • While you’re in there, also rip out anything inappropriate that makes you sound more like a teenager than a professional. This doesn’t mean you can’t have any humor in your source code. But it does mean that jokes made at the expense of your competitor, a customer or the decrepit browser you’re forced to support might not be appropriate.
  • If in doubt, think about whether you’d feel comfortable reading your code loud to those beyond your team.

Step 3: Make sure your code adheres to best-practice naming and formatting

  • You’ll want your open-source code to be examples of your best work. Make sure you are using good, standardized naming conventions and formatting. Use tools like pyflakes/pep8, jslint, gofmt, ReSharper and others to help.
  • Also, keep in mind that if you’ve been wanting to do the One True Naming Standardization for your project, now’s a good time. Once you open-source your code, there will be a lot of inertia to avoid breaking changes. Get those done before you release. It’ll also make it easier for other contributors to get started with your code.

Step 4: Document it

  • You don’t have to write ninety pages of info docs but you should at least have a nice Markdown-formatted README.md in your root directory that explains what your software is, how to use it, and (if applicable) how to build it.
  • If you’re releasing a library, you should also make sure your code has docstrings/JavaDoc/whatever so that you can generate API documentation.

Step 5: License your code

  • You may want to get some proper legal advice on this. But before releasing your code, you should pick a license. Unless you have a compelling reason to do otherwise, the MIT license will probably suffice. It’s short, sweet, well-understood, liberal and makes integrating third-party changes back into your own products headache-free. But if you’re contributing to the code that you want to include in a project that already has its own license, you might want to use that license instead. Here’s a useful overview of license types for more info.
  • You’ll want to put a LICENSE file in your repository and have a copyright notice somewhere prominent — either in that file or in the README. Such as ‘(C) 20XX Your Name. All rights reserved.’

Step 6: Name your library or tool

  • Pick a name. Make sure it’s not offensive and avoids having the same name with other existing libraries and trademarked products.

Step 7: Push your code

  • Put it on GitHub, create your own organization, repository and push your code.
  • Keep in mind that some communities have secondary systems that you should consider utilizing as well. If you’re writing .NET, then another one might be Codeplex. If it’s Ubuntu-specific then a Bazaar mirror on Launchpad etc.

Step 8: Publish your package in the appropriate package archive

  • If you’re publishing a library, submit it to the appropriate package manager. For .NET, that would be NuGet; for Python, it’s PyPI; for Perl, it’s CPAN; for Ruby, it’s RubyGems; for Node, it’s NPM; and so on. Also, make sure that someone else at your company, such as a sysadmin, has the ability to continue maintaining the library under the unfortunate circumstance that you get hit by a bus.

Step 9: Announce your code

  • You’re all good, time to announce it! You’ll want to blog and tweet it out. You should also consider publishing on /programming on Reddit and Hacker News etc.

And that’s it! You’re all done!

…well, nearly.

Step 10: Don’t forget about your code

  • Just because you’ve published it doesn’t mean you’re done. You’ve unleashed a new-born into the world; you need to take care of it. Monitor pull requests and bug reports on your new project. If you realize that keeping your project going is overwhelming, then a hearty congratulations! You should remember that it is your responsibility to at least find an extra or substitute maintainer. It’s okay if your project ultimately forks but it’s best not to do so just because you dropped the ball incorporating freely and submitted improvements to your code.

That’s it. For real this time. So go out, contribute, and have fun!

 

How to Organize a Hackathon?

So you want to run your own Hackathon? Great! Hackathons are a good way to meet and exchange ideas with fellow developers and creative team. They provide attendees with a boot camp style of learning and making something in just a few hours or days. They also push people out of their comfort zones so it can be a great method of getting people to work on different projects or with new technologies and programming languages. However, these events take a significant amount of planning and preparation in order to be successful. We’ve run many similar events for developers over the years and here are our tips for organizing your own Hackathon:

Pick An Inspiring Theme

There are plenty of events for developers. Pick an interesting theme for your Hackathon to help your event stand out and improve attendance.

It could be a community event based around a specific language or tool. A corporate event for an API or product. Perhaps an internal event to encourage innovation (Facebook’s Like button was first demoed at their own internal Hackathon). Or maybe one based around some special interest topic, such as a charitable cause or a hot topic. Whatever it is, it’s worth investing the time to come up with a creative spin that sets it apart from the others.

Set Event Goals and Define Success

Having a clear idea of what you want to get out of your event will allow you to focus on what matters. You might define success with the number of attendees, submissions or press mentions but identify your conversion criteria upfront to simplify the planning process.

Work Out Who You Need to Involve

Knowing your goals will help you begin to understand the scale of your event and what you need to focus on. If it’s maximizing the attendees, then you’ll want to go big. Big often means expensive and you may want to get sponsors involved to cover some of the costs if not all. If the Hackathon has a competitive edge, then that means hosting judges on duty. Maximizing submissions? Then you might want to think about offering prizes. Doing it for the coverage? Then start reaching out to your media contacts early.

Hackathons also have a lot of tiny details need to be taken care of and often all at the same time. Since you can only be in one place at once, you’re going to need assistance. You’ll need an MC to keep things organized and the event flowing. Then there are reception people in front of the doors to get attendees registered. To get the most value out of your event, you should consider recording it and taking lots of pictures so perhaps a photographer or at least a friend/colleague or two. You know the ones with the fancy cameras that they carry with them everywhere they go? If you’re doing demos, then you’ll also need people to help with the A/V equipment and be on hand to offer tech support. Make assisting people clear and visible on the day of the event with colored t-shirts.

Choose a Date and Time That Works

You need to pick a date and time that will work for your crowd. Make sure you spare enough time to plan it all and consider the day of the week that will maximize the attendance.

For work-based Hackathons around a product or service, weekday events are OK. You’ll need to provide long enough notice for attendees to get approval for the time out of the office. Also, stick to typical office hours like 9 to 5. For other types of events, weekends are better, especially for longer events. Weekday evenings, straight after work, can work well for shorter events – just remember to keep the drinks flowing.

Before you settle on your date, check out event sites like Eventbrite, Meetup and Lanyrd to rule out clashes with other events. Starting 8-10 weeks in advance is usually about right and remember to at least send out a ‘save the date’ blog post or mail once you’ve picked it.

Find An Awesome Venue

This will probably be your biggest expense but it’s not where you want to try to save money. Location can be a key factor for attendees when deciding whether to come or not. It needs to be a convenient location with easy parking, big enough for all the attendees and have the facilities to support them. That means enough space, WiFi and power. If your event runs overnight, then you’ll also need accommodation for people, blankets, stuff to lie on and maybe showers.

Make it as easy as possible for people to get there. Provide comprehensive directions, maps and transportation details. Don’t forget to spell out what to do once they get there too – signing up at the reception, how to get through the security and more. Print big signs to guide people.

Get the Kit

You’ll need A/V equipment like projectors for simultaneous sessions and microphone for slides and demos of applications. Make sure to test it ahead of time. The first time you set it up shouldn’t be the day of the Hackathon.

It’s often easier for attendees to present on their own hardware. Yet, you need to allow a quick turnaround between presenters. To save some time, have a couple of stations connected to the projector ready. This way, while one team is presenting, the next one can be set up.

If you’re filming the event, and you should, then, you need camera equipment. Unless it’s going to be a regular thing, you may want to hire the equipment or a photographer/videographer who already has it.

Get your swag on. Have a bunch of t-shirts available for giveaways and thank yous. Whatever design you come up with, make sure it doesn’t have a date on it. If it does, that means you can’t re-use any leftovers later on.

Have plenty of spare cables, USB drives, socket adapters and extenders available. Cover all connection types – Thunderbolt, DisplayPort, VGA etc.

Have Killer WiFi

This is super important but like at many hotels, WiFi sucks at a surprising number of event venues. Check this out before deciding on the venue and make sure the venue knows how important this is for you. Better yet, pick a venue where the WiFi has been thoroughly battle-tested by previous dev-related events. Make sure the venue has plenty of power sockets too. You want approximately 1.5 per attendee to cover all the laptops, tablets, phones and personal electronic devices.

Get More Than Enough Food and Drink

Don’t skimp on the food and drink. Nothing sends people home quicker than being hungry or thirsty. Have a large variety – it can’t be all Red Bulls and Oreos. So include soft drinks, tea, coffee, water and juice to your drink menu. Arrange breakfast, lunch and dinner. Have snacks available whenever people want them and include both healthy and junk food options. No matter what you do, don’t run out! If necessary, make trips to the local shops if you’re getting short during the event. You always want to end up with too much than risk having too little.

Communicate About the Event Regularly

Blog regularly before and after the event. Hit up any press contacts and influencers that you know to spread the word on Twitter and other channels. Keep in regular contact with your prospect registrants – once people know about it, you want to make sure it stays on their radar. To help you with this communication, set up a dedicated mailing list. Drip out information like venue confirmation, sponsors, judges and guests. Remember to follow up after the event as this is a good way to keep the mailing list fresh and ready for your next event.

You also want to set up a dedicated web page or site for the event which collects all the key data (date, location etc). For registration, don’t re-invent the wheel, just use Eventbrite, Meetup or similar.

Have Fun

Once it’s all over, remember that it was, in fact, a ton of fun and start prepping for the next one.

 

7 Tips for Better Developer-Designer Relations

In typical organizational groupings, designers and developers often find themselves in separate teams. Also, a common misperception of the people in these roles is that they are different — developers are logical, analytical, left-brainers whilst designers are the creative, flexible, right-brainers. And whenever people are separated like this, it’s easy for the relationship to become adversarial. Pretty soon all you do is to focus on the differences. Either they are those hippy-dippy designers with their strange and impossible requests or those vision-less, code monkeys. An ‘Us vs. Them’ mindset takes hold, leading to a break-down in communication which gets borne out in poorer products.

But does it need to be like this? I mean, there’s a lot of common ground. Both have a keen eye for detail, solve problems in creative ways and often share a love of great tools and technology. What’s more, the theory around what you can do to overcome these issues is simple. You just improve communication, empathize with the other team, respect to their contributions and build trust. Yet, actually achieving that can be tricky.

So, here’s seven practical things you can do to help designers and developers work better together:

1. Mind the Pet-Peeves

Developers:

  • Be Clear About What You Want

Often it seems that designers are expected to be mind readers. The brief for designers can be a little more than “go make this look good.” It’s just how a developer might ask for a requirements specification, a clear brief for a designer is also important. Make sure to provide examples of what you need. These might just be links to how others have approached a similar thing or even a quick sketch.

  • Be Mindful of Design Constraints

If you’re working with data, then supply real samples if possible. Knowing the data ranges you’re trapping in your code can be useful for designers to know too. Designers also need to know things like screen sizes and browser compatibility from the start.

  • Be Open About What’s Achievable

Developers can be the gatekeepers of what gets implemented. A big idea can all too often be dismissed out of hand in the name of time or performance constraints. Often though there’s a compromise to be made, with some part of the original idea being possible. So staying open-minded and working with the designer to find that compromise is important.

Designers:

  • Make Your Assets Easy to Work With

Name different file versions so that the latest version or the one you want to be used is easily found. Maintain the layers in image assets, naming them usefully and grouping them whenever you can. Don’t forget to also remove any old and no longer needed layers and files. If possible, prepare the assets for use too — cut them up so that they can be used straight away.

  • List Out Key Details

List out the names of fonts, text sizes and hex color codes used, along with the widths, heights, padding and margins you’re expecting. Doing this can be a real time-saver for developers.

With those pet peeves eradicated, you can start to focus on processes and ways of working.

2. Work Closely Together

This can be just having designers and developers sit next to or near each other. This helps encourage short, informal conversations that lead to more open and frequent communication. But this can also be applied remotely too with regular video chats and Instant Messenger or Group Chat. Either way, if you do this, then over time you’ll absorb knowledge about each others work.

3. Start Communication Early, Continue Regularly

It’s best to start a communication between the two teams as soon as possible into a project. If you build it into your process right from ideation, then there are no surprises that can cause problems later. So start off with designers and developers working together on how they can approach the project. Then continue the communication right throughout the build too. Look for opportunities to keep each other up to date on progress and developments. So, for example, when working on wireframes, designers can involve developers in deciding how to work with different screen sizes, devices, and browsers. Designers can share sketches, and likewise, developers can share links to works in progress. At all stages, bounce ideas off of each other, not just your own team, and break out onto whiteboards when you need to work through a problem.

4. Pair Designers and Developers

When the chance to work together doesn’t emerge itself, you should actively encourage it with the designer-developer pairing. For example, as Cap Watkins recommended in our recent interview, designers and developers can work together on a design bug rotation. This is where designers and developers pair up to work through a list of design issues. This involves discussing the problems, deciding on solutions and fixing them together. By doing this, designers are given insight into the code and developers are exposed to design-related issues.

5. Open Up Design Critiques

Opening up design critiques to others is a great way of helping them to better understand design work. This is something we’ve started doing at Fog Creek. We’ve seen that by showing example work and then walking through the design rationale, non-designers can better appreciate design issues. What’s more, describing how you’ve considered implementation issues shows that you’re taking developer problems seriously.

6. Run Designer and Developer Placements

For example, Etsy runs an engineering placement program. This program aims to get employees with no technical knowledge in deploying simple code changes in a few hours. Spending time working with other teams, even for a short time, helps to foster cross-team communication. This can be taken further too, with embedded team members, so designers embedded in development teams and vice-versa. Trish Khoo explained how this works with embedded test specialists at Google, in an interview with us.

7. Learn about Design or Development

Knowing even a little about code will make you a better designer. It’ll help you to understand and resolve implementation issues that you would otherwise have run into later. Similarly, some understanding of the theory and processes involved in design work will enable you to provide more useful feedback. Learning about design does not mean you have to be creating design assets. And the same goes for the code too. But by at least knowing the terminology and key concepts, you’ll be able to have more meaningful conversations about design and code issues.

By thinking through and creating opportunities for designers and developers to work on issues together, you can encourage a closer and better working relationship.

Why Your Retrospectives Have Become Unproductive?

Retrospectives provide teams with an opportunity to reflect. They’re an opportunity to discuss what is working and what isn’t with the goal of iterative improvement. The meetings should create a safe environment for team members to share and discuss processes and practices constructively so they could come up with actions to resolve problems or improve how the development team functions.

Yet, often this isn’t the case — retrospectives break down, become unproductive or just don’t happen at all.

Here are 3 core failings with retrospectives, along with potential causes and remedies:

1. Retrospectives That Don’t Lead to Real Change

The desire for continuous improvement is at the heart of retrospectives. The feedback gathered during the meetings should result in action items. These action items, upon completion, should deliver positive change. But if the action items aren’t completed or the true cause of problems is not identified, then the faith in the process can wane.

This can come about for a few reasons:

  • Too many action items

It’s important that you don’t try and tackle too much and fail to make real progress with any of them.

  • Items are vague or have no clear resolution

The action items you create need to be specific and have a definitive end point. Items like ‘improve test coverage’ or ‘spend more time refactoring’ lack specificity and need to be quantified. Concrete action items provide demonstrable results — allowing the team to see and feel the improvements achieved by following the process.

  • A lack of responsibility for actioning items

Often the facilitator can end up with all the issues or items are assigned to groups of people. This is a mistake — each item should have a dedicated owner who is in charge of ensuring to get it done, even if a team would be completing them.

  • Too much emphasis on technical issues

Working with tech is what we do so identifying problems about systems, servers, libraries and tooling is easy. But you need to ensure that you give just as much attention to working practices, communication, and people problems. Otherwise, these key impediments to improvement will hold you back.

Whatever the reason is, it’s important that you’re completing the action items. So prioritize them and focus on just a handful of items that you know can be done before the next retrospective. Break down larger issues so that you can begin to make progress with them too. Track items raised at previous retrospectives and review results in each session. This sense of momentum helps to build and maintain a belief in the process and fuel future improvements.

2. Retrospectives That Don’t Occur Often Enough

If retrospectives don’t happen often enough, it can cause a number of knock-on effects:

  • Too much to go over in any one retrospective

This results in meetings that fail to get to the cause of issues. Or due time isn’t spent on issues important to attendees, which can be disheartening.

So much has changed since the items were identified that the issues raised are no longer a priority. This doesn’t mean they aren’t important. More often, it just means you’re compounding them with others and you’re missing an opportunity to improve.

3. Lack of Participation in Retrospectives

This can often happen if the meetings aren’t managed effectively:

  • Sessions are long-winded

You should decide on the agenda before the meeting to avoid straying off the topic and unfocused discussion. You might want to consider time-boxing sections of the meeting. This helps to ensure discussion on one section or type of problem doesn’t consume all available time and attention, and that all areas get adequate attention.

  • Sessions have become stale

Change things up. Try removing seating for one session, so people don’t just sit back and switch off mentally. Or change the format so you aren’t just repeating the same old questions. There are plenty of different techniques: from the Starfish and 4Ls to FMEA if you decide to deep-dive on a specific issue. Or just pair off and discuss items to bring back to the group. Some people open up better in smaller groups. And one-to-one force a conversation, otherwise, things get awkward.

  • There’s a lack of trust

A lack of participation can also result from a breakdown in trust. You should only invite team members to take part. Observers, especially management, despite noble reasons for attending, should be dissuaded from doing so. It may seem to make sense to share feedback so that other teams can learn from it too. But the specifics should be kept in the room. People might not contribute if they know there will be a long-term record of it, or if attributable comments are shared. Just share the action items or areas you’re looking to improve.

  • Sessions are too negative

Retrospectives should encourage introspection and improvement. But this doesn’t mean it’s just a time to moan. It can be too easy to focus on the things that aren’t working or you failed to do. So it’s important to make an effort to highlight improvements, and not just from the last iteration but over time too.

With a few changes and a renewed commitment to the process, retrospectives can be a great way of ensuring you’re constantly improving. They can be an important part in making the working lives of your developers better and more productive.

How Low Should You Go? Level of Detail in Test Cases

It can be difficult to know just how much detail you should include in your test documentation and particularly in test cases.

Each case has a different set of needs and requirements in terms of purpose, usage, frequency and admin needs.

If it’s written at a too high level, then you’re leaving it open to too much interpretation and risking the accuracy of the testing. If it’s at a too low level, you’re just wasting your own time. It makes the maintenance more difficult and there’s an opportunity cost to other projects with demands on your time.

In this post, we break down some of the factors you should consider helping you find the right level.

Understand the Wider Context

Each of your project’s stakeholders will have concerns that will impact the amount of detail you need to provide. From your organization’s internal politics and appetite for risk to the extent to which the product is relied upon etc. This will provide a wider context for your test cases and start to improve your thinking. The documentation expectations at a lean startup may even differ greatly to that at some of the financial institutions.

Test Requirements and Resources

You need to provide enough information to describe the intent of the test case. This should clear all the elements that need to be tested. A special consideration should be given to any specific input values or a particular sequence of actions.

The amount of time you have to invest in the test case and the human or IT resources you have to enact the tests is obviously another key factor.

Know Your Audience

Also, consider the audience for each case. How technical are they? How much product knowledge do they have and how experienced at testing are they? More experienced testers who are familiar with the product will need fewer details but is the team likely to change in a foreseeable future? If so, then you might want to head off re-writes later by providing extra details now for those with less experience.

Some organizations have specific requirements to provide evidence of test coverage. Usually, it’s to show adherence for compliance to a standard or certification or for other legal issues.

Test and Product Considerations

Each test is different, from the importance of the test, to how long it will be in use for. If it’s likely to convert to an automated test script in the future, then including more details at that time might make it easier to do. There are similar considerations about the product you’re testing. Will the application be used in long-term? And are whereabouts in its lifecycle? The amount of change that you can expect for a recently built, an agile application is far greater than for some old system you’re maintaining. Unless it’s a wild, testless code beast that is.

There’s a Balance to be Found

These factors don’t necessarily mean you should include more detail but crucial and long-lasting tests justify the time if needed. However, there’s a balance to be sought. If you create highly specific tests, then even minor design changes or functionality alterations may mean you have to re-write the cases. They also lead testers to raise bugs for what end up creating problems with the test documentation, rather than impacting customers. They can have a knock-on effect too. They encourage the tester to only consider the specific paths through the application detailed in the case. Meaning they might not consider the functionality from a broader perspective.

There’s no silver bullet for coming to a conclusion, each organization’s requirements differ. And these requirements change depending on the project, product and individual tests. However, considering the factors above, you can find a level that works for you and your team.

Taming a Wild, Testless Code Beast — 4 Steps To Improve Test Coverage

Whether you’re working on an existing or new application, you’ll often find yourself playing catch up when it comes to tests. Soon deploying code changes feels like poking at some ugly, sleeping code monster — you aren’t sure what’s going to happen, but you know it won’t be good.

Here are the 4 things you should do first to tame the beast and improve test coverage:

1. Add the Right Tests

Start by adding tests in the areas where it is easiest. It’s important to consider the order in which you do this to make sure you get the most out of your scarce resources. You want to start adding tests in the following order:

  • i. Create tests as you fix bugs

Add tests to prove that your specific fix is working and keep them running to show that this does not break again. This prevents from being somewhat targeted — you are creating tests in your weakest areas first. The weaker it is (i.e. more bugs) the faster you will build up tests.

  • ii. Create tests with all new features

All new features will need to include tests created to prove that the feature works as expected. If you’re covering the new aspects of your application, then at least things aren’t getting worse.

  • iii. Create tests as you add to old features

When updating old features, add tests as you go to show that the older functionality is not breaking in unexpected ways.

  • iv. Create tests in identified risk areas

Talk to the developers and testers on your team and ask them to point out any weak spots or issues they have experienced. Also, you talk to your support team — they are an excellent resource with a direct line to the customer. They’ll know the features of your product that frequently causes issues.

2. Turn on Code Coverage

Code coverage is a tool included in most continuous integration systems (or one that can be added with a plugin). This tool will instrument and monitor your code as you run the tests to determine how much of your code used by the tests. For this to be useful, follow these steps:

  • Start running code coverage against all your code
  • Get a baseline

Find out what the tool can see, where you are currently at etc.

  • Determine areas that you want to exclude.

There are likely areas of your code that you don’t want to cover — third-party tools, ancient code untouched for years etc.

  • Determine coverage goals

Sit down with your team and discuss what your current coverage is and what your ideal can realistically be (usually 90% or above).

  • Work-out steps to improve your coverage

You aren’t going to fix this problem overnight. Put in place some specific tasks which are going to help you achieve your goals over time.

  • Determine your pass/fail criteria

Is staying the same OK, or should it always go up? Do you define any drop as a fail?

  • Run Code Coverage constantly

Use automation to run your coverage test and use the criteria you determined as a team to report a pass/fail and do this constantly. It is a lot easier to add tests when the code is still front and center in your mind than later on.

3. Run your Tests on a Scheduled Basis

You should run your tests regularly, on several schedules:

  • Run them on every check-in

Use CI tools like Jenkins to run (at least) your unit tests on every check-in. Run them simultaneously if they are taking too long to run at this frequency.

  • Run them on every build (package)

Depending on how your systems work, your CI infrastructure can help you with this. This could be on every check-in if you are on Continuous Deployment, or every day/week/month that you use. This should be a clean install on a test environment and a full run of all your automated tests.

  • Run them on every deploy

You should run all your automated tests against your environments immediately after a deploy.

  • Run them every X days/hours/minutes

Run your automation suite against your constant environments as often as you can (Production, Staging etc). This should be at least a “once a day task” and take place during ‘off-peak’ times when it does not interrupt others too much. You can increase the frequency further if your tests are short, just be mindful not to overload the system.

4. Provide a Button to Run the Tests

Again, use a tool like Jenkins to turn test runs into a self-service operation. A developer should not be delayed by asking a QA person to run a test for them. Get a system in place where your tests will run and just give them a button to press. Remove as many barriers for everyone to run the tests as possible.

If you follow these steps, over time, you’ll see that you are able to turn an unwieldy application into something more manageable. First, by adding tests to the key areas, then making things as easier as possible, you can build confidence around your code changes and deploys.