Friday, September 2, 2011

Offline Google Docs - Too little too late

Google (re)announced offline feature on Google docs recently. For those who noticed, would also remember that Google Gears was decommissioned nearly an year ago, hence this new HTML 5 version took too long to get to beta status. Is the new offline version worth the wait?

I guess not..here are some important notes about new offline capability (source: Google Docs help)

  • You'll need to Set up Docs offline from your Documents List to start accessing your documents and spreadsheets without an Internet connection.
  • Offline access is available in Chrome only. (Oops!)
  • Offline access is available only for documents and spreadsheets. Presentations, drawings and other items from your Documents List are not available offline at this time. 
  • (humm..okay..it's in Beta anyway)
  • Documents and spreadsheets are only available in view-only mode. You must restore your Internet connection to make any edits. (??!@#? - useless..I stopped reading next two points)
  • You can't create new documents and spreadsheets while you're offline.
  • You'll need to allow offline access separately on each computer where you want to view your Google Docs offline.

I wish Evernote comes up with a spreadsheet application. Till then, I will stick to the 'online' google docs..

Tuesday, August 30, 2011

Best Practices for Agile Managers

Agile Managers! Sounds like an Oxymoron?

In reality, there are organizations which have functional or product manager roles which do not fit under the traditional roles defined by agile methods. Jurgen Appelo started a thread (on his blog) to capture the best practices for a newly minted agile manager.

Here is what I think (as interpreted from the Agile principles)..please add on if I missed anything important

An agile manager should:


  • Focus on optimizing the "business value" being delivered by the agile team. You may decide on your own metrics for business value (qualitative, quantitative or gut feel), but key is to have a sense ..at all times
  • Pursue delivery of a fully working software at end of each sprint
  • Periodically (pick your own frequency) Review and optimize the 'Done' list
  • Identify key stakeholders and ensure their participation (as required) during the entire project life cycle
  • Set expectations clearly (with all stakeholders), manage expectations to avoid last minute surprises
  • Make an genuine effort to understand all aspects of the project (example: if you are not technical, don't avoid the architecture all together, try to gather just enough understanding)
  • Set up information radiators (to convey real time information to all stakeholders)
  • Focus on attaining a sustainable velocity quickly and early in the project life-cycle (it helps in planning and avoids burn outs)
  • Watch out for 'Smells' (things which might be an impediment to agile practices


Last but not the least, an agile manager should demonstrate thought leadership and show genuine concern for professional growth of each member of the team. It's essential for the agile manager to win the respect of the team. You would always be better of by being a 'Leader' rather than a 'Manager'

Monday, August 29, 2011

Myths of agility

In the context of Software development, the term “agility” is widely misunderstood. Even many seasoned software engineers associate agility with complex process changes to adopt ‘Agile’ methods such as XP, SCRUM, DSDM, FDD and Crystal etc. But in reality, this specious association can’t be any farther from the truth. Before you join the ‘Agile’ bandwagon and start reading a XP or SCRUM book, it is essential for you to understand the fine line between ‘Agile methods’ and being ‘agile’.

Being ‘agile’ is a state where your organization is completely adaptive to changing environment. You are driven by business value. Your entire infrastructure, not just IT department but also other business functions such as sales, marketing, finance, production, procurement etc look to maximize the business value generated for the organizations. All it requires certain level of maturity in the way you work, nothing else matters. In the context of Software development, you can adopt any methodology you like (yes, even waterfall, RUP) as long as you focus on a) maximizing “Business value” instead of “through-put” b) being “Adaptive” instead of being “Predictive” c) and Continuous sustainable improvement. All that ‘Agile’ methods do, is to enable some of the aforesaid attributes a bit more than any other traditional methods (such as Waterfall, RUP etc).

Looking from a holistic perspective, being agile is the end goal of all organization and adopting an ‘Agile’ method (for that matter any other software development method) is just a mean to achieve the end goal. However it’s unfortunate to see many organizations blindly adopt XP or Scrum process without giving sufficient thoughts to the values required to make an organization truly agile. It is, therefore obvious that such changes fail over long run.

If you care for being agile, have a look at the Principles behind agile methods. Have a open discussion within your team to determine what each principle means to you as a group. Look at your existing processes and see if they adhere to these principles (fully or partially). Start working on those processes which needs refinement. Change if you must, but only after fully grasping what change means to the overall organization. Rest assured you will ensure a successful and sustainable process change towards being truly agile.

Sunday, July 24, 2011

Tuesday, July 5, 2011

Software G Forces: The effects of acceleration

Kent Beck delivered this talk at USENIX 2011

Abstract:
- Effective software engineering is a relative term. As deployment cycles shrink, what constitutes effective software engineering changes radically. Developers must reflect on and choose the right set of software engineering practices based on their release cycle

Saturday, June 4, 2011

Carson's Law

Learnt something new about modern day innovation.

Carson's Law (by Curtis Carlson, the C.E.O. of SRI International, in Silicon Valley) states:

“In a world where so many people now have access to education and cheap tools of innovation, innovation that happens from the bottom up tends to be chaotic but smart. Innovation that happens from the top down tends to be orderly but dumb.”

As a result, says Carlson, the sweet spot for innovation today is “moving down,” closer to the people, not up, because all the people together are smarter than anyone alone and all the people now have the tools to invent and collaborate.

My 2 cents:
Modern day leadership is all about creating a conducive environment where the bottoms up innovations are encouraged and validated real time.

thoughts?