When I say I’m joining Test Double as their new VP of Delivery, I’m not just making a career move—I’m making an alignment move. This is a company that already values the things I value. They’ve built a strong culture, a strong team, and a strong set of practices. I’m not joining to overhaul anything. I’m joining to help make something great even better.
Today, I’m excited to announce the beta launch of Collaboration Contracts, a lightweight app designed to help teams—especially distributed ones—quickly define and manage their roles in decisions. Whether you're using it to bring clarity to one-off decisions or baking it into how your team operates every day, the app is built to support alignment, accountability, and smoother collaboration.
The Experiment Canvas is a simple means of planning, tracking, and responding to your experiments.
Simple Things
When I say simple, I don’t necessarily mean easy. And I certainly do not mean crude in form or incomplete. Simple indicates something that does not have superfluous parts or multiple responsibilities, is easy to understand, is as independent from the rest of the solution as possible, and meets a need as is.
Simple may not address all use cases, but it does address some use cases.
Over the past several years, as I’ve been helping teams and organizations improve their ability to deliver software products that are desirable, viable, and feasible, I have been experimenting with a Behavior Framework that has proven to be rather effective. And I’d like to share it with you in hopes that you find it useful and that you provide me feedback on your experiences with it.
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.
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.
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.
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.
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.
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.
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.
As a coach, I've gone into numerous environments with the intention of introducing agile. Of course, I always talk about the values and the principles. Of course, I try to help people to see that there is no one true agile. There's no prescribed set of practices that once followed earn you the agile merit badge.
At the same time, these teams need something concrete. What things can one do in order to set them on the path to "being agile"?
For an update on this process, be sure to read Collaboration Contract.
In January of 2012, we at LeanDog were honored to host Jurgen Appelo for his first Management 3.0 course in the US. If you've not read Jurgen's book on "Leading Agile Developers, Developing Agile Leaders", I recommend it. The book is full of good advice and simple techniques for improving the way you manage. Among the items Jurgen shares in his class, I was intrigued by The Seven Levels of Authority and his Delegation Poker game.
This year, at SCNA 2011, I had the honor of moderating a panel on apprenticeship. I was lucky enough to get participation commitments from an impressive list of individuals. I feared I would not be able to get a decent panel together and instead, I had to pare the panel from a list of eleven amazing people down to just six.
