Agile Coach Camp - Measuring ROI

Another topic of discussion was how do you measure your return on investment and whether you are making progress. The team may provide anecdotal evidence that things are better or will get better - but how do you know for certain that you are getting value out of your investment?

Here are some hard metrics to measure your success.

Customer Satisfaction

• Conduct customer satisfaction surveys to gauge how receptive your customers are. This is a tremendously under-utilized and under sold benefit. Customers love interacting directly with the development team and relish the higher degree of control they have along with the flexibility to adjust the product as they see it evolving.
• Analysis gaps - Rework related to missing or mis-understood requirements typically decreases since the product is demoed often and gaps are caught sooner. You need to be able to articulate the savings from this.
  
• Predictability of release - The cadence of XP/SCRUM projects typically allows for monthly releases. This could be more or less frequent based on your situation but the benefit is decreased anxiety from knowing that a feature or a set of features hasn't "missed the boat". This leads to lower churn and better prioritization.
  

Product Quality

• Defect count - Given the tighter feedback loop & the XP engineering practices, the defect count should trend lower over a period of time.
  
• Passing Builds - The percentage of passing builds to failing builds should increase as the team becomes more disciplined.
  
• Test coverage - The test coverage is the percentage of code covered by tests. There are many caveats to this measure but its always better to have more coverage than less. You can measure this easily and gauge the impact of adopting agile practices in your organization.
  

Gains in Productivity

• Cost of Ownership - The cost of ownership of the software produced in the organization should reduce over a period of time with smaller defects, better test coverage and hopefully better design principles that support iterative development.
  
• Pre-release stabilization period - The amount of time needed for stabilization before a release should reduce.
  
• Release faster - The team should be able to produce releases in shorter durations and the frequency of releasing software should also go up.
  
• Lower ramp up time - With practices like pairing, collaborative design and tests to highlight the usage of the code, the time to ramp up new people on the team should decrease including reduction of the negative velocity of experienced people on the team who need to spend time to ramp up newer members.
  

Employee satisfaction

• Lower Attrition - If all parts of the development ecosystem are performing well, it should provide people better job satisfaction and lead to lower attrition rates.
  
• Survey - Surveys measuring employee satisfaction should show evidence from both a qualitative and quantitative perspective that the morale (related to delivery) is better and the comments are moving to more complex issues from the baseline measurements.
  

Agile Coach Camp - Pragmatic Agile

This was an interesting conference for me for several reasons -

• It was a 'coach' camp and by definition had people who were already practicing and leading their teams to excel at agile development
• It was my first conference in India after a very long time, the last one was a decade ago when Steve Ballmer smashed a mac at the Taj (i think) to make a point.
• It was hosted in Goa
• It was a smaller group which was extremely passionate about delivering software.

The style of the conference was open space. I conducted a few sessions in that, the pragmatic agile session was one that was probably the most interesting. In the idea generation phase of the discussion, I got a sense (perhaps wrongly) that people wanted to question everything which in and of itself is not a bad thing but possibly because if you didn't you didn't have the chops.

Being Anti-Dogmatic != Pragmatic

We structured the session such that - each person in the group presented a hypotheses of a good practice that "must" be followed for an agile project to be successful and another in the group provided an argument against it. Here is a quick summary of the discussion

Assertion: You must practice TDD to produce good designs and well tested code that can be changed iteratively.
Dissension: You can't test drive main frame applications or legacy code.

Assertion: You must use relative estimation to scope out the work.
Dissension: Corporate environments, external forces client or team do not always allow for that to happen.

Assertion:You must have acceptance criteria without which you did not have a good definition of being done.
Dissension: In smaller teams, the product owner role can simply state the story and developer's familiar with the domain can develop the feature without every single thing being spelled out.

Assertion: Continuous feedback is a prerequisite in whatever form be it builds or product features.
Dissension: Too much data can be distracting and not allow the team to focus or lose out on real information in the deluge of data.

Assertion: Team must buy-in to be agile
Dissension: Political or other organization structures may prevent this from happening so while that's better, its not necessary .

Assertion: A release must be time-boxed.
Dissension: A team/product owner can choose between time boxing or scope boxing for a release.

Assertion: There are no pre-requisites needed to be successful at delivering (in an agile fashion)
Dissension: While there is no check list, not considering proven practices is going to make the learning process time consuming and will probably lead to similar conclusions in a lot of cases.

Assertion: Must retrospect periodically to improve the process and solve underlying issues.
Dissension: Not looking around for outside feedback can narrow the amount of feedback you can generate internally and lead to tunnel vision.

Assertion: Must have a product manager
Dissension: Do not need a product manager, anyone on the team can play the product owner role.

Most of the discussion as you can see was pretty mainstream and those 'opposing' the assertion were often providing guidance on when to bend the rules vs. opposing the practices. Take for example TDD for main frame development, while it may not be possible in the traditional sense of test driving java or .net code, its certainly possible to write test code that calls main frame functions. The key takeaway being that its important to strongly evaluate a 'best practice' before discarding it as being irrelevant to your particular situation.

Prototyping and Field Evaluation as Risk Mitigation in Mobile Product Development

Next momo meet should be interesting. Its a chat by Frank Bentley on prototyping mobile apps. Frank does research in ambient interfaces, mobile computing, and social media and teaches Communicating with Mobile Technology at MIT so I'm pumped!

http://momochitown.eventbrite.com/

If you do decide to invest in that Roth..

Here are some ultra long etfs that provide good diversification and leverage at the same time. Clearly if you are close to retiring you shouldn't venture down this path :)

Moving to India

A close friend moved back to India recently and started blogging about his experiences of moving back after living 10 years in the US. He has promised to post regularly on the joys, tribulations and just plain information from someone who has experienced the comforts of the US and heads back.

That's not the Apple I know..

My one year old daughter poured soda on my last macbook pro and hastened its demise prematurely. It served me well until its last day. I've been without a mac for over a month so naturally I was a bit excited getting a new shiny toy - until I tried to connect it to my shiny LG monitor. The new macs don't come with a remote, and more importantly they don't come with any video adapters out of the box. 

Given most mac enthusiasts are spending top dollar, the one thing you don't expect from Apple is out-of-the-box-inconvenience. The situation is even more aggravating since the mini DisplayPort adapters aren't readily available in your neighborhood electronic store or anywhere else on the $#% planet except apple.

So now I have to make another trip to the store to buy a stupid video adapter that should have come with the mac like it did with the "old" macbook pros.

Use That Roth!

Its a good time to put some money in a Roth IRA account. The money grows tax free and your chances of making a profit are decent in the long term, given that we are somewhere between 5 to 11 year lows (depending on what day and time you put money to work!).

Agile Barometer: Burn down charts

You don't always need burn-downs. If you are using them, think about why you need it. Let me explain - Typically burn down charts illustrate the delta between the slope you need to be at to achieve your go-live dates vs the current slope of your work. If you intend to release in a two week cycle, you have 10 business days to develop meaning your burn doesn't give you any more visibility than what you already have from your daily standups. Any project/iteration manager worth their salt should be able to glean from the standups + the story wall where they stand in that 10 day period.

There are often times when a critical mass of stories needs to be developed without which the feature is not fit for user consumption. Only when this cannot be released in a short period of time (say 2 weeks) are burn down charts useful. If you are doing it purely to be agile - you've just proven you truly aren't!

Win 10 Grand

My team is sponsoring a holiday contest. If you are doing or have been interested in doing a home project or just want to win 10K go check it out! Also please please give me feedback on your experience of using the site and any issues you may run into!