More stuff about Google

Following up on my twitter post...  

on the other hand is the fact that Google will keep creating weird features in Gmail - last example is this inbox feature for slow connection... 

How many Google savvy users are still on 3200 bauds modem?  Admitedly the value of this feature is of limited reach...

There are a bunch of productivity related features that are in their funnel I am sure, I for one keep pushing features their way. 

Last one was something inspired from the Syndeo Project Server we created back in the days...  It's the ability to put email threads on a stack or on a symbolic push pin board that you can later pick and add as attachments to other emails. 

I do not know about you but I keep having to do this, digging out threads and then forwarding them arround.    Of course I can send them individually but in many cases it makes sense to keep them together to keep the context in one bundle. 

Been waiting for this and other similar productivity enhancement to gmail... Maybe I am alone with this need who knows?

 

You can contribute feature list to Google at 

http://mail.google.com/support/bin/static.py?page=suggestions.cs

Google Tasks

This is something that I have been waiting for a long time now... 

Last week Google released an update that shows your tasks in your calendar.  Kind of mandatory if you want to get them done! (granted that you at least look at your calendar once a day...)

Read more about it here. 

OSEF - Software as a Service

Yesterday was the event on SaaS, we had a very information savvy group and our panelists, as usual, have helped demystifying SaaS for the rest of us. 

A couple highlights for me from the discussion:

SaaS is raising the bar with respect to the quality of the development process.  

I was not expecting that one.  But when you think about it, delivering software (read: value) frequently puts pressure on the need for the development team to create quality software at all time not relying as much on an intense and lengthy verification process.  In this context, successful SaaS product teams have better software development processes.  We did not dive into the details of it, but risk mitigation and quality assurance strategies such as: user centered design, code review, agile methodologies, automated unit tests are certainly part of the mix.

Lesson: When building software in the SaaS model, ensuring you have a great software development process should increase your odds of getting the most returns out of your SaaS initiatives.

Your development team are on the operation team. 

We had an extensive discussion on the shift that SaaS causes on the involvement of the development team.  This is a no brainer when you think about it.   When releasing software on a monthly basis (or even faster) to your customers, you must have your development team available at all time, otherwise who's going to take care of the unexpected failure occurring on a Sunday night?  This is a clear distinction over the more traditional delivery model of shrink wrapped software.  

Lesson: Ensure you are engaging your development team for more than "simply" building the software.  They must be available to handle software failures at all time.  

Hope to see you at the next OSEF, the last of this season (for real this time!) 

If you are not member, please request membership through http://www.meetup.com/ottawasef/

Cheers! 

The power of your team

I posted earlier this week on The Macadamian Files blog. 

Beside the technical lesson in there, this post if omitting - by design -  a gem that jumped right in my face the minute I got my answer. 

The hidden gem is a practice that consists of leveraging your entire team experience.   This is how I got the answer to my question.  Powerful collaboration. 

Here is the practice definition:

Description

• Offer a mechanism to reach out to the experts in your organization.

When to Apply?

• Knowledge exists in the org but it is not maximized and software errors or delays are caused due to that. 
  
• You have a distributed team.

What needs to be done?

• Define communication channels, it could be mailing lists, IRC channels, forums, etc...
  
• Ask your experts to participate and offer to everyone else to volunteer.

We did not set up that system from day 1 at Macadamian, it's only when we started to be distributed and somewhat larger that it became clearer that we needed channels to our collecctive brains.  

At Macadamian, we created 3 specialized mailing lists: engineering, usability and quality assurance. 

This is the mechanism that allowed me to get the answer to the problem I was blogging about on The Macadamian Files.   These mailing lists are now part of our problem solving process.

While you dig on the web you also email the group,  you are likely to be surprised by the volume of knowledge of your organization.  

Macadamian win OCRI's - Service Company of the year!

Another beautiful day! Presented to Macadamian , whose approach helps software product development managers attain the mix of skill, speed, quality and cost they need to be successful. To Macadamian, success means working hard to raise the odds of other companies' products succeeding in the marketplace. http://www.ottawasun.com/Money/2009/04/09/9065971.html

OSEF - Delivering Software Faster

Yesterday was the 6th event of the year.  We had a great pannel!

Adrian Cho, Development Manager, Rational Team Concert at IBM 
(see his work at http://www.jazzproces...)

Jason Mawdsley, Director of Project Management and Certified Scrum Master at Macadamian 
(see his blog http://ontherighttrac...)

John Fait, Lead Software Developer, Enterprise and Developer Business Unit at Adobe

We looked at ways that you can use in your oganization to "Deliver Software Faster".  Interrestingly enough, the discussion kept being steered towards Agile methods, Scrum in particular - probably a sign of our time! 

In the end Scrum has not - as is - been identified as the silver bullet though, but instead, an custom version that fits your organization might very well be YOUR silver bullet. 

An interresting shift that happenned early in the discussion consisted of focusing not on "Delivering Software Faster" but more "Delivering Value Faster".   

With no surprise, this consists of putting the user of the product as a key component in the product evolution, a couple methodologies were discussed:

• User Centered Design Methodology
• SyncDev

Last but not least, people.  It's only with a great team that you will accomplish great things.  Make sure that:

1. your hiring process allows you to get the best out there,
2. your people are doing things they like,
3. they are well trained.  

But first and foremost, have inspiring leaders that will help them to be self motivated at achieving theirs and your organization goals. 

Micro Deliverables

The Tech Republic had an interresting post earlier this month:  Monitor Project Progress by using micro-deliverables.

This is a lesson we made almost two years ago.  Being mostly software centric, we refer to this as the "patch a day principle".   We even push it further than the author of the post by targetting deliverables on a "almost daily basis".

1. Amongst developers, the code is an awesome communiation tools.  
   
2. You cannot catch an error much sooner than the next day it is commited.
3. In distributed contexts, the time zones often plays in your advantages and review happens over nights. 

As you can see by the name of the "principle" this is something very software engineering centric.   There is no reason to not apply this accross all roles involved in a project though: Documentation, QA and UX. 

This is about predictability and this is a requirement common to all activities on a project.   Make your project lead and your customer happy through a predictable team using frequent micro-deliverables!