I think, therefore I am – Agile developer

Continuing on “What got you here, won’t get you there” I further got engaged with the team to review existing development practices – starting with developer environment.

The team was using TFS for creating and tracking user stories. With just a quick walkthrough of the current sprint’s user stories it became clear that the effort was not going to be limited only to developers but would have to start right from defining stories. The user stories were very high level – generally at a feature level. Estimation were not in story points but instead in hours. Quite a few stories had huge scope and estimated efforts no less than 100 hours – at times even 160 hours.


How can a developer churn out 160 hours’ worth of work in a 2 week sprint cycle?

What was the weekly capacity considered for a developer?

Turns out multiple developers work against a user story and there are multiple partial check-ins against a user story – mainly for code sharing. This raised a lot of questions!

How do you define boundaries for individual’s work?

What about code reviews?

Who fixes defects if they arrive?

And unit tests? Well, automated unit test never existed whatsoever!

So obviously there was lot of ground to be covered before we could start looking at developer practices. Going back to the basics, I presented the team with following “commercial software success quadrant”


commercial software success quadrant

commercial software success quadrant