ScrumDo is a project management tool that’s built from ground up for agile teams doing Scrum. It helps you to plan your iterations, manage your backlog and visualize your progress.
If ScrumDo is your project management tool of choice, it’s now even easier to follow your team’s activity. Just follow the simple configuration instructions and all relevant activity will be streamed to Flowdock.
Naturally, the integration was built using Flowdock’s API.
Redmine is an open source project management application, which includes basic ticketing, wiki and other functionality. We’ve just released a Flowdock Redmine plugin on GitHub, which gives you a completely real-time Flowdock integration with issues and wiki.
Installation is straightforward and you can read the guide in the README.
These days at Flowdock we’re using a light, modified Kanban process to handle our everyday work. Previously, we’ve also had a lot of experience with Scrum. There are also some other strange words that try to guarantee the excellence of your software team. What all of them have in common is whiteboards and magnets. Usually you need about four identical magnets for yourself to signify which tasks you are undertaking on that particular day.
We like champagne. It’s really a no-brainer.
It also goes great on a fridge! Everyone wants an agile fridge!
Meet Wolfram Kriesing, Co-Founder of uxebu, a quickly growing JavaScript company.
In their own words, uxebu is not just another web and mobile app developer. Rather, they go head first to tackle mobile challenges of all kinds, from commercial ventures to open source projects.
Uxebu was kicked off in 2008 between 3 guys. Originally from Munich, Germany, the uxebu team has grown into a collection of developers spread across Munich, Amsterdam and Ohio.
To stay on top of their game regardless of timezones, closely-knit teamwork is a must for this agile startup. When it comes to collaboration, uxebu trusts Flowdock’s expertise.
The uxebu team was never a big fan of email. Before entering the world of Flowdock, uxebu relied on Skype and Skype chat. While Flowdock hasn’t eliminated the need for Skype calls, especially with external clients, what has changed is the way the team works together.
In Flowdock, uxebu has created separate flows, or project rooms, for each project they are working on.
“We don’t have all team members working actively on all projects, but still everyone has free access to each project’s information. If I need to follow up on a project in which I don’t have an active role, I can still access the project flow anytime I want to find the update I need”, Wolfram says.
The team discusses the everyday issues and customer updates in a general flow, but project-based flows are all about hard work. Discussion revolves around work-related details, the real techie stuff.
What makes uxebu’s work more efficient, is how they use #tags and @mentions. Working across timezones can create bottlenecks in development and communication, but Flowdock keeps you notified even when you’re asleep.
“When I open Flowdock in the morning, the comments that are important to me get highlighted. Skype just can’t do this!”, says Wolfram. “Skype’s notification was too noisy for me. In Flowdock, I have customized what types of notifications ping me.”
Connecting team members around the clock smooths out the software development process. All work related discussions take place on Flowdock, making it simple for everyone to stay on top of their game.
As Flowdock enters public beta (opens on March 10th!) we’ve begun doing continuous deployment. As an agile software development shop, we also test extensively and practice continuous integration. At the same time we need to monitor that Flowdock is running smoothly and when problems occur, we can fix them right away. All this requires fast working channels of communication so in the center of it as the hub of our team, is naturally Flowdock. I’ll walk you through our development process from the developer’s point of view.
We use git for version control. Each time someone pushes commits to a branch, an email is sent to Flowdock with tagged information on
This lets us do real-time code reviews. We habitually discuss individual commits inside Flowdock. We use a git post-receive hook to pipe the changes into Flowdock via email. The hook is available here as a gist on GitHub.
Whenever someone pushes some changes into the master branch, our continuous integration server runs all the unit tests in the project and if they do not pass, an alerting email, such as the one above, is sent to our flow. The message comes with details on who to blame so others can target the correct amount of mocking towards the culprit.
When the tests pass, the master branch is then deployed to our QA environment. All deployments send properly tagged messages to our flow in Flowdock. I can always tell what was deployed:
The QA deployment runs acceptance tests, which make sure all the important use cases function properly in a production-like environment. For acceptance tests, we use a combination of Cucumber, Selenium and RSpec. Once everything passes in QA, the deployed version is tagged a suitable candidate for production deployment. Next we do some smoke testing in QA, and finally deploy to production.
Flowdock also gives me a deployment log. For example to see front end deployments in production, I just search #deploy #production #frontend in Flowser.
Whenever something goes wrong in production, we get notifications to our flow. This way we can debug problems together, immediately when they occur.
A quick update. Along with elegant git branching, we’ve been busy taking Flowdock forward.
To show you a bit about our processes, we have been recording our daily scrum stand-ups and now compiled it all to a single time-lapsed video.
As you can see in the video, in start of each sprint we have our stories, represented as white A5s and tasks as Post-its on the left side of the whiteboard. Stories are prioritized from top to down, top being the most important.
When a task—for example, “make a time-lapse video”—is put on the board, it’s moved from left to right according to the approximate amount of work done, measured in Zörgöns™. On the most right is the “done” column, where tasks regarded as complete are moved.
Video holds about 4,5 sprints (10 weeks) of daily Scrums in 30 seconds. Check it out below.
Here is some proof to back up our overly lengthy tagline, Rails-doc is the first Rails documentation app that wasn’t developed by one guy in his underpants. Rails-doc.org has an actual team behind it – a team that employs an agile development process.
There’s hardly a better visualization of Scrum than a timelapse video! It shows the progress of our second sprint.
I think everyone who participates in Scrum ought to know the essential laws that Scrum was created to deal with. But much more important, I think that the client must acknowledge them, since I do not believe it is possible to be successful at buying software without being fully aware of these fundamental laws, coping with which is of utmost importance when it comes to developing software. It never hurts to remind oneself of the laws, that Scrum was created to deal with:
Where your mind sees a square, the next guy’s sees a circle. Specifications should be documented but the maker of the specifications has to be fully available for the development team to ask questions and to communicate eye-to-eye. The maker of the specifications, who should be or at least strive to be the best expert of the actual requirements, absolutely cannot be a stranger to the development team.
The users may also believe they need something they in actuality have no use for. Users customarily claim they need a feature for a business requirement that can often be covered much better by a very different feature. Users cannot make specifications. Users’ feature requests obviously still need to be heard so the developers can come up with the right feature to cover the business requirement and empower the user to reach his goal. Users’ goals and the software’s business requirements should be crystal clear to the developers and the developers need to show interest towards them.
Important to acknowledge, and just as important it is to understand that regardless of the impossibility, full test coverage, automated and manual, should be attempted to achieve. The specification of a software is always a work-in-progress, even after the software itself is ‘completed’. This needs to be accepted and specification documents need to be constantly edited during the process of developing the software.
