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.
Hi Arlo,
I have enjoyed the posts. I am working through similar org changes and appreciate the insights you give. I hear ya on the team naming. I have wanted badly to name certain teams that could not figure it out but have bit my lip and been glad for it. Some teams take longer than others, but with enough people around each team that have been exposed to agile, they seem to pick up things like a name and quickly swarming. The bigger question has been do they pick it up fast enough for the org not to squash the teams agile attempt.
Any thoughts on steaming the tide when agile squashing is in the air due to a team being slow to gel?
You must gel…very fast.
Seriously, though, if a company can't wait for results for a month or so then it isn't going to get any value out of anything it tries. Or, rather, it will get value only out of the simple stuff. So move on. If they're willing to wait for 4 weeks – watching the whole time, but not requiring proof of success on week two – then you are OK. In this case, you simply need to ensure that your team is well coached, well launched and has permission to improve itself. If so, you will get well into storming inside of the window that people are watching. And so you should start seeing results (some positive, some negative, but at least results).
The first place I'd start is by helping the observers understand that team formation takes time. It is a trust building exercise. That happens as the team runs into problems and works through them. So they should certainly monitor for what's happening throughout, but they shouldn't expect that Agile will magically introduce high-performing teams in 6 weeks.
Also, odds are that they haven't seen high-performing teams before. Odds are pretty good that they haven't even seen teams get out of forming before. So some prep is necessary.
Once that groundwork is laid, then focus on the team. Extreme Programming really does give all the practices that are necessary to create a high-performance team every time. It doesn't take that long. If you are having problems getting a team to gel within 3 months every time (at least well into norming), look to your use of the practices (or, if you aren't using XP, look to the practices in XP that your methodology is missing – they're there for a reason). Make sure you observe the emotional aspects of the team (they're the stuff that really matters for performance, not the intellectual stuff). And make sure that every moment you are enhancing the team's ability to be a team, not your ability to support the team.
There is a ton of nuance in optimally helping a team gel, but there is also a ton of flexibility: anyone can do it with the right practices and mindset; doing it well and quickly is full of nuance. I'd be happy to help with specific troubles – if you can describe them well enough.
Where are the next results? is your 2 week experiment over yet?
It has now finished. I wrote up the results internally for my team, but I got exhausted each night before I could blog about it. I hope to catch up this weekend and schedule entries for daily release thereafter.
Can't wait to heat about your new project. Love your pictures and your blog!
Love your pictures
that they haven't seen high-performing teams before. Odds are pretty good that they