Here’s an Idea

Today we’ve launched several major changes to the Discussions feature of Trajectory. These changes lay the groundwork for many more improvements we’d like to make to Trajectory in the future to make your projects more successful.

Discussions are one of the things that make Trajectory different than other story planning tools out there. Create a discussion instead of a vague story somewhere in an icebox or far down in the backlog. Discuss it with the team, do some wire frames and mock-ups. When the feature is understood, then create stories from the discussion about the work that will actually be done.

Ideas

First, we’ve renamed Discussions to Ideas. We wanted a more meaningful name that communicated the intention of this section of Trajectory better. Ideas are the communications that will spawn future development, which will then be represented in stories.

Next, we’ve greatly improved the interaction between Stories and Ideas, making it much easier to use the two together.

One of the first things we did to accomplish this was to rewrite the Ideas functionality in Backbone.js, like stories is. This makes switching back and forth between Stories and Ideas near instantaneous.

We’ve also added several tools that further integrate Ideas and Stories.

• It is now possible to see the idea that a story came from on the story listing. Click the idea to go right to it.
• You can mouse over an idea to highlight all the other stories that also came from that idea.

• We’ve changed the check box into a gear on the story listing page. Select all stories related to an idea in this menu. Once all stories relating to an idea are selected they can be moved as a group with drag and drop or by clicking the gear of any other story and selecting “Insert selected stories above”.

• It’s also possible to select all stories from the page of an individual idea. Click “Select these stories in the backlog”.

• Whether you’re on Ideas or Stories is preserved when switching between projects or closing the browser.

Finally, we’ve included more information on the Ideas listing to give you a better idea of their progress. We now show the number of accepted stories on an idea in addition to the number of stories on the idea.

We also introduced two new sections to the Ideas listing: Finished and Old. An idea will move to the Finished listing if all of its stories have been accepted and haven’t changed in a month, and the idea itself hasn’t been commented on for a month. An idea will move to the Old section if it never has any stories created for it and isn’t commented on for a month.

Unrelated to Ideas, but facilitated by these changes, we’ve also moved the functionality to move a story above another, and to create a new story above an existing story into the new gear menu. Many users had trouble finding these two features, and we’re hoping this will make it easier.

URLs

With these changes we’ve also improved the URLs in Trajectory in a few ways. Trajectory Ideas and Stories no longer use hashes in their URLs. The URLs are real URLs, addressable by the server and the browser. This has allowed us to introduce several performance improvements, and we’ll be able to do more with this in the future.

Finally, we’ve shortened a bunch of the URLs in Trajectory. It used to be that a URL for a story might be https://www.apptrajectory.com/accounts/thoughtbot/projects/trajectory/stories#106420. That URL is now https://www.apptrajectory.com/thoughtbot/trajectory/stories/106420.

We believe that using the URLs of stories to refer to stories is much more valuable than merely referencing a non-informational ticket number (ie. 106420). For example, by using the URL in commit messages you can now simply click the link on GitHub in order to go from the commit message to the related story. This is really powerful, and we wanted to make the URLs even shorter to make them more conducive to including them in external systems.

We’re working hard to make Trajectory a system that improves the software you’re building. We think providing structure and communication from concept to creation with these new Ideas is a step in the right direction, and we’re looking forward to doing more.

If you’re already using Trajectory, it’s live now. Go ahead and give it a try. If you’re not using Trajectory yet, sign up for a free trial and give it a try.

Introducing Trajectory GitHub Integration

Today I’m pleased to announce the availability of one of our most requested Trajectory features, GitHub integration.

We’ve never really used the GitHub integration in any of the previous tracking/planning software we used because it’s so hard to use it consistently and well. When we set out to implement GitHub integration we set the bar high by insisting that it be something we would actually use. I believe we have done that with a new feature that I don’t believe has ever been done before for GitHub integration.

Now, when you start a story, Trajectory will indicate an auto-generated feature branch name (you can change the branch name, if you want). Any commits against this branch in GitHub will automatically be associated with the story. There is no need to include the story URL in the commit message, unless you are issuing a command to Trajectory (such as to Finish the story).

This functionality solves a real problem with the integration with GitHub while embracing the way many of you are probably already working with feature branches in your repos.

In addition to the feature branch integration, you can also include a link to stories in individual commit messages. When you do this, Trajectory will associate the commit to the story. Finally, you can issue commands to Finish a story in Trajectory from your commit.

You can read more specifics about this new functionality on our support site. If you’re already using Trajectory, go ahead and give it a try. If you’re not using Trajectory, sign up for a free trial and give it a try. You can even get started quickly by importing your Pivotal Tracker projects.

From the desk of a thoughtbot apprentice

First, let me introduce myself, my name is Alex and I’m an apprentice here at thoughtbot. You may recognize me from this, this or this.

As an apprentice I get to immerse myself in the world of thoughtbot. I sit next to amazing developers and designers, and do work on the exciting projects that come through the door. As a result I’m learning crazy fast, every day I write code that I could not have written the day before. However, even bigger than the knowledge I’m gaining about how to write code is what I’m learning about process of developing software. One of the things that’s really important is the way people work.

I had heard words like XP, agile, and scrum used to describe software development but had never seen them in practice. After 5-plus weeks here I can tell you that the way they do things works.

Standup

Every morning at 10:00 am the entire team gathers in the conference room. We each go around the room and say something along the lines of the following:

Alex: Yesterday I worked on ______, I implemented ______ I had to do ______ to make it work. Today I will be working on ______. I am blocked on ___________.

Someone else: Yesterday I worked on ______, I did ______. Today I will be working on ______. I have no blockers.

These standups are the lifeblood of thoughtbot. They improve communication internally and provide accountability. If I say I’m gonna do something in standup then I do it. It ensures that if someone is blocked on a problem that someone else can solve, then that problem gets solved.

Retrospectives and teams

We work in teams. Each team usually consists of one designer and 2 to 3 developers. Each team dedicates its time to one project. Once a week each team meets with the client to discuss what was done during the week. As part of the retrospective each person on the team as well as the client goes around the table describing how they are feeling about the project and airing any grievances they may have about the way the project is progressing. These meetings make sure that the team is all on the same page and that we are doing work that our clients approve of.

Airing of grievances

Client Pitches/Caring about what we’re working on

Before we work with a client we ask them to pitch to and converse with the developers and designers (not just the management) on their product. We want to know:

• What’s their business model?
• Who are their competitors?
• Why is it a good idea?
• Will they be fun to work with?
• Do they get the principle of an MVP?

The reason we do this is simple. People do better work on projects that they’re excited about. By having potential clients pitch the product to us we can choose products that we want to work on.

TDD

Before I started at thoughtbot I was of the opinion, like many others, that testing your code is a waste of time.

It was part of my job as an apprentice so I did it. But I was not as exuberant about it as most of the other people here.

But then something changed.

I began to write cleaner code that solved real problems and when code introduced breakages I knew about it right away. 

Now I get scared when I see code without tests and I am test driving all my code, even the stuff I work on outside of thoughtbot.

Trajectory

We practice what we preach and use Trajectory to manage product development. What this means is that there are no emergencies. If a client finds a bug or needs a feature developed, they simply put it in Trajectory and prioritize it. The developers and designers are able to take the top story off the stack and have a discussion around it. All from within the app.

Campfire

We use Campfire extensively. We have a bunch of rooms:

• General Discussion, for company wide news, blog posts, etc.
• Dev Discussion, filled with vim tips, bugs and other geeky goodness.
• Design Discussion, I have no idea what goes on in here but it involves designers.
• A room for each project, in these rooms we post feature branch code reviews as well as project specific questions.
• Last but not least is everyone’s favorite room, Watercoolor (or WC, as we call it). You see images of people’s heads photoshopped onto other people’s bodies as well as other off topic discussions If any of the other rooms go off topic, someone, usually Mike Burns, will chime in with WC reminding us that the current chat belongs in the watercooler room.

These Campfire rooms provide a non interruptive internal dialogue. People can look into the room when they want to and ignore it when they’re busy coding (or designing).

Pace

One of my first days here, someone was explicitly told not to work on a client project on the weekend. This threw me for a loop. Shouldn’t a company want its employees to work all hours of the day?  The thing is that thoughtbot understands that the best code is written during bank hours. This doesn’t mean that thoughtbot employees don’t code at home. Everyone is encouraged to work on open source and side projects at home; however, all client work is done during bank hours when we are writing our best code.

A better way to build software

One of thoughtbot’s informal mottos is there is a better way to build software. After 5 weeks here I can tell you that the fine folks here have got something right. They write great code in a great atmosphere with no stress.

Launching Trajectory: Communication Builds Better Software

Over the past 8 years, we’ve used many tools for project communication and planning and we tried very hard to not write our own. The latest combination was Basecamp and Pivotal Tracker. Basecamp was great for discussion and communication. Pivotal Tracker was great for user stories and emergent planning.

However, we’ve grown tired of having one tool that designers love, one tool that developers love, and no tool that clients love.

I’m excited to take the lid off of our newest product, Trajectory.

Trajectory is an agile planning tool that helps teams discuss and plan their projects in a realistic, structured way.

We set out last summer to create something which met the following goals:

• Encourage conversation. The ability to start with a feature idea, and have a real conversation that defines exactly what to build and results in a story that describes what that is.
• Embody a clear workflow. A better system for people to know exactly what to work on next and do so in a way that designers, developers and clients all agree makes sense.
• Look and work great. Be easy to understand, embrace workflow and linkability, and be enjoyable to use.
• Track velocity and have emergent iterations.  A way for all team members to know where things really stand, and what momentum looks like.

We created Trajectory to solve our own problems. We now use it on all of our projects. Maybe it can solve your problems too. I invite you to learn more and give it a try for free today. If you’re currently using Pivotal Tracker, you can import your project and get up and running in a matter of minutes.

Many thanks to all the designers and developers at thoughtbot who have worked on this since last summer’s CapeCo.de, our clients who were the early, enthusiastic alpha testers, and our designer and developer friends who have helped us work through bugs and add polish in the last few weeks.