About me
This is Amit Rathore’s blog and its mainly about project management and related things – although you’ll occasionally find other stuff here as well. If you’re looking for my software-development/programming blog, go to s-expressions.
I have been using agile methods to build software since 2001, and I’ve been interested in applying lean thinking to the agile process over the past few years, in order to help improve the throughput and the amount of value delivered by teams and organizations.
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.
Patrick Hallock said
Based on what I see here and you interests, I think you would like to design databases using Object Role Modeling. It is a conceptual approach that in turn will create the schema for you from structured language and drawings similiar to midn maps. It is free on SourceForge.com. THe tool is named NORMA. Keywords for the search would be NORMA and ORM.
Give it a look and see if I am right. It is much easier for business users to participate and confiorm data models. None of that techie stuff.