Sexy 6 Agile Meeting Tips for Google Hangout Usage

So, your team is remote, or maybe just out of the office for the day. Never fear, get everyone on G+ (Google+) to use the Hangout feature.

I have used this feature numerous times for standups, kickoff, estimation, and half-day planning meetings. It’s a great tool and its free. You can share your screen, see video, hear audio from everyone on the team (in the meeting of course). But with great power comes confusion.

So here are some “pro-tips*” on how to improve the experience for all your team members using the hangout feature in G+.

1 – Use headphones. By using headphones your computer speakers wont feedback into the microphone on your computer, thus eliminating that annoying echo. the annoying echo. the annoying echo
2 – You can use the microphone on your laptop but please put your laptop on a table. We dont want to hear it rubbing against your legs, or other noises from that general area.
3 – Use an external mic if you have one, if not don’t worry. This is just a “super all-pro**” move. Add a pop guard to the mic to really be a hotdog.
4 – Be aware of what is behind you, your camera will display things besides you. So clean up the moldy pizza and empty beer bottles, or just position the camera strategically to point away from the illicit activities going on in your “office”.
5 – Give everyone 10 minutes the first time they use hangouts to play with all the silly hats and overlays. It’s going to happen, don’t fight it.
6 – Pay attention. No need talking forever and being on mute. You won’t look cool, even if you have a mic and a pop guard.

So those are my Sexy 6 Agile Meeting Tips for Google Hangout Usage

As always, feel free to comment.

* The term “pro-tip” is so annoying and condescending 

** And you thought “pro-tip” was bad.

The Athletic Guide to Agile – 360Flex

I just got back from 360Flex in Denver, what an awesome time.  I highly recommend attending a 360Flex Conference.

My presentation was “The Athletic Guide to Agile.”  The premise of the presentation was to explain Agile using a metaphor.  The metaphor for this presentation was sports.  It had become obvious to me, over the years, that the explanation of Agile was becoming convoluted and confusing for some.  The problem I saw was people trying to relate Agile principles to Waterfall, something they already knew.  Agile and Waterfall don’t really relate. So I thought that maybe it was time to change that and try and relate Agile to something completely different than Waterfall.

I am still refining the athletic metaphor for introducing Agile, and I have a few other metaphors in the works as well.  Here is the presentation slide deck:

Download - Athletic Guide To Agile – AdrianPomilio

Photos – Yogi sayin it all

Video - not yet available

It is important to understand that this was a live presentation, and it covers many areas of Agile but not every aspect.  The areas that I cover are the parts that cause a bit of confusion.  I am always looking for feedback so please feel free to leave comments.

My Ruby and Rails Journey – Part 1

DISCLAIMER –  I want to clarify the title that I will be using for this series of posts.  I know what Ruby on Rails is, but I am taking a different approach.  I am learning Ruby, the language, while also working with Rails, the framework.  So I am digging through the famous Pickaxe book to learn about the language of Ruby and I am also working through Rails3 in Action. This is the story of my journey.

Most of my “career” as a developer has been focused on the frontend (e.g. JavaScript, CSS, HTML, ActionScript and Flex).  But I have also been working with many different backend technologies (e.g. Coldfusion, PHP, Java, Groovy/Grails).  The reason I am always looking at backend technologies is to improve my efficiency in proving out frontend solutions.  After all, a UI with no backend is about as useful as a Powerpoint or Photoshop file, which makes it hard to drive technical change with decision makers.  Trust me, if you are a frontend developer or designer, and all you ever do is create pictures and never implement; no one will care about your technical opinion.  You will fail.  Time to get on with the post..

Continue reading