Monday, May 21, 2012

Distributed Teams and Scrum

With outsourcing in vogue and Scrum/Agile methodology in full wind, how to get benefits of both? This is the question asked by each customer and each out sourcing company, product owner, scrum master, pig, chicken and virtually every stake holder.

A distributed scrum looks like:

With Distributed teams two more variables get added to SDLC, so the SCUM based development. These are reduction in communication richness and time difference. Being to be true engineer, let understand one at a time and then draw a unified picture.

On the scale of communication richness, different communication medium can be depicted as:

In distributed team, richness of communication needs to be maintained to compensate impossibility of face to face communication.

Apart of presence of communication of medium, team should have access to communication modes at all time to reduce time and resource consumption in arranging and finding access to communication medium. A pig or chicken should not be spending time in requesting for conference room, looking for shared telephone, etc. Instead she should be focusing on her core tasks.

To further enhance the person to person comfort level, each stake holder should be posting her photo graph – not place holder in contact details ( like email, self-introduction, etc.).

To answer time difference, team should have some overlap across geo locations. This certainly reduces wait time for each stake holder. With overlap, distributed teams handover the task smoothly and burn out to team members can be avoided.

To unify the both factors, discussed above, each location can run scrum separately and one scrum of scrum certainly helps to keep all horses of chariot aligned.

To further enhance personal rapport, distributed team can have rotation policy which enables each team member to have chance to develop personal relationship with other member. Product owner should be traveling to distributed locations on regular interval.

The above mentioned measure should result in integrated scrums.

The path charted above surely will help in running distributed team in effective and efficient manner to deliver extra ordinary results.

Thursday, May 17, 2012

Book Review: The Art of Community: Building the New Age of Participation (Theory in Practice)

Book Review: The Art of Community: Building the New Age of Participation (Theory in Practice) by Jono Bacon: Publisher- O'Reilly: ISBN- 13: 978-0596156718

The Art of community building is a book from practitioner. Though Jono’s book talks talk about community focused around open source project but his experiences are readily transferable to any form of community. Book takes reader one step at a time to exhaustive understanding of on line community creation and maintenance. The ideas and practical advices elaborated in book are applicable to not only online and open source community but to non on line, business oriented communities as well. For any community manager this book is bible. Great book to lay foundation of a thriving community.

Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author. I got electronic format of book from publisher for review.

Further reading: There are several books on similar topic. Managing Online Forums: Everything You Need to Know to Create and Run Successful Community Discussion Boards , Design to Thrive: Creating Social Networks and Online Communities that Last, Online Communities Handbook: Building your business and brand on the Web, Community Building on the Web : Secret Strategies for Successful Online Communities, 18 Rules of Community Engagement: A Guide for Building Relationships and Connecting With Customers Online, The New Community Rules: Marketing on the Social Web.

One can get more information about book and related topics from:
1. Book’s web presence http://www.artofcommunityonline.org/
2. Amazon: http://www.amazon.com/The-Art-Community-Building-Participation/dp/05961567153.
Publisher -- Oreilly http://shop.oreilly.com/product/9780596157234.do 4. Jono’s site: http://www.jonobacon.org

5. Review ( 1st edition): http://www.ariadne.ac.uk/issue64/bremner-rvw

Monday, May 14, 2012

Story Point: What is important?

While assigning story points in any sprint, every single time one of the team members asks same question: On what basis story points to be assigned? I do not have perfect answer but I have come up with following list of factors which should be considered while assigning story point.

• Technical complexity
• Business complexity
• Efforts required to complete the story ( dev +test+ deployment + ...)
• Dependency within scrum team
• Dependency within project (A project might have multiple scrum teams)
• Dependency across different projects ( some of the projects might be running on waterfall model)
• Clarity in requirements
• Clarity in scope
• Urgency of story

While taking help from google, biggest issue I observe that most of the Agile/Scrum experts are talking about what not affect story points but not the what affect.

One more central themes I noticed with respect to story point: In a Scrum team relative value of story points for each story is important not the absolute value.

Any thoughts ?

Friday, May 11, 2012

SaaS: Tips for Contract Negotiation

SaaS is one of the most widely adopted cloud model in industry. With proliferation of various SaaS vendors, it is becoming difficult and time consuming to negotiate contact.

Following is the list of items which must be in consideration while discussing a SaaS Contact:
1. Setup Costs
2. Customization Costs
3. Training Fees
4. Integration costs
5. Data transfer costs – into SaaS (import)
6. Data transfer costs – out of SaaS (Export)
7. Free Pilot Period
8. Development sand boxes availability and their numbers
9. Test sand boxes availability and their numbers
10. License conversion from one model to another
11. Locked in or Escalating discounts for incremental spending
12. Fees for Non Corporate use
13. Storage fee
14. Maintenance and support fee
15. Uptime guarantee
16. Penalties
17. Audits of SLA compliance
18. Issue resolution
19. Escalation path
20. Data ownership
21. Source code ownership
22. Upgrades
           a. SaaS Infrastructure
           b. 3rd party software
           c. Developed code
23. Business continuity
24. Data security
25. Privacy issues
26. Disaster recovery
27. Suspension of Services
28. Limited Liability
29. Software license fee
30. Termination Fee
31. Pricing Model
             a. Per user
             b. Traffic based
             c. Time based
             d. Processor cycle used
             e. Storage used
32. Version control
33. Deployment strategy
34. 34. Retention/Disposition of customer's Official Records (data & metadata)
35. provision for legal holds and production of Records for eDiscovery

Thursday, May 3, 2012

Documentation for Support Team

Recently, my dev team was handing over a project to support team. While handing over the project, most of the support managers asked for documentation which should assume support engineers as dumb. A support engineer should be able to do various support tasks after following the documentation in verbatim. Yes I mean verbatim (even clicks and screen shots to create do mundane tasks).

Does support teams are made of such dumb persons? If not then does it is worthwhile to make such documents?

Wednesday, May 2, 2012

Book Review: Webbots, Spiders, and Screen Scrapers: A Guide to Developing Internet Agents with PHP/CURL

Book Review: Webbots, Spiders, and Screen Scrapers: A Guide to Developing Internet Agents with PHP/CURL by Michael Schrenk: Publisher- Apress: ISBN- 13: 978-1-4302-0973-7

Webbots, Spiders, and Screen Scrapers is first book I have read on Web robots. Book is very good for beginners and gives moderate understanding of subject. Book assumes that reader should have basic understanding of PHP which is good keeping the topic it is covering. Though Author covers library written by him but that makes book good for beginners and does not bog down the first timers to web robots. Schrenk also covers legal issues which may arise while designing and writing web robots which is fair warning to any developer. Book also has its web site which gives latest information about subject. This book certainly be in by book shelf for long.

Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author.

Further reading: A competing book is Spidering Hacks by Kevin Hemenway and Tara Calishain http://www.amazon.com/Spidering-Hacks-Kevin-Hemenway/dp/0596005776 

One can get more information about book and related topics from:
1. Book’s web presence http://webbotsspidersscreenscrapers.com
2. Amazon: http://www.amazon.com/Webbots-Spiders-Screen-Scrapers-Developing/dp/1593273975
3. Publisher -- No Starch Press http://shop.oreilly.com/product/9781593273972.do
4. Review http://blog.utahcon.com/books/book-review-webbots-spiders-and-screen-scrapers-2nd-edition
5. Review at Book critic: http://blogcritics.org/books/article/book-review-webbots-spiders-and-screen
6. Another Review: http://smoothtommy.wordpress.com/2012/04/13/book-review-webbots-spiders-and-screen-scrapers-2nd-edition
7. One more review: http://www.i-programmer.info/bookreviews/12-web-design-and-development-/4121-webbots-spiders-and-screen-scrapers.html