Tuesday, January 23, 2007
Okay, AppLabs, I take it all back!
I did a half-day tutorial--a Rapid Introduction to Rapid Software Testing--at the STeP-IN Summit 2007, on the morning of January 18 in Bengalooru (formerly Bangalore), India. After lunch, the choice was between a presentation on test automation strategies and building test management skills. I chose to sit in on the latter.
The presenter was Jaya Raghuram (Raghu) from AppLabs Technologies. Apparently his colleagues were unable to attend the scheduled talk, so he was a solo act. I was blown away. It was a wonderful talk, with lots of interaction between Raghu and the participants.
On several occasions, he asked for examples of the ways that people dealt with various problems--staffing, metrics gathering, estimation, release decisions, and so forth. In each case, he provided plenty of opportunities for people to suggest "best practices", and in each case, he also allowed other participants to point out contexts in which those practices wouldn't work. This wasn't done for the purpose of making anyone look stupid; it was done to demonstrate that something that makes sense in one circumstance might be disastrous in another--any practice is, at best, a solution that sometimes works. He also launched an aggressive (and in my opinion, appropriate) attack on most of the metrics that we use in software development, noting how easily they could be incomplete, distorted, or gamed.
Raghu led the discussion with grace, tact, and great energy, showing an eagerness both to teach and to learn. I left the presentation feeling energized and enthusiastic, and later had a very pleasant chat with him over tea. Great stuff, Raghu--keep in touch!
One insight triggered by the talk was something about our development models. Whether we adopt Agile or Waterfall or any other process, a general systems view of things requires us to consider that our development model is inter-related at some level with everyone else's model. No matter what decisions that we choose to make about our project and our product, those decisions are on some level vulnerable to the decisions that our customers or our service providers are making. That speaks to Pliant approaches to running our organizations; no matter how much we'd like to drive the context, we have to be at least somewhat context driven.
The presenter was Jaya Raghuram (Raghu) from AppLabs Technologies. Apparently his colleagues were unable to attend the scheduled talk, so he was a solo act. I was blown away. It was a wonderful talk, with lots of interaction between Raghu and the participants.
On several occasions, he asked for examples of the ways that people dealt with various problems--staffing, metrics gathering, estimation, release decisions, and so forth. In each case, he provided plenty of opportunities for people to suggest "best practices", and in each case, he also allowed other participants to point out contexts in which those practices wouldn't work. This wasn't done for the purpose of making anyone look stupid; it was done to demonstrate that something that makes sense in one circumstance might be disastrous in another--any practice is, at best, a solution that sometimes works. He also launched an aggressive (and in my opinion, appropriate) attack on most of the metrics that we use in software development, noting how easily they could be incomplete, distorted, or gamed.
Raghu led the discussion with grace, tact, and great energy, showing an eagerness both to teach and to learn. I left the presentation feeling energized and enthusiastic, and later had a very pleasant chat with him over tea. Great stuff, Raghu--keep in touch!
One insight triggered by the talk was something about our development models. Whether we adopt Agile or Waterfall or any other process, a general systems view of things requires us to consider that our development model is inter-related at some level with everyone else's model. No matter what decisions that we choose to make about our project and our product, those decisions are on some level vulnerable to the decisions that our customers or our service providers are making. That speaks to Pliant approaches to running our organizations; no matter how much we'd like to drive the context, we have to be at least somewhat context driven.
