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!

MS Live Workspace

A few of us at Macadamian have been experimenting with the Microsoft Live Workspace thingy... Sort of Google Docs for MS Office users.

This is still very beta and several key collaboration features existing in Google Docs are missing. To name a few:

1. Folders: this was the first annoyance, when you collaborate on a project you want to keep things clean otherwise it gets... messy... one need a way to organize files.
   
2. Email Collaborators: This is a low hanging fruit, when you collaborate you need to email your collaborator, why isn't this there yet? Beats me.
   
3. Notifications seems flaky: I just started to get them (took time to work) but they have no content, just a link, only partially useful.
   
4. History: Well, I have yet to find a way to see the "diff" between the versions. I do not think it's there although I am sure I read somewhere something about this.
   

All in all this is an acceptable stab at it from MS, in my opinion mainly for two reasons:

• It promotes document sharing in a rather nice and working (most of the time) way. Can we be done with sending each others documents as attachments once for all?
  
• It leverages Words and other Office tools - although most of the time overrated and overpowered for most uses - they have been adopted in organizations, keeping them around while working in the cloud makes it comfortable for most of us and it does not create the same resistance to change effect than Google Docs does.
  

This being said, the current Live Workspace offering is far from the power that we need for efficient distributed collaboration. Google seems to have a serious lead there but people wants to use Word... What can you do?

I still thinks this is far superior - event with the occasional glitches - than the staus quo of keeping sending each others documents as attachments.

With this at least you will stop asking yourself: "Am I looking at the latest version?"

Delay on send...

With the integration of Gears and the related addition of the Outbox in Google Mail, it seems that Google is ready to implement a feature "I" ;-) have requested a long time ago... "Delay on send".

This is a feature in Outlook that has allowed me in the past to fix already sent emails before they get onto their journey in the interweb...

Ultimate feedback loop for bloggers...

Following up on my last blog post...  I started wondering last week if process savvy people in the work place were the same at home.  I was thinking about this when doing the recycling duties, i.e. avoiding to put garbage in the recycling bin and vice versa... 

There is a corrolation for me.  Then I thougth wouldn't it be nice to ask arround?  Then I found this little free instant survey tool... What do you say?

Feedback loop for bloggers...

Jason's recent posts made me found out about this new feedback thingy "Reaction" that Blogger is offering. Combined with Google Analytics this is probably the ultimate feedback loop tool for bloggers that I have seen so far. 

I just turned it on on my blog.  Of course, comments are interesting an very welcome but they may be intimidating to some readers.  Ticking a check box is not as engaging but does provide valuable feedback to the blogger.  

To turn the "reactions" feature on, simply go to your template and edit the layout of your post item.   When you read a post with this, send feedback to the author, I am sure they will appreciate. 

Code Review - How to miss the point...

Sometimes your arguments just don't weitght enough in the balance... 

I had the opportunity to "attempt" to contribute to Esther Schindler's article on Code Review.  She reached out on LinkedIn and I offerred help.  Now that I am reading her article I have many dissapointments.  Mostly related to not being able to make my contributions useful. 

Right from the get go I warned her about "meeting driven" code reviews.  These code review sessions where people each bring a tree's worth of paper and then beat the s**t out of the code worked on for a month.   They generally also spend a day reading a massive and scary amount of code before the meeting, a very costly process needless to say with limited output in general (at least from my experiences 10 yrs ago at Bell Northern Research and later at Nortel).

I could see from the other contributions she was provided with that this was the route she was about to embark when talking about code reviews.   Her article is filled with reference to "weekly review meeting"... or "meeting driven" code reviews. 

A couple good take aways are:

1. Jason Cohen from Smart Bear who is talking about a code review style that makes more sense, closer to what we believe in at Macadamian. 
   
2. Someone from Google who's is suggesting to do design review before you even consider doing code review. 

If I had to write that article I would put emphasis on what has helped us here to improve quality:

1. Small and frequent code review.  Get code reviewed on a daily basis.   This ensure you catch errors as soon as possible. 
2. Do design patch review - Just In Time Design - JITD (expression first heard from the mouth of Francis Baudet's sometime in the summer of 2008... ;-) )  This process, not only ensure that the first line of code will be a valid one, but also ensure that the deveopper starting the work took a step back and thought about the code to be written before to start writting it. 
3. Tools stack.  Do not neglect the use of proper tools to do the job, emailing a patch to each other works, but now a day there are very good tools out there.   

Last but not least, for code review to be effective you need:

1. this process to be part of your culture,
2. to foster an egoless programing environment, ensure understanding of the "what's in it for me" for your developpers,
3. to not only rely on this process to ensure quality.     

First and foremost, you need to not do code review once a weeek but have this process part of your complete breakfast.