July 4, 2012

Bye Bye AgileIndia2012, Welcome AgileIndia2013

by Sampath Prahalad

I attended Agile India 2012  in February this year. Three full days of talks and discussions about different streams within Agile (Agile Product Management, Agile Testing, Agile Coaching, etc), the different flavors of Agile (Scrum, Kanban, very little of XP, etc). Many talks were great,  tweets and related blogs were nice. There was enough food for thought and for the tummy as well. I made new friends and met up with lots of friends and like minded people. Here are my experiences from day 1, day 2 and day 3. So, Agile India 2012 was a success by any yardstick, the organizers deserve many pats on the back for organizing and pulling off an event of such a magnitude. They had done their due diligence and it showed.

Now, here comes Agile India 2013 . I don’t want the 2013 version to be a similar success, I want it to be much bigger and better. Yeh dil definitely maange more (Translates to ‘The heart yearns for more’)

For this, there are some tweaks and changes that the organizers need to make. I have tried to list some of them here. Continue reading

June 22, 2012

Agile Estimating over a coffee and 3 glasses of water

by Sampath Prahalad

Joseph Flahiff of Whitewater Projects explains about Agile estimating in layman terms by using 3 glasses of water. Ignore the background noise. This really is a nice video. Keep them coming Joseph.

Continue reading

April 23, 2012

Scrum rituals, summarized…

by Sampath Prahalad


Happens on

What gets done



Sprint planning meeting

First day of the Sprint

  • The capacity of the team for the Sprint is determined.
  • User stories for the sprint are presented by the PM, and agreed upon between the team and the PM based on team capacity
  • The team then breaks the User stories into tasks and assigns the tasks to themselves.

Sprint planning meeting is complete only when both the above are Completed

  • If there is an investigative User story, a specific time period (maybe a week) is alloted to that with the aim ofcoming up with the next steps.
Once planned, the contents of the Sprint are to remain constant for the duration of the Sprint. Any recurring activities like Production Support can be put in as a separate user story or their effort need not be tracked as part of the Development sprint.


Daily Scrum meeting

Every day of the Sprint

3 questions to be answered by the team.

  • What did you do yesterday?
  • What will you do today?
  • What impediments do you face?
This is not for the managers but for each other. If it is becoming a status meeting, the manager can be asked not to participate


Sprint Review / Demo

Last day of the Sprint

An informal demo of what was achieved by the team to the Product manager and other stakeholders in the Sprint. Anyone in the Delivery team can give the demo. The Sprint review focuses on the product and not the Process

Only User stories that are developed, tested and ready to deploy are ones that classify as Done.


Sprint Retrospective

Last day of the Sprint

The team (minus the managers) reflects on what went well during the Sprint and what processes can be changed for the better.

Continuous process improvement.

The Sprint Retrospective focuses on improving the Process and not the Product.


User story Sizing (Optional but recommended)

Once every 2 (or 3) weeks

Sizing of the user stories in the prioritized backlog list. The PM and team go through the user stories, play the planning poker game and assign story points to the user stories. Pace: 6-10 user stories per hour. The Intention is to have a backlog that is prioritized and well sized at any point of time so that the PM has enough information ahead of Sprint planning to identify the user stories that provide the most business value.
March 27, 2012

Having issues with the Sprint timebox and unfinished user stories in Scrum? Check out ‘Kanban applied to Scrum’

by Sampath Prahalad

I have faced some of the below problems with the rigid Sprint timebox (of 2 weeks, 3 weeks or what have you).

  1. A case of ‘The Sprint feels too long’: Product manager is under pressure to address an issue from Production quickly. However, the product development team is in the middle of a 3 week Sprint and will not take in any new user stories. This means that the issue in Production will need atleast 2 weeks to get picked up and 3 more weeks to get Done.
  2. Another case of ‘The Sprint feels too long’: The Sprint has just begun and a small user story is already complete and will add value once it is deployed to production. However, the Sprint end is 2 weeks away and deployment to production will happen with other user stories.
  3. A case of ‘Can’t the Sprint be longer?’: Product manager has come up with a feature to implement Google Analytics. However, the Product development team knows nothing about it. Continue reading
March 7, 2012

Tired of long, stressful Retrospectives? Try out the “Triple B Retrospective”

by Sampath Prahalad

As a Scrum Master and moderator, are you getting bored with the way the Retrospectives are being held? Are they becoming forums where few individuals dominate and/or accusations are hurled at each other and not much constructive is coming out of them?

Here is a minor tweaking of the usual Retrospective format to ensure that each team member gets a fair chance to reflect and portray his/her views candidly.

Let us call it the Triple B Retrospective:”Bouquets, Brickbats and Bulbs”

  • Put up a chart paper (A2 or bigger) in the team area 2-5 days before the Sprint end (depending on the duration of the Sprint). Create 3 distinct areas with the below headings
    • Bouquets: Appreciation for a team member, Anything positive within the Sprint
    • Brickbats: Any process that can be improved, toned down or scrapped.
    • Bulbs: Bright ideas here on what can be done differently starting next Sprint. Continue reading
February 28, 2012

Business Value generated by Agile vs Waterfall

by Sampath Prahalad

I came upon this video when I was preparing to give a talk on Agile and Scrum. Great video explaining the Business value add in Agile versus that in the Waterfall model.

Started my talk with points from this video and the talk went pretty well.

Go Agile Go…

February 23, 2012

Awesome Tweet Quotes from ALM Chicago

by Sampath Prahalad

The Midwest Conference on Application Life-cycle Management (ALM) was held on 22nd and 23rd February 2012 in Chicago. Microsoft was one of the main sponsors of this event.

Keynote speakers being Mike GilpinVP, Research Director , Forrester Research ON Day 1(22nd Feb 2012)  and Ken SchwaberCo-Founder of Scrum.org ON Day 2 (23rd Feb 2012)

Here are some good quotes in talks by Ken and other speakers that have been tweeted by participants at the conference. This is an effort to collate some good ones for everyone’s benefit.

  • If you want to really understand what you are doing on a project, use #Scrum. Ken Schwaber.
  • Metrics are used in waterfall because we had no idea what was happening so we tried to measure anything. Ken Schwaber.
  • @KSchawber“where there are rumors, there is not good communication.”
  • “There IS business value beyond new features.” aka quality vs. quantity. via Scott Herman – JCI
  • “Agile and Scrum seem to be used by companies that actually care about their customers.”
  • Perfect rule following will cause your org to grind to a halt. @vgr
  • Technical debt is growing faster worldwide than it is being paid off. @vgr
  • Competitive advantage is won with people not process. @vgr
  • It’s always amusing to me how much psychology plays into software design & development.
  • Culture eats process for breakfast
  • You wouldn’t wait till a car is at the end of the assembly line to test it. Why would you with software?


February 23, 2012

Recipe for good Distributed Agile Development

by Sampath Prahalad

At the Agile India 2012 conference, I attended a  superb talk by Rebecca Parsons (CTO of ThoughtWorks) on ‘Agile is not the easy way out, bit it works’. Many one liner wow tweets came from that talk. Check out some of them here.

After the talk, I met her at the ThoughtWorks stall near the Registration area and asked her what according to her was the Recipe to successful Distributed Agile Development.

  1. Split the power. Ensure that no one person at any one location calls all the shots. Try and ensure that there is a balance in the experience and knowledge across  both locations in the team.
  2. Forge a team identity. People who are part of the team across geographies should be treated as One team. Should not be referred to as Onsite team, Offshore team, etc. They are all part of the same Product Delivery  team. What applies to the team at one location should apply to the team members at the other location as well.
  3. Split work across functionality. Work should be split as vertical slices of a product (e.g: Distributed team working on say, User provisioning) and not horizontally(e.g. UI/UX development at one location, Back end processing at the other).

Pearls of wisdom from a person with loads of experience. Took her a minute to deliver and took me an hour to assimilate and digest.


%d bloggers like this: