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.
My plan is to write a series of blog posts all related to the behaviors framework. Some of them will be about a specific behavior. Some of them will be about tools or techniques that help teams express one or more of the behaviors. Some of them will be my own experiences. And some will be damn near complete fiction.
Some time in mid-January, I was thinking about various organizational patterns and how companies run. I was thinking, in particular, about the idea of a "leadership team". I tweeted that leadership teams may be an indication of dysfunction.
I got a few different responses, all of which amounted to "please say more about this."
I recently gave a talk on the role of a Quality Analyst as an organization transitions from waterfall to agile. The talk was entitled "Switching Horses in Midstream" and covered a number of topics. One item in particular struck me as worthy of blogging about. It's a technique I've been using for years, but have never written about it. So here we go:
Legacy code bases with a lack of test coverage are often trepidatious places to hang out. You never know when a simple abstract method is going to create a sink-hole of logic and reason, eventually leading to your exhausted resolve to revert and leave it dirty.
I saw a tweet this morning that caught me off-guard.
If your software makes money it is good software by definition. Nothing else matters. #Agile ^ @SkankworksAgile — AgileFortune (@AgileFortune) July 23, 2015
It doesn't strike me as consistent with the type of thing AgileFortune usually tweets. My initial reaction was to reply via twitter, but didn't feel I could express my thoughts well in 140 characters or less.
I think I saw Daniel Pink's TED Talk on "The Puzzle of Motivation" for the first time in 2011. I'd been reading some about leadership, management, and organizational psychology up to that point, but Pink's talk and his distillation of these complex concepts into a simple framework (Autonomy, Connection, and Excellence) inspired me to read more on the topics. Over the course of the next couple of years, I consumed a decent amount of material. You can view my Goodreads account to see what books I was reading. Unfortunately, there is no easy way to share all of the scientific articles and other sources I also consumed.
I had the pleasure of presenting at NDC Oslo last week and the additional privilege of co-presenting a collaboration workshop along with Denise Jacobs and Carl Smith.
In this workshop, we cover Fist to Five voting, 5x7 Prioritization, and Collaboration Contracts.
It is not only the things we reward that shape culture, but the things we allow. Perhaps the easiest way to shape a culture is to do nothing at all.
When a rockstar employee yells at, denigrates, or refuses to help teammates and you let it slide because the rockstar is valuable, you are shaping a culture. When a teammate tells a racist or sexist joke and you say nothing because nobody present is a member of the target group, you are shaping a culture. When an executive abuses power, when a coworker engages in gossip, when a team cuts corners to make deadlines and you decide it isn't your problem, you are shaping a culture.
We have an application internal to Groupon called the "Love Monster". It was written, in large part by Devin Breen. There are other contributors, but Devin is the one that made it happen. He didn't do it because it was on a roadmap or because it's part of our quarterly objectives. He did it because he and others wanted something like this to exist. So he willed it into existence.
Back in May of 2014, I attended ALM Chicago. I had the privilege of closing out the conference with my "Let's Start an Epidemic" talk. The second speaker of the day was Venkatesh Rao. This was his third time speaking at the conference and I quickly came to understand why they kept inviting him back. His talk was daring, extemporaneous, and insightful. There were many pearls in his presentation, but one thing he said in particular struck me.
In 5 Tips for Building Trust | Globoforce Blog, Darcy Jacobsen suggests the following steps for building trust within your organization:
I've worked for essentially two types of companies - those that have clearly defined job ladders and those that don't.
A clearly defined job ladder provides people a clear picture of what they need to accomplish and what skills they need to display in order to move into a new role. A clearly defined job ladder provides a baseline for performance appraisals. Everyone in the organization knows what is expected of people in each role. Are you displaying these attributes with a level of proficiency requisite for the role, or are you not? Job ladders make the expectations of progress and the opportunity for advancement clear and consistent.
