This is a quick post, following up on a tweet from a little while back:
"Unit testing is for code coverage like exercise is for weight loss. You're actually missing the point."
A great number of people in the software field appear to think the primary benefit of unit tests is test coverage. Some even talk about them as if they were one and the same. "No need for more unit tests, we have plenty of coverage already."
Best Practices are Subjective and Fleeting
I've long had an aversion to the phrase "Best Practices". As I started out writing software, I looked to my mentors and industry leaders to inform my decisions about how things should be done. If they shared their "Best Practices", I took them to heart. I wanted to be the best coder I could possibly be.
Coaching Anti-Patterns: Prescriptive Agile
I saw a tweet this morning that got me thinking about a coaching anti-pattern I frequently see:
"Without knowing you, your Agile coach knows you use should start using stand ups, TDD and pair programming, etc.
Taylor would be proud."
THE PRESCRIPTIVE AGILE COACH
The Prescriptive Agile Coach is armed with a reliable set of practices. The practices have been documented, vetted, and implemented successfully on a number of teams. They are inarguably proven. To the Prescriptive Agile Coach, those not following these practices are not truly Agile.
Being a Boss
In some manner or another, I've served in roles frequently referred to as "boss" for over 20 years. In a few cases, I owned the company, in whole or in part. In many more instances, I held some rank that granted me authority over the work-lives of others. I've learned a great deal over the years. And I am definitely still learning.
If you'll indulge me, I'd like to share what little I have learned about being a boss.
Management by Magazine
I think there is great value in reading books on business management. That is, there is great value in reading them with intent, considering their points, thinking through the details, doing some research, assimilating, and drawing your own conclusions.
But there is another approach I see taken far too often.
One on One Meetings
About 15 years ago, I started a simple practice with my fellow co-workers and employees. Every so often, we'd meet to discuss stuff and things. Nothing too formal, just a touch-point to make sure we were staying connected. I called the sessions "touch-point meetings". Over time, I made adjustments to the format of the meeting as various structures proved more or less valuable.
Don't Bring Me Problems
Coaching Anti-Patterns : Drive-By Coaching
As an "agile coach" over the past several years, I've seen a lot of different techniques and approaches. I've been impressed with the ability of some coaches to slowly and gently affect change; sustainable, genuine change. And I've been dismayed at the number of coaches who trivialize the complexity of change to check-lists and notions read from books, but never tried.
This series covers some of the (anti-)patterns I've seen among check-list agile coaches.
Collaboration Contract (was Collaboration 8)
Back in April, I wrote about a practice we were experimenting with at LeanDog. I called it Collaboration 8. The intent is to figure out who are the right people to have involved in a discussion. Rather than the boss making the decision, Collaboration 8 provides a way for the team to self-select and get clarity around levels of engagement and responsibility in the decision making process. I've found coupling Collaboration 8 with Six Thinking Hats has been a tremendous boon to the self-organizing teams to whom I've introduced the concepts.
Maybe it's about you...
I am reading "Good Boss, Bad Boss". It isn't a book I'd first recommend to aspiring or existing managers. It's not bad, it's just not as good as "The Advantage", or "Leading at a Higher Level"
In the epilogue to the book, Sutton talks about Steve Jobs and differing perspectives on what contributed to his success; creativity, assholery, or some magic combination of both. Pondering this made me think of a story from my own life.
Forever Forward
Memory Lane
Retrospectives are simple, but not easy. The general idea is to get the team together, establish a context, gather relevant data, develop insights, and decide what actions to take. Esther Derby covers the retrospective structure well in a slide presentation on her blog.