The ultimate software development tool

Best practices on project management, issue tracking and support

Category: Project Management

Evidence Based Scheduling

Evidence-Based Scheduling (EBS) is one of the most revolutionary and mindblowing features of project management software today. Joel Spolsky, the inventor of EBS, describes it best:

“Software developers don’t really like to make schedules. Usually, they try to get away without one. ‘It’ll be done when it’s done!’ they say, expecting that such a brave, funny zinger will reduce their boss to a fit of giggles, and in the ensuing joviality, the schedule will be forgotten.

Most of the schedules you do see are half-hearted attempts. They’re stored on a file share somewhere and then completely forgotten. When these teams ship, two years late, that weird guy with the file cabinet in his office brings the old printout to the post-mortem, and everyone has a good laugh. ‘Hey look! We allowed two weeks for rewriting from scratch in Ruby!’”

Joel points out that there is a need for finding out how much of a return a project would bring, and in order to calculate this you need to first figure out how much time you need to invest in order to get that return.

“Why won’t developers make schedules? Two reasons. One: it’s a pain in the butt. Two: nobody believes the schedule is realistic. Why go to all the trouble of working on a schedule if it’s not going to be right?”

Over the years, FogBugz developed a system that’s so easy that even the grumpiest developers are using it. It’s called Evidence-Based Scheduling or EBS. You gather evidence, mostly from historical timesheet data that you feedback into your schedules.

Smart Scheduling

What you get is not just one ship date: you get a confidence distribution curve, showing the probability that you will ship on any given date.

Here’s how you do it:

  1. Break Them Down: EBS is a believer in breaking each design into steps, and maximum time allowance is 16-hours for each step.
  2. Track Elapsed Time: EBS encourages you to keep timesheets so you can keep track of how long you spend working on each task. Then you can go back and see how long things actually took relative to the estimate.  You can do this for each developer.
  3. Simulate The Future: Rather than just adding-up estimates to get a single ship date, use the Monte Carlo method to simulate many possible futures. In a Monte Carlo simulation, you can create 100 possible scenarios for the future. Each of these possible futures has a 1% probability so you can make a chart of the probability that you will ship by any given date.

EBS is the future of project management and yet a handful of developers know about this hidden gem. Our goal is to spread the word by providing a smart tool for developers to use to help with the heavy lifting, leading to time savings and increased accuracy for their projects.

Some Feedback on EBS:

Jeff Atwood@Coding Horror: “It’s a tremendous credit to Joel Spolsky that he made this crucial feature the centerpiece of the FogBugz. I’m not aware of any other software lifecycle tools that go to such great lengths to help you produce good estimates.”

Rafe Colburn@RC3.org: “We’re rolling out FogBugz 6.0 at work, and I’m finding that I actually like the time tracking. For one thing, it’s a tool for focus. When you kick off the timer on a task, you don’t want to jump around and multitask because it will just throw off the timer. The timer feature itself is pretty easy to use.”

Scott Rosenberg@Wordyard.com: “What’s most interesting about the FogBugz is what Spolsky and his team are calling ‘Evidence Based Scheduling…’”Reg Braithwaite@Raganwald.com: “I built a prototype that did the exact thing that FogBugz is doing quite some time ago. However, prototypes are not shipping products. FogBugz is a shipping product. My prototype was not. And that makes all the difference.”

We’re Bad At Interviewing Developers (and How to Fix It) Interview With Kerri Miller

In this interview with Kerri Miller, Lead Software Engineer at LivingSocial, we discuss how to hire and interview developers. We typically don’t get trained on interviewing and we’ve all experienced the haphazard approaches of those new to it – poor organization, repeated questions, fizz-buzz… Kerri tells us how to run interview days, the types of questions to ask, how else we can evaluate candidates and what to do after the interview. For more tips, Kerri writes about software development and hiring on her blog.

Introduction

Derrick:
Kerri Miller is a lead software engineer at LivingSocial. She is also a RailsBridge instructor and frequent conference speaker. She talks about software development and hiring, including the talk, ‘We’re Bad at Interviewing and How to Fix It’. Kerri, thank you so much for taking the time to join us today. Do you have a bit more to share about yourself?

Kerri:
I am actually, in fact, a lead software engineer at LivingSocial. Part of that is working with junior developers, or more junior developers, leading software teams and projects, and I also do a fair bit of work in our engineering culture team, so doing things like how do we propagate a good culture for code reviews, post-mortems, and hiring.

“You want them leaving the interview process regretful that they didn’t get hired, not resentful that they didn’t get hired”

What’s Broken with Developer Hiring?
Derrick:
What do you think is broken with the current way a lot of companies hire and interview?

Kerri:
We don’t do a really good job of hiring with intent. We decide that we need more people, but we don’t do a really good job of figuring out what we need those people to actually do, and who we actually need to hire. I like to think of my software teams as little ecosystems, little, tiny arcologies that exist in a bottle. They’re not entirely a closed environment, and, like any ecosystem, anytime you introduce anything new to that realm, there will be changes. There will be impacts.

Any time you hire somebody, you’re changing that ecosystem. You’re introducing a new species or a new variable to things and it’s going to change. Thinking about what you want to change means that you have to have laid that groundwork to understand where you are at the moment. A lot of teams and companies don’t do a really great job of understanding that. They’re just simply, “We need more bodies. Let’s hire bodies.” They don’t go into these things with a conscious sense of where they are and what they need, and how the future’s going to change by adding more people.

How to Structure and Run Interview Day
Derrick:
Let’s talk about the interview day. How should we structure it, and what are some key aspects you need to get right?

Kerri:
You need to go into it having a plan, and that plan starts with knowing what questions you’re going to ask and why. Understanding that every question you ask that a candidate can’t answer, or every step of that process is an opportunity for a candidate to filter themselves out of that process, it’s a point for you to get information to make that final decision. I think it’s really important that you take a look at what that plan is going to be. If you have, say, three people, and you’re hiring for a front-end developer, you should have one person ask about JavaScript. You should have one person ask about, perhaps, browser interaction, or working with designers, or what have you. Just splitting up that interview so that you’re not asking the same questions over and over again, you’re really able to get really solid signal on a person’s skill sets, what they’re comfortable with, and what their concerns are. What kinds of decisions are they making?

Good Types of Questions
Derrick:
What are good kinds of questions that we should be asking?

Kerri:
Well, I’m not a big fan of whiteboarding, because I think that’s something that we just automatically do, and we don’t think about, “Well, what questions are we trying to answer by asking a candidate to solve a problem?” Are we dinging people for trivia questions, for not remembering, “Oh, I need this third option flag or an obscure method from a core library.” Instead, I really want to focus on questions that are asking about decisions that they’ve made, what choices have they made, and what choices would they make again in the future? Are they reflective about mistakes that they’ve made? Are candidates looking for opportunities to improve, and how do they actually go about it? Do they make plans for themselves, like how they would improve a certain skill set, whether that be a technical skill set or a more soft skill set, for example, management, or project shepherding for example. Those are the kinds of questions that I think really get you at the heart of not necessarily what somebody knows, but what they’re capable of.

Beyond the Interview – How Else to Evaluate Developers
Derrick:
You’re a proponent of evaluating candidates in other ways than just an interview. How else should we be finding out more about potential employees?

Kerri:
I’m a really big fan of pairing on projects, like actually working with somebody. It doesn’t have to be a formal or traditional pair programming situation with one computer and two people, talking through the technical choices that they would be making as they programmed on something. At LivingSocial, we do a code challenge like a lot of companies do, using that as, then, a launching pad to have a discussion with a candidate to say, “You solved the problem using this technique. Why didn’t you choose this other technique? Why did you choose this one? How would you do it better? What if we sat down and refactored?” That’s one really good way to really get the heart of why are they making the decisions they’ve made? Not just did they make this choice because they didn’t know, or are ignorant, or did they make this choice because they had a certain belief about what the requirements of a given project were? That’s one way to do it.

Other ways you can be finding out more about potential employees … I’m a really big fan of asking the employee to explain something to me or teach something to me. In the past, we’ve done this with simply just saying, “You can teach me anything, something that I don’t know, and preferably is non-technical.” How well do they communicate about something that they’re a local expert in but they’re intended audience is not? Could they then go off and go and learn a new framework, or go have a meeting with, perhaps, a stakeholder, or a client, and come back and explain what the actual requirements are to me, to distil down what I need to know and communicate that well? Communication is such a big part of what we do in this job, and so testing for that essential skill in a really clear and explicit way can be really useful and get you a really good signal about who that candidate is and how they’re going to fit into your organization.

“We don’t do a really good job of hiring with intent”

After the Interview – Making the Hiring Decision
Derrick:
After the interview, what are key things that employers should be doing?

Kerri:
I think it’s really important that we don’t just say, “We’re going to get back to you,” but to say, “We will get back to you by Thursday, end of the day.” Then, if you can’t make your decision within those three or four days, communicating that to the candidate so they have expectations that you can meet, because it’s not just good for the candidate, it’s good for you as a company to have that discipline, because you want people to, whether you hire someone or not, you want them leaving the interview process regretful that they didn’t get hired, not resentful that they didn’t get hired. Being professional and upfront and just friendly and encouraging about the entire process is great.

I try always to make sure that, if we can’t hire somebody for whatever reason, we make sure that we give them constructive advice or feedback afterwards, or at least make that available. If you did like somebody, if it came down to either Joe or Mary, and you hire one or the other, keep that person on file, and follow up with them in a few months to see how are they doing, what’s going on? “Hey, we have an open position, would you like to re-apply, or would you like us to consider you for that?” That gets into the part of how you keep metrics on things as well because if you didn’t hire somebody, figure out why you didn’t hire them and then follow up and see, are they actually doing that work, and did we hire the … Not necessarily the wrong person, but did our process let us down? If you assume that somebody didn’t know anything about, say, SQL, and now they’ve gone on to work on a SQL-heavy project, for example, what in our process missed that step?

“It’s really hard to look at who you hire and decide that you have a good or bad process. But you can look at who you don’t hire.”

Derrick:
Great, so we talked about having a plan as part of the hiring process, what’s a good process to follow to make a hiring decision?

Kerri:
When you split up the interview topics, the questions you’re going to ask, and you’re going to consistently ask all of your candidates, it feels a little bit like reading a script, but it really lets you compare apples to apples as much as possible. Once you’re done with your little section of the interview, you should immediately go back to your desk and not get back to work but write down what your impressions were. What were the pros and cons, the bullet points, and find something good about the candidate and something not-so-good about the candidate, something that you wish they did have? Doing that at that moment and passing that back to a central person so as not to … Don’t pass it back to a group, pass it back to a central person, whether that be an HR or the hiring manager, to collect that, so you’re not coloring the impressions of other people.

When you get back into that room with everybody else, whether it’s virtual or real, to really discuss your opinions, you’ve got your opinions of the moment and you can’t be swayed by the impressions of somebody else. For example, if you were supposed to interview them about JavaScript, and the senior JavaScript person, who’s got twenty years of experience in JavaScript, just really did not like that person, how would that color your opinion if you had to give your opinion in that moment? If you wrote it down previously, no, this person really is good at JavaScript, then you’ve captured that honestly and you can really give honest feedback about what that person’s qualities are and what their strengths are without being colored by other people in that discussion.

Measuring and Improving Your Hiring
Derrick:
You hinted at this earlier, but a key part of your approach to hiring is measuring the process to improve it. How could we go about measuring the effectiveness of our hiring?

Kerri:
It’s very seldom that we ever hire anybody bad. When you hear horror stories about hiring, it’s always somebody else’s team that hired that one jerk, or that one idiot, so it’s really hard to quantify because now we know that person, and we’ve worked with them, and we understand their strengths and their weaknesses. It’s really hard to look at who you hire and decide that you have a good or bad process. You can look at who you don’t hire. You can look at that in terms of what were the false negatives? Did we bounce this person out of the process for a specific reason and then it turns out that that reason wasn’t good based on where they ended up going to work?

It’s really easy to LinkedIn stalk people, and peak into their GitHub profiles if they’re doing that sort of work, to see what they’re doing a few months later. It can be really useful to, four, or five, six months down the road, go back and look at the candidates that you passed over and see what they’re doing to understand, if you keep records of the questions that you ask, and the reasons why you maybe didn’t hire somebody, to see if those reasons are still valid.

Other metrics that I think are really, really important to an organization are understanding what your pipeline for candidates consists of. At each step, you have a certain amount of leakage, because people just simply don’t make it through the process or they abandon the process, they disappear. How many people are you losing at each step, and is there one step that you’re losing a lot of people at? Maybe you need to refine that step, remove it, or move it earlier or later in the process based on what your organizational needs are. I think it’s also important to look at who you’re losing as well. Are you losing junior developers at a step that you really don’t want to be losing them at? Are you losing more diverse candidates? Are more women abandoning your process at a certain step than men are, and understanding, or questioning at least, your process to see, is that a problem? Can we fix it? How do we fix it?

“You should immediately go back to your desk, and not get back to work, but write down what your impressions were”

Common Developer Hiring Mistakes
Derrick:
What are some common mistakes you see companies making when hiring developers?

Kerri:
Some of the more common mistakes are hiring from our friend networks. I think that the friend network is such an important part of how we get jobs, but it also tends to reinforce our monocultures a little bit. We tend to be friends with people who are mostly like us, and so those are the people that we’re going to be recommending, and so those are the ones that get hired more often. When I was mentioning earlier how the team is an ecosystem, it’s important to have some diversity there, and not just the diversity we talk about in terms of gender or ethnicity or race, but age, class, looking at people’s technical backgrounds, do they come out of CS programs versus being a self-taught or a boot camp?

Industry backgrounds, did they work in, perhaps, consumer electronics testing before they became an SDET at Microsoft? Were they at startups versus large enterprise companies, or somewhere in between? All those pieces of diversity are going to be influential and improve the health of the ecosystem of your team, and so those friend networks are important for getting candidates in the door, but understanding that that sometimes is going to lead to a certain amount of self-selection for candidates.

You have to, like in soccer, they say, “Run to where the ball will be, rather than where the ball is.” If you have those early conversations about who you need to hire, and what you want to look for, what sort of energy and person do you want to add to your team, to influence it into a good direction? And then go to those people, find them, whether it be through meetups or user groups, or extending your extended network, not just your immediate friend network.

Derrick:
Are there any other resources you can recommend for those looking to improve how they hire developers?

Kerri:
Looking at the different boot camps you’re doing, and how they’re talking to their students, as well as to their sponsoring companies, or the companies that are hiring. I’m a really big proponent of hiring more junior developers, because no one is ever going to know our exact technology stack and our exact way of working, we always have to teach people, so looking at what those boot camps are doing, and how they’re talking about the industry, because they’re trying to set people up for success over the next five years. There’s a lot of wisdom. They’re spending a lot of time to gather wisdom that they can relate to us about who we should be hiring over the next five years, and what skills we should think are important.

Finally, I tell everybody this, go take a relationship skills class. Although they’re sold as being aimed at couples, a lot of that is really about listening to other people and understanding what their concerns are. Once you can start to build those sorts of skills for understanding the perspectives of other people, just generally improves everything about your hiring process, and your team, and how you work with each other.

Derrick:
Kerri, thank you so much for joining us today.

Kerri:
I’m really excited about this topic. I’m glad to see more and more people talking about it. There’s no one size fits all solution. We all face some really unique problems, but there are some commonalities.

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 Stripeand 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 sourceda number of libraries and even whole products.

Help you to recruit

  • Take Yahooand LinkedInfor 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 typesfor 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 ideaof 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 goalswill 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 itall 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.

 

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 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.

Getting Started With Iteration Planner For Agile and Sprint Planning

Iteration Planner unlocks the power of the project management software as an Agile planning tool for software development. With it, you can combine sprints and milestones to graphically group cases into the scope of work that you’ll complete in each sprint. You can also balance the allocation of resources by dragging and dropping cases from one assignee to another. Iteration Planner is a lightweight way to plan work and manage teams using FogBugz.

Here are a few key suggestions to help you apply priorities in your projects:

  • 1–3 Minimum Viable Product
  • These are all of the cases that must be completed in order for your sprint to provide new value to the customer in the form of a usable feature.
  • Priorities 4: Hygiene
  • This is non-essential work that improves the product but is not required in order for the product or feature to be useful to a customer. Small amounts of this work are often spread throughout sprints to continue making small improvements to the product.
  • Priority 5: Incidental work
  • Don’t allow your scope to creep from a manageable size to something so huge that it couldn’t be completed in less than a decade by Steve Jobs and a host of efficiency experts. If you add something as incidental work that needs to be done during a sprint you need to subtract or deprioritize some other work that has an equivalent number of estimated hours. Keeping all your incidental cases under one priority allows you to group cases by priority and see how much time you are spending on cases that are not part of your MVP. At the end of your sprint add up the hours and determine whether or not the interrupts were a worthwhile use of your time. This discussion can be part of your retrospectives or done separately. Either way, the numbers should be useful for evaluating whether or not the work that was done during the sprint was part of the planned work.
  • Priority 6: Long-range work
  • Frequently teams are asked to take on a category of work that is not part of the MVP but does contribute to the overall plans of the organization. These tasks may be expected to take many sprints to complete and their progress needs to be tracked across multiple milestones.
  • Priority 7: Stuff we won’t do
  • It’s useful to declare this as a way of focusing the team and managing expectations about the work that will be completed in the sprint.

For Agile software development teams, Iteration Planner is a useful, graphical tool that allows you to visually manipulate the information you need for planning Sprints. With it, you can set the direction for your team’s work and monitor progress so you can deliver on your organization’s goals.

How To Keep Track Of Cases In Multiple Projects At Once?

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.

Take a look at our help site for more details. If you have any questions or feedback, please get in touch!