Inside the box

I’m really enjoying my new job as QA architect at Borland. One part of my job is to help some of our agile development teams in the US and Austria to form effective working relationships with our enterprise testing team in Singapore, and then, based on those teams’ experiences, to create a general process that other agile teams can use to implement the same types of changes. This is the enterprise agile testing initiative that I’ve referred to before in this blog.
Anyway, while reviewing my proposed process with our company’s agile evangelist, I realized that my proposed process works very well within the given constraints of our company, but that I had given no thought to questioning the constraints themselves. Most of those constraints are very much outside my control, but my coworker pointed out that there is value in thinking how much more my process could adhere to agile principles if some of those constraints were changed or removed, and then presenting that information to the people who do have the power over the constraints.
Without making this blog post a therapy session, let me just say that I think this ability to work well within given constraints goes back to my childhood. As I was growing up, there were many not-so-great aspects of my family life that I couldn’t change, so my coping strategy was to excel within those limitations.
This inclination to make things work within given limitations served me well earlier in my career, when I was just in the position of implementing process. But now that I’m also in the position of defining processes for others, I need to keep this inclination in mind so that I can make an intentional effort to think outside the box.