Lunar Logic Polska

The musings of the Lunar Logic Polska team on Ruby, Rails, Merb, Flash, Flex, Adobe Air, agile, scrum, and any other buzzwords we can think of.

How to Automate your Retrospectives!

Paul Klipp by Paul Klipp 20 February 2012

I've been intrigued by the idea of self-guided retrospectives. Imagine motivated teams that could collect and evaluate data and reach valuable conclusions without management guidance! It appealed to me in more ways than one - firstly, to my principle of empowering teams wherever I can. It also suits my personality. I'm an introverted control-freak, which means I risk manipulating situations even when I'd really rather not be involved at all. I've come across techniques by which teams could progress through a retrospective themselves, but I face the added complication that many of our projects have at least one remote team member, because our clients are usually in America or Western Europe. I seized on the idea that Kanbanery, our web-based project tracking tool, could be used to facilitate the kinds of interactions that lead to a valuable retrospective.

Our retrospectives with distributed teams were always very traditional, with either no interaction with physical objects (discussion only) or with a local proxy assisting remote participants. There's value in collecting ideas on cards and manipulating them as a group, but I don't like the necessity of treating remote team members differently.

Teams in Lunar Logic are using Kanbanery’s real-time updates features to collaborate effectively. Could we use the same familiar tools to hold a retrospective session? The answer came when I applied a TRIZ technique of reducing the environment to its bare essentials and asked what I had to work with within the constraints I set. If you're of a more philosophical bent, you might say that I asked of Kanbanery: "What is this thing in itself?"

Kanbanery is intended to visualize the flow of work through a process but essentially it is just a series of lists of items which can be moved between columns, both horizontally and vertically.

Getting Started

Items have certain distinguishing features that help organize your work:

  1. A title field with a larger description field,
  2. The avatar of the last person that handled them,
  3. Checklists, type fields, and check marks just in case you need them.

as well as a variety of other features that weren’t required while preparing for a retrospective.

A Kanbanery-powered retrospective

Thinking of Kanbanery as a series of lists gave me the clue I needed to devise the retrospective exercise.

Newly created tasks appear in the first column, so I called it the ‘Working’ column. I labeled the next column ‘Retrospective Steps’ and in it I placed the instruction cards for conducting the retrospective. There are many methods of conducting a retrospective, but my favorite is to collect data from team members about the recent history of the project, evaluate their answers, extract useful practices and discard those that were unhelpful and finally to choose a small set of those changes to implement in the next iteration. I created columns for each of these steps.

We used this process for our last Kanbanery retrospective, which I joined from home while I was ill. Here is how it works. The team members sit at laptops in a room together or in their own offices and start a live call via any teleconferencing system (we used Skype). Because of the shared Kanbanery board, all team members are equal and interact with it in the same way.

The team begins to work through the steps listed in the Retrospective Steps column:

History
  1. They set a timebox for the meeting and write it down in the title of the first card, so everyone knows when the meeting will end,
  2. Everybody reads and all agree to the retrospective prime directive,
  3. Team creates the project history by adding cards and dragging them into the History column in chronological order.

The advantage to using Kanbanery is immediately visible - everyone contributes in his or her own way and time without biasing others. Cards begin appearing like "Got our first paying user", "Migrated to new test server", and "Marcin joined the team". The avatars show who added which tasks.

Practices

When the time is up, the team members use the checkmark feature to mark the events in the history that they feel good about. The team can talk over, point by point, any ambiguities during this stage.

Afterwards the team, with the history fresh in their minds, brainstorms about the useful practices that might be associated with the highlights of the recent history, about unhelpful practices that might have led to the pitfalls they faced, and to practices they'd like to consider adding or changing to make future iterations more effective. They do this in the same way in which they built the history, by creating cards with ideas in the Helpful and Unhelpful Practices column.

Next the team talks about the practices listed and agrees on three (or any other number) which they will change going forward and they drag these to the final column, What We Will or Will Not Do. The team can look at these decisions and clarify them in terms of how they will be implemented, by whom, and when. After reaching an agreement, they can capture these ideas by using Kanbanery's “Export to PDF” function to print the decisions onto index cards easily put on the wall.

Ideas

Though I participated in the retrospective as a remote member, not only was it a very focused and well-organized retrospective, but also I felt I was actively participating because I could create my own tickets in just the same way the other team members were. The meeting stayed on time, each phase was clear and moved us inexorably to useful conclusions.

Ideally, retrospectives are very interactive activities that take place with everyone in the same room, finding solutions and exposing truths hands-on with appropriate visual tools, but that’s not always possible in this day of remote work and global teams. Here’s a new technique to add to your remote development toolkit. Let us know how it works for you in the comments.

Navegas: Connecting the World of Music

Jakub Suder by Jakub Suder 6 February 2012

Working on a project with a strict deadline that isn't too far away isn't something that we developers like to do, to put it mildly. So when Lutz Villalba-Adorno, a German entrepreneur, contacted us in December with a project that had to be ready for the Midem music conference on 28th January, we knew it was going to be a challenge. But the project just seemed too interesting to refuse…

The application, which was originally implemented by another company from Poland, is called Navegas and is a web-based music player that lets you easily play music from various online sources, arranged in a single playlist. Currently it supports YouTube and SoundCloud APIs, and also a new Berlin-based online radio service called Aupeo which we've integrated; additionally, you can mix music files from your local disk with those from the web. The app currently has full support only for Chrome, although most features should also work in latest Firefox and other modern browsers.

We knew from the beginning that we wouldn't be able to add every feature and improvement we wanted, so we had to keep it simple and focus on the essentials. We've determined the set of features that were the "must haves" – e.g. the Aupeo integration, new design or the social sidebar which finds links to music videos posted by your Twitter or Facebook friends. We had to constantly remind ourselves that it's logistically impossible to do everything in time – it was sometimes painful to ignore some nice ideas for improvements, but it was the only way we could meet the deadline.

There were some technical challenges too. For example, the Aupeo API is very fresh and we were probably the first ones apart from its creators to use it, so there was no open source code available and we had to write it ourselves. But there were also some bright sides – you can't really complain if your work not just allows but actually requires you to listen to music all day :)

Fortunately, we managed to get everything ready in time before the conference, and Lutz could proudly present the new version to the attendees. The app has now more features, looks much better than it did before, and it works faster. We even managed to make the code a bit more maintainable in the meantime, which, as you may know, is especially difficult when you're working under time pressure and there's a constant temptation to cut corners to finish the work faster.

Overall, the project was a great success – we all had a lot of fun working on it, we've learned a lot, and we'd love to do that again in future. We're also hoping more users will start using it regularly – some of us certainly will!

Like in real life, your second big love is even better! The folks at LLP did an awesome job with limited resources (time + budget) but most importantly - inspired me and Navegas! Always again!
– Lutz Villalba-Adorno

Urban noise levels at last measurable - thanks to AirCasting!

Mirek Woźniak by Mirek Woźniak 31 January 2012

Have you ever wondered how loud, exactly, is that noisy crossroads that prevents you from having a well-deserved sleep? Is it really comparable to a herd of starting jumbo-jets pursued by a swarm of fighter planes? How could anyone put up with this madness?

Worry not - we’ve got a solution to your problem and it’s called AirCasting.

AirCasting is an Android application that measures noise pollution. It’s a light, flexible and free-for-all Android app we created for HabitatMap.org with funding from Google’s Charitable Giving Fund of Tides Foundation.

AirCasters measure sound levels, which they can choose to contribute to a crowd sourced map of noise pollution. This allows everyone to see the best place to either walk your dog, wind down and meet your mates or, simply, test your brand new protective earplugs.

All right, all right, you may say. Buzzwords don’t impress me anymore. I would like some facts. How does it work in practice?

Sound level measurement started in New York City. Its inhabitants complained about noise to a City hotline. The usual hustle & bustle affected their sleep, health and overall well-being. As a tool to justify their claims, AirCasting becomes a vessel for public opinion. Local authorities may dismiss one claim unsupported by any evidence, but what about hundreds of noise pollution reports made on the spot?

AirCasting has been developed by three Lunar Logic pros: Paweł, Marcin and Grzesiek (he was testing the app). I’ve asked Paweł some specific questions about AirCasting.

Mirek: What does AirCasting do, in a nutshell?
Paweł: AirCasting is a platform for sharing and visualising environmental data. Currently the only supported kind of data are noise levels. These can be obtained by users with their phones and then shared through our website.
M: Which parts of the smartphone does it use?
P: Most prominently we are using the microphone to gather noise level data. Other than that we are using Google Maps to visualise the data the user and others have gathered.
M: Are there any planned extensions for the app?
P: The app is planned to support a wide range of environmental sensors with which it will connect via Bluetooth. The one that's being engineered right now is a gas sensor for measuring pollutant concentrations in the air.

AirCasting has been live since 20th December 2011 and is available free from the Android market. The source code is available under GPL:

https://github.com/LunarLogicPolska/AirCastingAndroidClient https://github.com/LunarLogicPolska/AirCasting

Why we built 'Engage!' - a Rails Engine for User Engagement

Paul Klipp by Paul Klipp 25 January 2012

Most web startups struggle and many fail. For almost a decade, I've been watching it happen up close. As the owner of a custom web development agency I've had front-row seats to rare moments of glory and spectacular failures. When I encountered the customer-centric approach promoted by Steve Blank in The Four Steps to the Epiphany and more recently popularized by Eric Ries in The Lean Startup, I was excited, because it described so nicely a solution to many of the problems I've witnessed over years of watching startups launch. I've seen founders blinded by the brilliance of their own vision fail to adapt to the demands of their users and miss crucial opportunities to adapt, or pivot, in Lean Startup jargon.

The idea of the customer-centric approach is to build a product largely driven by feedback from users. This way you have a successful product that you can be sure solves real user problems.

In 2009, we built one of the first online Kanban board applications because we needed one to work with remote clients and nothing like that existed at the time. We later decided to offer the product to the public and for the first time I was the product manager of a web startup and I could apply principles I had learnt over a decade in software development. Initially, my decisions about Kanbanery were primarily driven by principles such as team empowerment, flexibility, transparency, trust, and ease of use. For the details, however, I looked to user feedback.

Getting that user feedback would prove a major challenge. What tools could be used to obtain the necessary feedback from users in order to overcome the challenges of our first product? It was in answering this challenge that the second product we created emerged: the Engage! engine for user engagement.

Like other startups, we had two alternative solutions to the problem of obtaining user feedback. The first solution was to use a hosted service such as GetSatisfaction or UserVoice while the second solution would mean developing our own support tools from scratch.

I didn't want to distract us from our main task of working on Kanbanery, so I opted for the hosted solution but frustration was quick to set in. The frustration was largely due to the same problems most companies face with the use of one-size-fits-all hosted applications, in that they offer a limited range of customization. Also, using this tool meant that users had to leave our application and create a new account on another application in order to provide feedback and this confused a fair number of users. I was also faced with an awkward financial decision. Any of the 30 people in my company might help to support users by answering questions or engaging with them in the feedback forum, but at $25 or more per person per month, I had to decide who would get accounts and who wouldn't.

We're about to change all of that with our own software solution to user feedback and engagement aptly named 'Engage!'.

'Engage!' is customer engagement tool that plugs seamlessly into any Ruby on Rails application running Rails 3.1 or higher. It can work right out of the box with a simple installation and configuration script, but it's designed to be easily extensible and skinnable. It has all the basic features you'd expect from a ticket tracking and customer support forum but no more.

If you have half an hour to spend installing it, it will just work, but if you want to add one more feature or change the style to match your site, you easily can. It will also tie into your own authentication service for a seamless user experience, or you can use it's own built-in authentication system if your application doesn't require users to have accounts.

'Engage!' is a Rails Engine, which means it's a stand-alone application that can be added to any Rails 3.1 or higher application as easily as installing a gem. The best part is, the code will be free to non-profit organizations and open source projects, and a lifetime license will be available to web startups for a low, one-time fee. You can have as many users as you like and customize it to your heart's content without ever paying again.

If you're interested, sign up at engage.llp.pl and we'll contact you as soon as the first version is ready to release. We'll let you know when you can download it for free and start hacking at it as you like. We'll only ask you to pay for it if you install it in a commercial product. We'll be inviting beta testers to use it free of charge, so please let us know if you're interested.

If you have any questions about 'Engage!' or suggestions, we'd love to hear them. Just use the comments below.

iOS development screencast

Jakub Suder by Jakub Suder 19 January 2012

Everyone at Lunar Logic is good at something. And since no one is good at everything, it's nice to be able to share the knowledge and skills.

One of the ways we do that is an internal event we call "workshops". Technically, these aren't workshops in the strict sense, but rather technical presentations with a lot of examples, where someone explains to everyone interested how to use some kind of framework or technology.

I've recently done one such workshop, titled "Introduction to iOS development". This time, we've decided to make an experiment and record it as a screencast, and share it with everyone. We think it worked out pretty well – sorry for the sound quality though, let's hope it will be better next time.

The screencast is mostly intended for people who haven't done much iOS development (or none at all), to give them a general idea what it looks like. It first shows how to generate an application from a template, what this application does and what each part of code is for. Then I quickly go through the code of an example application – a simple client for RubyTime, our time tracking webapp. I also show some examples how to use LunarToolkit, an ObjC library we've shared recently on GitHub (note: it's referred to by its old name "PsiToolkit" in the screencast). If you've already written an app or two in UIKit, you might want to skip straight to around 22:00 where the RubyTime part starts.

If you're just starting with iPhone development and ObjC code seems to you like something written by aliens, I also recommend that you read this blog post I've written some time ago, which explains the basics of the language to developers familiar with some other popular languages.

If you want to play with the code yourself, here are the GitHub projects: