Feeds:
Posts
Comments

The Scheme

I want to get the team off to a good, clean start.

My challenge is that we are not used to working collaboratively in this group / company. The point of this experiment is to work collaboratively and to see how that impacts productivity and flexibility. For example, what does the ramp-up cost look like to work in an area where only one person is a SME?

Therefore, everything I do today is focused on ensuring a collaborative team.

For this reason, I’m starting with a small amount of agile training, then doing a chartering session. The training is intended to give us a shared context and vocabulary. We will then use this, in the chartering session, to set up an initial way of working.

The real point of the chartering session is:

  • Give us our first win at win at working as a team.
  • Ensure all voices are heard. Make sure we hear about any (well, many) clear objections / obstacles and have a chance to work through them before they fester.
  • Develop an initial core set of team norms that 100% of the members agree with.

There’s also a challenge with this team in that I have a lot more experience at this way of working than most members. Fortunately, we also have a good champion (Fran) and another person with experience (Dana). However, I will certainly need to do some info-dumps. One of my key challenges will be to do that training without losing my ability to be a facilitator.

Although the team is forming (and will be during our entire experiment), I want to reduce the strong leader effect. Were it intended to be a long-running team, I’d be already setting up intentional challengers to help pull the team into storming. As is, I will simply try to go directly to servant leadership – not the right match for our current stage, but a lot more likely to be comfortable and successful for the experiment.

As part of preparing for this session, I looked carefully at what I care about. Since I’m facilitating, I need to be clear with myself on the things that I care about and the things that I want the team to pick where it wants to go. And I need to ensure that there are very few places where I have a horse in the race.

Upon reflection, this was my list:

  • We are doing daily retrospectives. We are only running for 2 weeks; we need chances to adapt.
  • We walk away with a process that works for both Dana and I. She has experience and will have a huge impact on our success. We need to make sure that her requirements are met.
  • Everyone else is happy with the result.
  • We have made a choice on pairing, one way or the other. I have a 60/40 preference for, but am completely OK with choosing no, so long as we choose.
  • Respect and trust show up in our values or simple rules. Team orientation, not individual excellence.
  • We think for a bit about how TDD or Refactoring might apply in our domain. We may not be able to apply them, but we think about it as a group for a bit.

I am OK with any result that meets those. So I’m ready to go.

How It Went

Results were good. It looks like the team is ready to start. We came up with a set of working agreements and simple rules. It looks like everyone is happy with them. Our first standup is at 9:55 tomorrow; our first retrospective at 3:30. We agreed that, by day’s end, we would have a plan.

Our plan will focus on a theme or two that are deliverable and show clean impact. It will also take into account the “other things” that we can’t get out of. It will list the theme and objective and the first few steps towards that objective. It may do other things too, TBD.

Dana is our Product Owner. I am our Scrummaster. I am going to see how much I can get my role to transition to Coach over just 2 weeks.

At the very end, someone asked about team name. We decided to do the same quick exercise that Dana does in her courses to give names to table groups. We had a quick discussion and found out three things we all had in common: we all enjoy travel, dancing, alcohol, and cooking. And apparently we can’t count to 3. Someone remarked “Sounds like a party!” And so that became the name. We are Team Sounds Like a Party.

As a coach, I’m really glad the team spontaneously came up with this idea. I like team names for the sense of shared identity they help label. It’s also great to see the team coming up with such desires – and acting on them – on its own.

In the future, I’ll probably add the team naming to my chartering session. I will need to figure out how to get it started via soft touch: it would be best if the team came up with it entirely unprompted, next best if they do so after minor suggestion along the way. Not sure whether I’d do it if I had to tell the team to do it – it’s all about the team-owned identity.

Tomorrow will be iteration 0 (setting up the space & the plan). We will start implementing the work on Weds morning.

Spinning up a new team

I am forming a new team. We are doing this as an experiment, so we are documenting the heck out of it. As part of this effort, I am publishing “Coach Arlo’s Secret Agenda”—a daily journal of what I intend to teach each day and what the results were. This is/will be a name-scrubbed version of that series.

Welcome inside my mind as I go through each day and detail of spinning up a new team and transitioning it to agile at the same time. Continue Reading »

The No Mocks Book

Recently on twitter, Clayton asked for a good book about unit testing without mocks. I don’t believe such a thing can be written, so I’ll try to write it in one blog post. First, here it is in one sentence:

Mocks are a smell. They tell you that your code depends on some semi-related part of the system. Rather than work around the design defect, fix the design.

The trick is figuring out what smell you are observing and how to “fix” it. Basically, what alternatives exist. Down the rabbit hole we go. Continue Reading »

Another good question came over the wires at work. My reply grew too long and I figured more people would want to see it. Besides, this way I can blog and call it a legitimate business activity.

Problem statement: what patterns and strategies work for choosing when and what to refactor? Does this change at scale? Continue Reading »

Paying Down Code Debt

We have huge code debt. We want to pay it down. But we just can’t afford to this week (or last, or the one before that). How can we afford to pay down our debt?

OK, it’s not a direct quote. But I’ve heard something close to that often enough that random word ordering may have actually created exactly that statement at some point.

Here is a set of techniques that I’ve used in the past to start paying down debt in situations where we were all sure we’d never be able to afford to. Continue Reading »

A Pairing Phrasebook

I see pairing as similar to a language. So I figured I’d put together a phrasebook for those who are just learning to pair. You might find these useful as you are trying to locate the bathroom, train station, and restaraunt in PairingLand. Continue Reading »

In the previous post in this series (“last week” to those who didn’t read it over a year ago), I made simple code complicated in the effort to make it unit testable. It was all going along fine, until I started bringing functional programming into the mix.

Since that worked so well, I’m going to demonstrate how I really wrote the code, which brings in functional programming, laziness, and asynchronous programming. Continue Reading »

In previous discussions about mock-free unit testing, I’ve shown techniques that I use to eliminate the hard-to-eliminate test doubles. I’ve skipped the simple techniques that I apply all the time. Time to fix that.

One technique eliminated about 90% of the test doubles in my code. It’s simple. It’s been around for a long time. Odds are you already do it but not frequently enough. It even has a name:

Extract Method. Continue Reading »

Hamlet On Branching

To branch, and when to branch: that is the question:
Whether ’tis nobler in the mind to suffer
The slings and arrows of poor integration,
Or to take arms against a sea of features,
And by swarming end them? To end: to ship; Continue Reading »

I have noticed a significant difference in the results achieved by teams with pairing depending on how they approach learning to pair.

In particular, many people don’t expect pairing, itself, to be a skill. They don’t realize that they’re going to have to learn new ways to think, to problem solve, to be creative, to filter their perceptions, and even to converse. Since they don’t realize this, they get surprised. And then they set themselves up to make that learning hard, and quit when they get poor results and find pairing to be hard while learning. Continue Reading »

Older Posts »