I’ve posted the slides from my recent presentations at Utah Code Camp 2014. If you missed it, I’ll be presenting “Thinking in F#” at Boise Code Camp 2014 on April 5th and “Software Craftsmanship and Agile Code Games” at Mile High Agile 2014 on April 18th.
Check out these and previous sessions on my Sessions page.
Posted a blog entry on the new Ancestry.com Roots Tech blog called “Games at Work?”
Here’s the opener…
Agile Games are a way for teams to learn and apply agile concepts in a fun, playful, safe environment. Play is important as it brings aliveness to our work environment that allows for creativity and our best work to flow. Games provide a safe environment where people are more open and willing to take risks and embrace change. The safety of games also allows us to talk about work… without necessarily talking about work.
Sometimes we feel like this:
We are at the top of the mountain! We’ve climbed, we’ve improved and we’ve made local, incremental changes such that we’re not quite sure where to go from here. We don’t know where else we could possibly go to move higher.
What we’re missing is this:
Yeah, there’s a higher point behind us that we can’t quite see. In math this is a “local maximum” where we’ve found the “highest point” but only if we constrain the graph we are looking at.
So can we find a global maximum? Or at least a higher local maximum? Why can’t we see it? And how do we get there?
Most retrospective practices (Stop/Start/Keep style activities) will generally get us incremental improvement and will usually lead us to these local maxima. I’m a big fan of retrospectives and incremental improvement so I’m not bashing these in the general case. We need to do this once we find a hill to climb, but sometimes we need to find a new hill.
So what can we do to find a new hill? We need to shake up our team and give them a Jolt. While I have several ideas how to do that, today I’m going to focus on one: Defining and Focusing on Team Values.
Whether you’ve defined them or not, your team has unspoken values. The value in defining them and talking about them is ensuring that there is common understanding in the team and giving a common language for the team to use. The values give you a framework for decision making, especially around how you will execute.
For example, if your team values “time to market” they might take shortcuts and hack something together but a different team that values “maintainability” may take more time to deliver, but will be more maintainable in the future. (We can debate the relative merits of each of these and if they are really in conflict but this is just an example.)
On my team, earlier this year we came up with eight team values. When asked what our team values were, we struggled to remember all eight. We didn’t really know how to focus on all eight or even did a good job of picking one to focus on.
In The Advantage by Patrick Lencioni he describes four different types of values.
This, in some ways, is a Start/Stop/Keep (Aspirational/Accidental/Core) activity, but at a value level that makes you step back and take a wider view. In our original list, we didn’t differentiate between different types of team values which didn’t give us a place to focus.
So in a recent retrospective, I explained Lencioni’s model of value types and then challenged the team to refine the list to 5 values and classify them as either Core or Aspirational.
The concept of “Permission to Play” gave us a term to talk about certain values that were proposed and exclude them. Using Lencioni’s model helped us to clarify why we wanted to certain values listed.
We started with the eight that we had originally come up with and I threw out several additional ideas including the XP values, the values from the Agile Manifesto and Software Craftsmanship Manifesto and other sources.
As a framework for voting and subsequent discussion, we used Fist-to-Five voting (we nick named it “Fist voting”) to decide if values were in or out and if they were Core or Aspirational. While it might seem silly to quibble over such things, I often go back to this quote:
Often the true value of a thing isn’t the thing itself, but instead the activity that created it.
-Dave Thomas
I found the discussion and the clarification of thoughts and terms to be one of the most valuable aspects of this exercise. We came to a better common understanding by forcing each other to clarify what we meant with different values.
One example of this was one of the original eight values was “teamwork”. As we talked about it, it seemed like this might be “permission to play” or at least too broad and poorly defined. So we debated about words. What word or phrase would better embody what we really felt we had or needed as a team.
Eventually “Team Ownership” was proposed. The team liked it but the team was split on whether or not it was Core or Aspirational. This might seem trivial, but the divide produced a valuable discussion around what that really meant. Half thought “well, we help each other out and pitch in when needed already, seems like it’s Core” while the others thought “we often have our own areas we’re working in and not really collectively owning all the code or even all the tests”. Clarifying how we wanted to define Team Ownership drove us to decide it was Aspirational.
Once we defined what our values were, we used a variation on the Values-driven Retrospective. Specifically we used the Believe Statement format (which is We Believe in [insert value], therefore we will [insert what we do]) to generate ideas of what actionable items to work on. From there we used dot voting to narrow the field and decide.
The other value that our values has given us is the framework to talk about what and how we are going to do our work in a more focused way.
I hope that this method can help you and your team to jump off your local maxima and find a taller hill to climb as a team.
For those interested, our team values are currently (in no particular order):
They actually ended up very similar to our first eight, but more focused. As a side note, I fully expect to reexamine these again in the future. As our team changes and grows, our values will likely need some tweaking.
I recently had the chance to interview candidates for a position on my team. I put together a list of questions that I believed would be a unique and effective way of phone screening candidates. Without giving away the whole list (I may disclose it later), here are the first two questions:
I had two out of seven candidates that I phone screen answer in the affirmative to question 2. Now not being familiar with the Agile Manifesto isn’t necessarily uncommon, I guess. But the inconsistency came from the answer to the next question:
“What Agile practices are you familiar with and/or have used?”
I figured the answers would be “I haven’t used any”. Because if you have done “Agile practices” you’d certainly know what the Agile Manifesto is, right… right?
BUT…
the answers were mostly in the “like, Scrum? Stand ups? Yeah, we do that stuff on my team.”
So… these candidates had presumably been introduced to the term Agile, to some Agile practices but hadn’t taken the time to investigate further, to understand the roots of the Agile movement, to do a quick Google search! Granted none of them had incredible answers to the Agile practices question, but they did have answers.
I guess I just don’t get it. I mean, I do. But I don’t.
Would this matter to you?
My name is Mike Clement. I'm a husband, father of four, a Latter-day Saint and currently a Distinguished Software Engineer at Hunter Industries.
Opinions expressed here are my own and do not necessarily reflect those of my company :)
Software on the Side is my blog about software development (coding, design and architecture), software development management, technology and leadership. Why "Software on the Side"? I guess there are a few meanings.
Sessions that I've presented (and can again!)
