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.
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 tooand they keep things interesting by picking a different cuisine from around the world each time.
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”.
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.
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.
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.
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.
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.
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 are 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.
Life is complicated and we all accept it. While we tend to categorize the different aspects of our lives, in reality, things rarely fit neatly inside the little boxes we carve out for them.
Our work life is another major compartment and when it comes to planning, it’d be nice if a single project captured all the details we might need to organize work for a project or product and across teams, but often that’s not possible
This meant at times, working with the Iteration Planner and Kanban boards in FogBugz could be kind of awkward. What if you maintain multiple products and each one has its own project? You’d want the “Planner” to show both at the same time, but it couldn’t. Or, what if several teams had multiple projects relating to a single product? You couldn’t plan without affecting the other teams.
Well, such things are not a problem anymore! With the cross-project planning capabilities in Iteration Planner and Kanban, you can keep track of cases in multiple projects at once.
That means you can view all cases relating to a product on one board, even if they’re in separate projects. And multiple teams can plan things without disrupting or being interrupted by others.
Here’s how it works
Site admins can create a new planner and associate it with one or more projects. Each planner may contain any global milestones and any per-project milestones for its projects. You can also optionally filter by project or area, and filtering down to multiple projects is allowed too.
For existing customers, each of their single-project planners migrated to the new versions. If you would like to add additional projects to a planner, view that planner and click “Edit Planner Settings” in the top-right, then “Add Another Project”, select additional projects and click “Save”. With that done, you can add milestones from those projects and any global milestones, and the filter columns shown will include cases from your selected list of projects.
If you use our Kanban board, the project selections for your planner also apply to each milestone when you click through to the Kanban view.