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


What got your here, won’t get you there

What got you here, won’t get you there was my first message to the product team that I joined as a technical architect 8 months back.

To give some context, I joined a product team of a commercially successfully software product. The product was being developed for close to 2 years and claimed to follow agile software development methodology (scrum specifically). In line with the spirit of agile, there were frequent releases of the product – every 2 weeks – to be precise. Pretty exciting stuff.

Call me old school, but I knew only one way to get a successful product released so frequently – i.e. by following TDD (test driven development). I was excited to be part of a team that very well understood this and were delivering such a successful product week after week.

But maybe TDD was not the only way to achieve frequently releases after all. The team was not at all following TDD. Then how was the team delivering really? I learnt that since the same developers who joined on day one were still around and so was true with the testers. So generally they know all impacted areas and could code such that nothing was broken. Was I nervous to hear this? Hell, of course.

Below is a small dialogue from my conversation with the team that followed:

Me: Being a 2 week sprint, testing must be the biggest challenge. Right?

Team (T): Yes. In fact QA/testing team trails by at least a week behind the development team. We are so much caught up into the catchup game that we hardly finish functional testing before our staging release.

Me: What about regression testing?

T: We hardly get time to complete functional testing – regression testing is a dream. We have never done a single round of regression since we started.

Me: I don’t believe you guys. How on earth can you still deliver a working product every alternate week without any regression testing?

T: Well you are right, though we have never manually done regression testing we do have automated tests – we use CodedUI for test automation. But the coverage is minimal. This is more of a smoke test suite that we execute some basic test to make sure the basic product functionality is intact.

Me: But this is no replacement to regression testing.

T: No.

Me: Hmm. So now let me ask you this one question – how confident are you, as a team, about the product quality that you release every week.

Boy, this one question really changed the whole tone of the discussion and set the tone for all things that were about to change in the subsequent months.

The concluding lines of my dialogue were “What got you here, won’t get you there” We started with base-lining where were were and where we ought to be – and what was required for us to get there. I would be documenting all the steps and changes that place in the subsequent posts.

Meanwhile if you had any such experiences, do share.