About me
First of all, what is an s-expression?
This is Amit Rathore’s blog and its mainly about software development- although you’ll occasionally find other stuff here as well. If you’re looking for my project management blog (about agile methods, lean software development, etc.), go to epistemologic.
I’m most interested in applying advanced computer-science concepts such as language-oriented design, functional programming, distributed and parallel computing, and collective and artificial intelligence algorithms to general application development. I’ve worked on several different domains including health-care, education, retail, construction, entertainment, insurance and financial services.
I love to read (I own several hundred books – they’re proving to be too much trouble during moves), and I’m a self-acknowledged Apple fan-boy. I love adventure games, science-fiction, and digital photography. And good wine.
I currently work at a startup – runa.com – we’re based out of Mountain View, CA. Before this, I used to work for ThoughtWorks (I was there for nearly seven years), and a long, long time ago I spent forgettable time at IBM.
I can be reached at (312) 953-4945. An alternative is to IM me using Y! at amitrathore or Skype me at jbbrwocky.
 |
 |
Randy Arvizu said
I came across your blog googling lean. I read Why I don’t use real hours for sprint planning (3/14/08) and I must admit that I really enjoyed the insight. For the past 18 months, I have been a scrum master on a program that has struggled to adopt agile principles. We have a team of 20+ engineers, scientists, and developers whose experience range in system development encompasses a broard spectrum. There have been many times when it has felt as if we were going through the motions of sprint review, sprint planning, and story development simply for the sake of doing so. I don’t think we ever met one sprint burn down goal. However, as the sprints progressed, the product backlog did provide a clear view of how close we were to meeting our deadline. It’s interesting that the very principles that we struggled with are the very same ones that you propose doing away with. In our case, many team members felt that if we did away with the planning and estimation (some were so bold as to suggest nix’ing the reviews) we could better interact with the product backlog and that the team could self-monitor itself. After all this time, I would find it very hard to argue those points.
I do have a question. I found that the sprint planning meeting was very useful in reviewing the backlog and refining requirements (or backlog items). I’m just wondering, do you find that requirements refine themselves naturally without reviews or should the team still set aside time for these types of activities?
Again, great thoughts. I look forward to sifting through your archives.
Regards,
Randy
Amit Rathore said
If you have been successful at hitting the commercial goals of the software you are building, then I’m happy to hear that you’re looking to take the next step and customize the process to suit the needs of your team.
There is one caveat, though. This kind of customization (iteration-less, estimation-less, etc.) is an advanced technique. I do not know your team, but assuming that they are master-level practitioners of agile (high test-coverage, low technical-debt, short-releases, super-involved stake-holders etc.) then you are good to go. This article explains this point of view.
Now, about your requirements question. No, I don’t think they get refined by themselves, I think it is a continuous process which must involve the stake-holders (business users, customers, product-managers etc.) and the project-management. This activity ensures that the backlog of high-level features gets constantly (re)-prioritized in order of importance. Then, the team always picks up a few of these (enough for a week or two, say) and breaks them down into the small stories that are actually used to get the features implemented.
By definition, therefore, this needn’t happen at the sprint-planning. It’s more effective to establish a healthy flow of ready-to-play stories, which are always arranged in order of business importance. The development team just pulls these as needed, and ready-to-deploy software comes out the other end.