Category : Android

in Android, Développement logiciel

Codapalooza – Mes impressions

La première édition de codapalooza est terminée… et après 15 heures de sommeil et deux jours de calmes, je peux enfin donner mes impressions. Pour ce faire voici en gros le déroulement de mes 32 heures de développement.

Vendredi 9h

- Arrivée au bureau, je suis le seul de mon équipe, mais ce n’est pas grave, car ça me laisse le temps de parler aux autres équipes… et déjà la compétition amicale commence entre moi et rankinternationalgirl (mon équipe initiale, que j’ai quittée, car je voulais apprendre android) …

Vendredi 9h14

- Oh non la machine à café est en réparation, comment allons nous faire pour survivre… Je pars au Tim Hortons acheter 20 tasses de café… la madame du Tim n’était pas contente, car il y avait beaucoup de client et je vide toutes ses cruches.

Vendredi 9h45

- Ouverture officielle du codapalooza, le reste de mon équipe arrive et on commence la première activité de création … soit décorer notre salle ou pendant 32heures nous allons coder et s’amuser. Merci à Simon, Monsieur Poteau notre médiateur en cas de conflit prend naissance.

Vendredi 10h15

- On commence à coder et manger des cochonneries. On divise l’équipe en deux pour faire du binôme. Carl Létouneau joue le rôle du professeur, car c’est lui qui a le plus d’expérience avec Android. On commence à coder le Timebox.

Vendredi 12h30

- Même si on n’a pas faim, on se commande de la bonne bouffe grasse pour notre pause.

Vendredi 13h30

- On recommence à coder. Notre mission terminer le Timebox pour pouvoir le mettre sur le market d’Android pour le démo au groupe à 18h30.

Vendredi 18h18

- On génère l’apk avec la clé pour pouvoir mettre l’application sur le market.

Vendredi 18h22

-  On Upload l’apk sur le Market, mais problème on n’a pas rentré le numéro de version et on n’a pas une image 512×512 qui est obligatoire sur le market. On demande à notre maitre graphiste Guillaume de nous fournir une image. On refait l’apk

Vendredi 18h27

- Notre application est sur le market High-Fives de l’équipe on peut respirer.

Vendredi 18h30

- Démonstration de notre application aux autres équipes… Yes, rankinternationalgirl a pas de démo à faire… mais j’ai vu ce qu’ils ont commencé et ça promet d’être vraiment beau.  Apres la demo on se remet a coder.

Vendredi 22h

-  On code toujours, l’équipe du site web codapolooza décide de mettre de la bonne musique, mais voila que l’équipe Pyxis Sosoft viens chialer, car ils ne sont pas capables de se concentrer puisque la musique est trop forte. La guerre entre les vieux et les jeunes commence :) …

Samedi 2h

- Y a personne qui veut aller au Paintball ou go-kart ouvert 24h. Sniff Sniff…

Samedi 9h

- Je suis pu capable c’est l’heure de la power sieste.

Samedi 10h

- C’est le réveille et on recommence a coder.

Samedi 16h

- L’énergie n’y est plus je décide de quitter pour la maison… je roule un peu, mon char fait un drôle de bruit.. ce n’est pas vraiment grave, car il s’agit d’une poubelle. Mais oups voilà que j’ai presque pu de frein. Je tire donc mon brake a bras. Ouf ça brake … Codapalooza coder comme si c’était votre dernière ligne de code, je crois que dans mon cas cela aurait pu être vrai…

En conclusion

Durant deux jours, je me suis vraiment amusé. Je crois que cette activité a permis de renforcer l’esprit d’équipe de Pyxis. Mais aussi dans mon cas, cela m’a donné un regain d’énergie et de passion. J’ai pu apprendre à développer une application Android, mais surtout renforcer mon sentiment d’appartenance à cette merveilleuse compagnie qu’est Pyxis. De plus, ça m’a permis de réaliser qu’il est possible de toujours coder comme si c’est notre dernière ligne de code et ce même dans des moments de stress.

in Android, GreenPepper, Management, Nouvelles et événements, Scrum, Vie @ Pyxis

Agile in a Command-and-Control Organization : What to do when upper management forces overtime?

Image by MyLifeStoryMy colleague François Perron launched a very interesting discussion on our private wiki – “As a coach, what to do when executives and upper management force the project team to do over time in order to meet deadlines?”.

As you can probably guess, this initiated very interesting discussions and an obvious reaction to such an approach.

Everyone agreed that due to the project visibility and the position of the organization within its market, the project launch date was critical. Everyone also understood that the organization had very few options so nobody debated the need to achieve results. The discussion was strictly around which measures to use in an Agile context.

I’ll admit up front that I am biased toward intrinsic motivation (I really loved Drive by Dan Pink) and the fact that it is well suited for an agile environment.

As such, my first impression to the conversation that was going on were:

  • Does the organization wish that employees spend more hours at the office (attendance) or would they prefer more engagement (commitment)?
  • If their choice is to increase the hours of attendance, imposing overtime will achieve this goal while giving them a false sense of increased performance. People will show they are working longer hours but the real throughput is unlikely to be much higher. In addition, software development is a brain intensive activity and reducing the amount of rest people get is likely to increase the number of mistakes they make.
  • On the contrary, if the organization wanted more involvement, the inclusion of team members in determining the best way to achieve the results would probably come to a better decision – even possibly leading the willingness to do over time

It appears to me that by forcing overtime, the executives and senior managers will probably collect their bonus and congratulate each others in the short term only to realize in the longer term that they have simply pushed the problem forward for others to deal with – and possibly request more over time in the long run.

Share

You might be interested in these related posts:

  1. I don’t feel so good – I’m a people manager in an Agile organization
  2. Does your organization support prostitution?
  3. Defining Agile Management – part 1
in Android

Applying Lean Startup principle to Android application development

Creating good and successful mobile applications is something you learn from the market, not by reading books on how to do wonderful technical tricks on the phone. But getting an application to market is a complex endeavor which requires a level of polish to avoid bad ratings and thus, killing your good product before its even used. So, even more for mobile apps, getting to the market fast and providing constant releases with small improvements to your customers is a key to success. Agility helps us on two axis: customer development and product development.

Knowing quickly who (and where) are the customers willing to pay for your app is another key to success. You may perform educated guesses on where they’re hiding, but the best way to find your customer is through trial and errors. You have to craft a message and quickly get it to your potential customer, measure their interest and adapt your strategy. Chances are that for the same product concept, you’ll have 5 or 7 (or more) customer development iterations before you nail down your most efficient market strategy. It means that while you’re finding your target, we don’t focus on the code or technological aspects at all. We just build what’s sufficient to fulfill our market experience. Of course, through good engineering practices, you may build flexible products that may be quickly adapted to your market needs, but the market must be prioritized over the technology. If you have to rebuild everything to succeed, just do it.
To avoid unnecessary waste, you must thus perform very small iterations. In the worst case, if you have to discard your work and make a 180 degrees turn, you’ll minimize the amount of work you’ll be wasting. You have to organize your activities around delivering fast releases to your potential markets, broadcast the news and measure the result while you’re already started your next iterations using a different angle. Depending on your product, you might look at daily cycles or even continuous deployment approaches. For Android applications, we have the capacity to deploy to the market as often as we want (many times a day) as there’s no complex approval process. This is a good environment to apply lean startup principles and learn from market feedback. For small teams or other platforms, market cycles of 1 or 2 weeks may be good enough, but just remember that you’ll still need a few cycles before nailing down your target market positioning. The longer the cycle, the longer the discovery phase, the higher the cost of your product.
These principles and practices have emerged around the Lean Startup movement. In the coming weeks, we’ll be applying these agile principles on ACS derived products and provide a complete walkthrough and experience return on this blog. Stay tuned!
in Android

Slashoid.org traffic on the rise

With a few people from Pyxis Tech, we launched Slashoid.org last month. The goal was to provide a community-driven website that provides Android news that matter : interesting and unpolluted scoops that prevent you, as a reader, from subscribing to dozen of RSS feeds just to be notified of anything that is worth it in the Android community.

After a month of activity, things seem to go well. We average something like 60 unique visitors and about 150 page views per day. This is a good start, and will continue to rise as we get some visibility (From a SEO point of view, we are practically invisible). Any idea on how to improve this ?

in Android

Slashoid is one-week old, already 30+ scoops published

Slashoid has been launched less than a week ago, and more than 30 scoops have already been published. The current feedback includes :

  • Too much clutter before being able to publish a scoop (tags, ..)
  • Article publishing date/time does not work correctly
  • Impossible to delete scoops

These issues are all related to Drigg/Drupal, but we will take a look at them whenever we get some time, to check wether things can be easily fixed.

in Android

Android community: launch of Slashoid.org

With a few work collegues from Pyxis-technologies, we have decided we would use our 20% side-project time to launch an Android community.

The first visible part of our work is the launch of the Slashoid.org news website. The Launch of Slashoid post describes the intent of the website, and what we want this to be. Any kind of feedback and suggestions are more than welcome, and you can use our Slashoid Google Groups for this, for instance.

What is the next step ?

Well, we are a small team of motivated developers working from Montreal, and we would be thrilled to find partners in the area of mobile development. We can especially bring a lot of expertise in server-side application development, as well as in the agile stuff (tests, engineering practices, etc.), so we would love to collaborate on creating full-stack, mobile enabled applications. If you like the idea, do not hesitate to contact us to android@pyxis-tech.com