Customer Delight

In order to delight my customers, I need:

1. A hypothesis of what they care about and any breakdowns they are trying to overcome and functionality I believe will help them with both
2. A tight feedback loop that allows me to demonstrate stories and functionality and make decisions to pivot or persevere based on their feedback
3. Confidence in the codebase so I can know and can automatically verify that changes, large and small, will not break other functionality, services and systems

I get confidence in the codebase through:

1. A fully populated automated testing triangle including unit, acceptance & end-2-end test suites
2. Many sets of eyes in the code as it is being developed:
1. Promiscuously chosen developer pairs
2. Pair switching for code reviews
3. Product Owner driven "Whole Team" demo's
4. Fully Socialized QA 
1. Defect Prevention rather than defect detection orientation
2. Generalizing specialists and blurred roles
1. QA Testers included as part of developer pairs
3. "Whole Team" ownership of quality 
3. "Whole Team" exploratory testing as a foundational part of my weekly cadence

First Post

Jerry Seinfeld said "But I don't wanna be a Pirate".  I remember him standing there in that puffy shirt whining.

That's me, except for the shirt, the fame and the fortune...Oh, and I have a huge mustache...  I am whining too though, except I'm wining about writing this blog.

For more than a decade folks have asked me to blog.  I have obviously resisted.  I'm not sure if it is out of fear or something else, but I've avoided blogs & blogging, but that ends now.  I really don't know what to say or what I want to say and as I write this, the feeling is not subsiding.

I can write about philosophy, spirituality, family and what it means to me to be married for a quarter century, but, whatever I say is likely something somebody else has already said in another blog somewhere.  What's the unique perspective I would offer???  I like technology, high-performing teams, and QA in an agile world, so I guess that's the kind of stuff I'll blog about.

Again though, not sure what to say.  I guess I'll just write opinions and then see if they hold up to scrutiny.   Who knows where this will go.

So, opinion #1.  Command and control organizations are a dying breed, but most do not know how to evolve.  They are dying, as a result of not being able to produce results at the same pace and of the same quality as autonomously functioning organizational structures.  In my opinion, structuring around teams and helping them to become autonomous and high performing is key to shedding the legacy of C&C organizational structure.

Team orientation rather than project orientation means that the teams survive beyond the projects.  Traditionally projects spools up and teams are formed to complete them.  They disband after the project and then re-form for whatever new project comes along.  The cost of forming and re-forming teams is high, painful, costly and unnecessary. Structuring instead around teams, and taking the work to those teams, allow them to form, norm, storm and then perform.  And then hopefully, stay in the "perform" zone longer and more often.  I believe this approach is called "Take the work to the team" though I don't know where I heard it or read it.  I have however seen it, for years now, and it works far better than a traditional approach.

That's enough opinion for a first post.  I'll dive into what I mean by "autonomous and high performing" teams in a future post.

tc