Flowdock is a real-time collaboration web app directed to teams. It allows co-workers to work together closely and coexist in the same space within their browser. Right now it’s going through an alpha stage where some 10 companies are trying it out and giving feedback.

The public beta is to be expected later this year. Before that we want to share some of the ways of using Flowdock with you. Today I’ll show you some ways to use one of the coolest features in Flowdock, tagging.

Lowering the barrier

We’ve noticed that lots of useful content is generated in instant Messaging, e-mail, Twitter and other medias. In a couple of minutes it may be totally forgotten, because it’s in no-one’s interest to structure that data to a wiki page, or even worse, to a Word document.

Imagine if logging a simple bug would mean just writing a short description to your group chat and ending the line with a #bug hashtag? With Flowdock’s team chat, that’s exactly how it works.

Tags can be added as hashtags or afterwards with a separate UI by anyone in your team. This helps you to ensure that all relevant content is tagged properly.

Information always accessible

All tagged content, including chat, files, content from e-mails etc. can be found using Flowser, an app-in-app of Flowdock for information management. When a bug is closed, for example, the user can simply remove the #bug tag.

When I’m looking for a screenshot of Flowdock for a blog post, I’m going to open Flowser and search for #screenshot. If I wanted to find screenshots only about our future promo site, I could just search for #screenshot #promo.

All this has truly changed our way of working. Now I’ll never forget who’s managing contracts at one of our customers, because that information is tagged in our flow. And tagging that information didn’t cost me anything.

Photo by ElbridgeGerry

We here at Nodeta work incrementally. We standardly split all of our development efforts into smaller and smaller increments in order to better grasp what is planned, what is achieved and how well the two match. We do small things to get big things done.

When you’re making a piece of software, the first version usually sucks. It doesn’t matter, if you whipped the software up in an afternoon, or if you spent thousands of man months to develop it from point Nothing to point Done, it’s gonna suck. Instead, you need to do it in small increments, and then you need to throw most of those increments away and do them again. The bigger the increment is, the more likely it is that it will be made of suck, and you’ll need to do it again.

You need to start with minimal features, then build. Test your ideas early with real users when possible and use that feedback to re-create.

In a personal sense, it’s not always so simple to adopt the concept of incrementality to your work process. Many would like to have their handiwork done, polished, framed and fixated before showing it to anyone.

Team members and incrementality

In Scrum, stories (which group smaller tasks in a single sprint) are given acceptance criteria, so that it’s easy to check how well the story has been completed or implemented. You can use these following criteria to either test your team or potential members for their abilities to work incrementally.

You, as a software developer, need to realize that your code is not valuable in itself, it is only valuable in what it can do, and if what it does is not useful that week, it has no value. No matter how long you pondered to find the best and most beautiful solution to the problem you had. Not even if your code flows down the misty meadows like a clear and concise natural language, if it is not a part of a proven feature, it’s worthless. You need to remove it and move on. Move to the next piece of code. You need to start feeling good about your ability to produce good code, and not about your code itself. Code proudly with the backspace!

You, as a manager, need to understand that your funky new features are worthless if the previous features haven’t been proven good by testing them with actual customers and actual users. Features have no inherent value. If you have a feature that reaks, you need to kill it fast and hop on the do-over train. You also need to appreciate the value of incremental development, and mold the day-to-day working environment to support it.

You, as a product owner, need to be able to plan well often and in variable scopes. Any project should have a road map, on what is sometimes called ‘epic level’. That means you take the contents of the project and try to define them in as broad as terms possible, without restricting development paths. Then you need to be able to chop these epic features up into pieces with the team, and prioritize, prioritize, prioritize.

Special feature

In software development, there are no manufacturing costs. That’s why do-overs are not only possible but smart. Incrementality is a special feature of software development, and one of the reasons why any comparisons to, say, construction development, lead to horrendous distortions of the truth. Think about it, if you could start building your house by simply setting up the planned facade and if you could then change it without material costs, wouldn’t you do it like that? Of course you would.