Greetings friends! It's been way too long since I've done a live blog series, so you are either lucky or unfortunate but nevertheless, I'm here for you these next couple of days ;).
My second contribution is a workshop I will be giving on Wednesday called "Building a Testing Framework from Scratch". This is a co-presentation with my friend Bill Opsal (cute side note: Bill and I both live in the Bay Area but to date, with the exception of one day, we have only met up with each other at this conference). Hence we decided we should do something together and this workshop is it. I won't be live blogging about it specifically but I will be talking about it in the days following the conference.
Let's get started with the first talk. Michael Mah is the first speaker and true to form it starts out with a technical difficulty (really, what testing conference would be complete without at least one of these happening. Maybe with it happening at the beginning of the program it's a good omen ;) ). One of the factors that we often miss when we are talking about software delivery is how the business itself actually delivers. We spend a lot of time and attention (deservedly so) to make sure that the software we develop works and that we can deliver it on time with the best quality that we can. Do our businesses do the same Often the answer is "no". Michael points out that when organizations scale up, they expect that there will be an increase in bugs. Double the people, double the bugs. Seems logical, right? Truth is, what really happens is the bug count goes up exponentially (if you double your team, you often increase your bug count by four times).
Michael is describing a number of companies that have tried to bring Agile up to a scale that is larger than many smaller Agile teams ever experience. To succeed in those larger environments, planning and execution is critical. You need a roadmap and you need to be aggressive with your backlog. Additionally, you have to know your limitations as an organization and be realistic about those limitations. I've gone through this process with a small company becoming part of a larger company and that larger company itself becoming part of an even bigger company. That adjustment has not always been comfortable and it has taken a different way of thinking and executing to get to the point where we can reliably deliver on sprint goals. At the same time, the more often we do meet those goals, the better we get at determining what is real and sustainable. The key to realize is that it's definitely not a one size fits all option but with time and practice, you get better at achieving your goals and objectives.
Speed is great and if you can do it with high quality, that's also great. The bigger question is "do the desired outcomes of your business also match this speed and quality?" In short, it's great we are making stuff the right way but are we making the right thing? Are the features we are developing providing the maximum value for our organization?
Post a Comment