Agile is Good... But Pay Attention to End Customers
The Agile Zone is brought to you in partnership with JetBrains. Learn how Agile Boards in YouTrack are designed to help teams plan, visualize and manage their work in an efficient manner, with support for both Scrum and Kanban processes.
I can't call myself an "agilist", as I'm rather a hybrid kind of software architect. But I like many aspects of the agile methods and I constantly try to adopt more of them. For instance, I like making frequent releases when I actually have control of the project (which includes having tests with good coverage). For blueBill Mobile, my first Android project, I've rolled out three versions in two weeks, which means one per week. As mobile projects are small, it makes sense to have a more frequent release cycle as it happens for desktop or enterprise stuff.
But a few days ago, I read a post on the blog of an italian journalist. He's not focused in technology, but he was talking about the iPad launch in Italy and the fact that many nation-wide newspapers were saying they were ready with their specific applications. He commented about one of them as being poor, and then "they released a new version after a few hours". This was intended to be a critique. Now, I don't own an iPad and maybe the application he was referring to was really bad, but this made me think that, from the perspective of an end customer, frequent releases might sound not good at all. Instead, they could be perceived as the constant, and failing, attempt to fix bugs.
Now, let's recall that agile methods are also about communication and sharing values. With a regular customer, you can go agile as you share the way you work and you have educated the customer so he expects frequent releases to be delivering more and more value, rather than a problematic try to pursue and fix bugs. But you can't educate and end customer. Actually, it's likely that you'll have a contact with an extremely small fraction of them - I don't expect that they'll go and read the change log for each release - supposing they understand what a change log is - and, at the moment, the tools in the Android Market aren't helping at all in communicating with customers.
After sharing my issues with a few guys in the Java Posse mailing list, I concluded that sharing the agile frequent release cycle with blueBill Mobile customers might be dangerous for my application. Obviously, I'll keep being agile, and have frequent releases, but I'll not publish them to the Market immediately. I've still to figure out a reasonable lapse for the end customer perspective - it could be one or two months.
Thanks to the fact that the Android Market is not the exclusive source of software, I will anyway announce and make available the frequent releases on the website. If a customer got to the website, I suppose I can try to explain him what's happening and, if he feels comfortable, he can directly download and install any fresh stuff. BTW, this is a chance that iPhone developer don't have, AFAIK.
In any case, I think that Google should really work on these subtle aspects. After all they're also a communication company and should have the know-how to roll out effective solutions to the problem.