Friday, 29 March 2013

Smarter, not faster

Last November, I was partially working on a "crazy" project. I say crazy  because:
1- The initial scope of that project was presented as "Take this Excel spreadsheet and make it a web form.By the way, there are some macros"
2- 2 weeks in the project we found that the scope was much bigger. "By the way, we want to make some enhancements!". There was no Solution Designer looking into it, just developers.  Nobody was doing anything to change the delivery date
While Business Analysts were trying to figure out what had to be done and trying to solve a lot of questions, Developers started coding. A lot of developers were contractors and we were paying them by hour. There was the need to keep them busy to justify their time. No matter what they were doing.

I asked the team to agree for a 3 days "developer hiatus" while Analyst could catch up with the requirements. My point was that developers were making technical and architectural decisions in a time when we didn't even know what was being asked. In the same time, we wanted to introduce Git as a new tool so, I thought, would be a good usage of the 3 days for developers to move the code to Git, set it up properly, get familiar with it and then pick up with what Analysts would have found.

It was a big NO from the Dev lead. Under the pressure to use the contractor's time on writing code for the project, he just couldn't accept the fact that developers would stop writing code. "They are developers, they write code, they don't wait for requirements. This is against being Agile!". Despite my argument that the decisions they were making now would create problems if the requirements would be asking for different technical decisions, despite the fact that Analysts asked for 3 days to catch up with where developers where, the "3 days hiatus" didn't go very far. What I was proposing (some sort of TDD) was never done before, was just unacceptable!
Fast forward, end of March, after pushing the deadline 2 times, having a lot of people joining that team and then moving on to other projects after a while, I was talking just the other day with one of the Analysts that has been on this project from the start. Here what she said:
-OMG Ardita, that 3 days that you asked for developers to stop, we should have asked for 1 week!! You have no idea how much trouble we have been going through. The requirements were not anymore what client was asking for, but what developers had already done. We were being pushed back and forth between client and developers to figure out how to get the maximum of what client was looking for on a feature that developers had already closed. They were so worried to spend some contractor hours, but they spent so much of our hours that were wasted in this ping-pong. We should not aim to be faster anymore, we should aim to be smarter on how we do things!

I thought my job was done!!
Yes, true, I did not really help them with that project, but, as far as I'm concerned, they now know how to think differently and sometime consider to Stop! TDD is the best Agile practice that my company needs now. It's not about coding fast, is about coding what is needed, is about being smart on what to code and when.

No comments:

Post a Comment