By Manoj Vadakkan
Recently, I happened to overhear and eventually involve myself in a conversation between two Project managers. They were discussing why Project managers have to define what "yes" and "no" means to the team – after all, people have understood these words since kindergarten. The story is very familiar to Project managers. Every week, team members report that their activities are on track; the project status is green, and everything is going as planned. Everyone is happy until the project is about three quarters complete, and suddenly one team member reports that he is not on track anymore. Suddenly, dates need to be changed and the schedule needs to be updated. The Project manager inevitably asks the important questions, "Why have you been telling me all along that you were on track?" "Have you been hiding something?" "Don't you know, 'yes' means 'yes?'" Obviously, the Project manager cannot go to the sponsor with the bad news, and the team has to work overtime to get the project back on schedule.
This reminded me of a story that Alistair Cockburn once told about a student trying to do his reading assignment. The student had to read a dozen stories and answer a few questions afterward. He had a week to finish this assignment. If I were the student, I would have spent every day just thinking about reading those books, and would have postponed reading each day until Sunday afternoon when I would cancel everything and start reading the first book. But this student was different; he was a good planner. Upon getting the assignment, he considered the size and difficulty level of each book and figured out he had to read a couple of books every day to have enough time to go through the questions and answer them. He spent three quarters of the week just reading those books. He was on track until he started looking at the questions. He then realized there were things he didn't pick up on or pay close attention to when he was reading them for the first time. This meant he would have to re-read many of those books. This also meant he would have to spend a lot more of his weekend on his homework than he had planned. Good thing he had some contingency built in to his schedule!
Could he have done better by scheduling the work in a different way? What if he had quickly read one book, and then immediately looked at the questions? Then re-read, but this time paid closer attention to where the answers were coming from. What if he had changed his approach a little further? What if he had not read the books first but considered the goal – answering those questions. Why not read the questions first and specifically look for the answers in the books? Does this sound like test driven development (TDD)?
Let’s think about how the student measured his progress. In the original plan, he was checking off activities as done (reading each book) each time he finished a book. He was on schedule during the reading phase. But the real goal wasn’t reading books. He wouldn’t get any credit from his teacher for just completing the reading. His success was measured against how many questions were answered and how well he answered them. So measuring progress against reading wasn’t realistic. On the other hand, if he had reviewed the questions first, then read those books to answer the questions, and measured his progress against answering questions, that would have been a better measure of progress. If you think about this in the software development world, this is similar to an iterative process. You complete (read) a set of stories and go through the tests for just those stories. But is this approach good enough? Is this agile?
Let’s take this a step further. I realize this may not work well with the homework example, but bear with me. Imagine that the student has the option of taking a set of answers from one book at a time to the teacher and getting feedback. The teacher might have said that a one-word answer was not good enough, and that she was expecting a paragraph, or that she was expecting correct spelling. In this case, the student could have made some changes to the way he produced these deliverables (answers) and could have scored better on each subsequent book.
One could argue that the teacher should have defined all the success criteria (minimum number of words in the answer, no spelling mistakes, etc) at the beginning of the week so everyone would know what they were measured against. I agree; the teacher should have. Translating this to software development, one could argue for collecting all the requirements upfront and getting a sign-off from the user. Then again, we have seen so many times that requirements are a moving target. We can get sign offs and freeze those requirements, only to find that we have to make changes later. Sure, we can keep complaining about how changing requirements interferes with our plan. However, at the end of the project, we can call it a success only if we deliver what the customer really needs, not what we signed off to do in the beginning. We can do that only if we are open to change and if we are getting frequent feedback. Getting frequent feedback from the user and making changes accordingly is the heart of agile. It is not enough to iterate through user stories or components.
As for the developer in my first example who kept saying he was on track; he may not have been hiding anything or lying at all. He may have been just following the plan like the student reading the book and checking off activities on his schedule. Or he might have meant something that we hadn’t been paying attention to such as: "Yes, we are on track but I haven't tested this with the other components."
Sometimes the organizational structure and/or process do not lend itself to getting frequent feedback from the user. What do you do in that situation? Tell me a story about your project.
