The intersection of technology and leadership

Category: Coaching (Page 9 of 11)

Onboarding Strategy: Pair Programming

Its Purpose?
Working with people closely on a day-to-day basis creates a safe environment, ideal to learning more about the current culture of the team including the norms, habits, style and general approaches to way things are done.

Pair Programming

Image taken from ImproveIT’s flickr stream under the Creative Commons Licence.

How Did We Execute It?
On this particular project, programmers pair programmed most of the time. As a technical lead, I wanted to make sure people were comfortable working with each other so I encouraged a bit more of a pragmatic pairing approach and asked the team to take on the responsibility of ensuring enough pairing was going on.

I highlighted the benefits of what we were trying to achieve with pairing (knowledge transfer, style nuances, spreading different problem solving approaches, review of code) and asked new people to be comfortable raising flags when they were getting uncomfortable. Interestingly I think on this particular project we still ended up with a very high percentage of time spent pair programming and noticed that people also appreciated having a little bit more freedom if they wanted to investigate something.

Why Is It Important?
Working closely with someone (that you are bound to do with pair programming) gives a great insight into the working culture of the team that you happen to join. It’s easier to incidentally pick up the certain style that the team has towards different items though can be sometimes very frustrating depending on the people working on that team. I think that pair programming helps with the onboarding process, but it alone is not enough. I personally think that this technique is best combined with the Big Vision Business Problem, the Visible Architecture, and the Transparent Technical Debt strategies.

What I Might Try Next Time
I find pair rotation an interesting experiment. I’d like to try doing a day pair rotation with new people so that they more rapidly get a feel for the way individuals work and contrast their different experiences. Talking over their experiences and finding out what they discovered themselves or see what important lessons they found could be very powerful. I’d be quite concerned about over-doing it though.

Retrospective Meetup in Bangalore

One of the benefits of working in our Bangalore office the unique concentration of people in one location on a daily basis, resulting with some very interesting conversations. On Tuesday I hosted a retrospective facilitators meetup with a pretty open agenda. We had people from all parts of the organisation. I was asked by one person who couldn’t attend to write up the things we covered and some of the topics.

I felt we had some nice discussions, and thankfully not all of it coming from one direction (i.e. me). Here’s a quick recap of some of the topics and things we covered. I’m sure I’ve missed plenty of other side conversations (it was only an hour too!), so if you were there and you’re reading this, remind me via email or a comment here. Next time I’ll try to write the topics down so we capture some of the discussions. Here’s at least what my (terrible) memory holds:

Is it okay to give feedback to individuals during a retrospective?
Asked from the context of trying to give people feedback that strengthens confidence, I think many people in the room felt it would be appropriate. Others gave examples of these comments coming in from things that went well as well as describing the Offer Appreciations exercise (see the Project Retrospectives or Agile Retrospectives book). I’ve also seen these work quiet well.

What goes into a retrospective
We covered this pretty quickly since the room was a mix of experienced and inexperienced participants/facilitators. I quickly ran through a format that is most used:
1. Set the scene – Make it clear to participants why they’re there and what you’re trying to do.
2. Create safety – Ensure that all participants are going to participate
3. Gather feedback – Use some activity to generate some data and insights.
4. Actions – As a group, decide upon results or things to action upon

What happens if the same things keep coming up?
Part of it indicates to me a process smell that I’ve written about before. Some useful techniques to address this include Bas’ Plan of Action pattern. I encourage everyone to also focus on creating actions that fit the SMART (Specific, Measurable, Achievable, Relevant, Time boxed) criteria and ensure that you celebrate small successes so everyone feels like progress is occurring. I also tried emphasising that at least retrospectives are still bringing visibility to the issues, and that it sounds like the actions or things happening around it need to be addressed, not to stop running tools that give you feedback.

Alternative Exercises
A common exercise people in Thoughtworks use is What Went Well/What Went Less Well/Puzzles. I’ve had conversations with some people (not in this particular meeting) who believe that unless you’re doing this one, then you’re not doing Retrospectives. I showed a couple of alternative exercise ones including the Retrospective Starfish, the Art Gallery one, the Forcefield one (with its speedboat/air balloon variations).

What’s the perfect size of a retrospective
I honestly didn’t have an answer for this one other than “it depends”. The group talked about as you increase the number of people, the more time you need and individuals end up participating. We also side lined for a while on what happens if you keep Prioritising with Dots and not really getting the smaller issues out. Others came up with sometimes not running Prioritising with Dots and getting everyone to brainstorm action items that the team simply just took on automatically. Quick wins become reality in a flash this way.

Retrospectives are a process smell
I can’t remember who, but someone talked about having retrospectives themselves are a smell, in that an “ideal” team should be self healing and fixing problems continuously without needing them. In one way, I agreed with him as did several other people. On the other hand, in my experience sometimes even a well performing team needs that separate time to reflect on things independently of the other things they’re focused on doing day-to-day. One person chimed in saying that in a way, the issues coming out the retrospectives gave them confidence that they were already dealing with the issues (as in, there wasn’t any surprises). I also tried to explain several other side benefits such as a common place to share a story that might be missed, a place where people are safer giving some feedback, and a place where everyone has input into agreeing to a solution.

When Retrospectives Go Wrong: The Format Becomes Too Repetitive

As a facilitator and a participant of teams leveraging agile practices, regular, heartbeat retrospectives become an essential part of the team’s toolkit. Doing retrospectives so continuously inevitably leads to some repetition, and on some occasions team members seem to find it boring. I’m sure there’s plenty of reasons why someone might find it boring. I believe one of those reasons is that perhaps no important issues are being brought up, to which I would respond by scaling back the frequency of the retrospective – so say, holding one every two weeks instead of every one.

On the other hand, some people find the standard format of What Went Well, What Didn’t Go So Well (and sometimes Puzzles) too monotonous for their tastes. Even as a facilitator, I admittedly find repeating the same exercise slightly boring.

Luckily the Agile Retrospectives book offers a plenty of options you can implement and still achieve the same outcomes. I think it’s important to ask different questions, and also use different formats. Sometimes asking a different question exposes a set of very different answers from what you’d expect. Using different formats, especially those that are highly visual (symbols, graphics, colours, charts, etc) is enough of a subtle change to keep people interested and excited.

Onboarding Strategy: Preparation Email

Its Purpose?
This strategy gives individuals a chance to gain some context and do some background research before actually arriving on the first day of the project.

Email

Image taken from Shinyai’s flickr stream under the Creative Commons Licence.

How Did We Execute It?
Before we started our new team, I sent out an email that covered a few different topics. Some of the content would repeat some of the information they receive during other onboarding activities but I think it was still useful to help set some expectations. Some of the topics that I covered included a list of all the tools that we use, the technology stack that the application is built on, a description of common software patterns that we leverage in the system and an opportunity for them to reply with some questions.

Why Is It Important?
People coming to your project may come from very different backgrounds. They may not have had the same level of skill, or exposure to the same sets of tools. When you send out a concrete list of items relevant to your project, you help them understand what they may need to do more reading on or where they need to develop further skills. It also helps alleviate any concerns about not having the right level of skill or understanding and gives them more context about the project.

What I Might Try Next Time
Next time I would want to include more about the business, include more on what life on the project is like, and discuss any unusual or unique aspects to it.

When Retrospectives Go Wrong: All Action and No Talk

This is the corollary to the previous “All Talk and No Action” post.

I remember talking to two different facilitators about the way they run retrospectives. Facilitator A said “I don’t care too much about getting to action items”, implying that they wanted the people to discuss their problems. In contrast, Facilitator B said, “Why would you run a retrospective without any actions?”. I saw both sides of the argument, but also saw danger in both extremes. In the last post, I wrote about what happens if you only ever run retrospectives without ever changing it.

What would happen if you ran retrospectives only focused on action items?

Context is never shared
Running a retrospective gives some people a forum to be heard. Sometimes people need to get things off their chest, and need to be fully heard by all parties (keeping in mind it’s under the Retrospective Prime Directive). Regardless of whether an action item is created or not, some people may feel resentful if they don’t get a chance to tell their side of the story. By sharing a story, the team is also more likely to relate to the other person’s problem.

The wrong problem is solved
Often I hear people propose solutions in retrospectives without explaining what it’s trying to solve. Only by drilling into the issue further, do you sometimes uncover a very different problem. To this root problem, others may propose a better solution that is more effective, or works better for the entire team. Jumping to actions without discussing what you’re trying to fix often results in a poor solution, and often one to the wrong problem.

Teams lose a shared understanding
I’ve been in one retrospective where a team member only saw the result of the action items and never heard the discussions around it. They felt very resentful over a number of the action items, both because they felt left out and couldn’t see why they were needed. After the retrospective, we revisited the items and the reasons they came about to give them a better context but I don’t think it had the same impact if they had been there during the discussions.

What you can do about it.

Understand the the retrospective is simply a tool, so truly understand what you’re trying to achieve with it and facilitate it accordingly. Use a different set of activities to achieve your specific goals, and ensure you balance the needs of the group to make progress and the needs of the group to talk about the issues at hand.

We Do Things Differently

We’ve almost arrived at the end of my first two week course for internal training. We’d normally hold it in our offices, but space in the office is a huge premium with so many active projects. We’ve had to move our training sessions to the Royal Orchard Hotel. We hold our sessions in one of the conference rooms and I’ve noticed a distinct difference between sessions we’ve held and those that the different groups of people next door hold.

Our sessions use a blend of techniques including individual brainstorming, group brainstorming, facilitated discussion, reflective exercises and a group exercise combined with discussions about principles.

In contrast, the sessions held next door are often a single speaker presenting uni-directionally at the audience with a barrage of powerpoint slides.

As a coach, as a teacher, and as believer in agile methods, respecting people and their individual mechanisms for learning are motives enough to teach using a variety of techniques, especially in group situations. I like to think that our company thinks differently, more effectively, and hopefully much more fun.

When Retrospectives Go Wrong: All Talk and No Action

I’ve talked with a number of people who dislike retrospectives, and I feel a common reason they dislike them is that they feel that things don’t change. It’s all very well talking about problems, like what occurred and why, however when they come up with solutions, they still keep finding the same things coming up over and over again.

I, and several facilitators I’ve talked to, have many good reasons for holding retrospectives without being excessively focused on action items as it can be a useful place for different members of the team to better relate to each other’s problems and understand each other’s situations. On the other hand, you want to avoid creating situations where they feel they can’t work on their problems or they are not making progress.

Regardless of whether or not problems persist, I feel retrospectives still serve as a useful tool for highlighting these problems. Like Information Radiators, they are simply showing you where pain points lie. They don’t automatically make them go away.

The question I ask people about these situations is “What did the team do to make the problems go away?”, and “How did they approach fixing their own problems?”. I’ve seen a few retrospectives where the actions involve people outside of the retrospective, and committing them to changing external environments.

Some useful techniques for dealing with this include Bas’s Planning for Action, or by creating and ensuring that better action items are created. Perhaps they’re too big and they never get done, or perhaps action items are too general for them to be really executable. Creating action items that the team have no control over, and involve people not present in the retrospective are generally never realised. Focusing on smaller, more specific action items that the team actually has an ability to influence ensures that at least incremental progress is made and sometimes that’s enough.

When Retrospectives Go Wrong: The Facilitator Controls the Retrospective

I participated in one retrospective run by a contract Project Manager whose style was to stand in front of the group, and ask individuals one by one for a single idea for a “What Went Well”, “What Went Less Well” wall. I felt horrified as I saw each person uncomfortably offer a very brief statement, or in general, skip their turn and all with little discussion around it.

I look back at that situation and guess that it wouldn’t have been so bad if the team already had trust and confidence in the facilitator, but it was obvious from my perspective, based on the lack of interaction and productive conversations, this retrospective offered little value.

Strategies that I would employ (and some that I did) to improve the situation include using an independent facilitator (with no vested interest) to run the retrospective, collate input using sticky-notes to improve anonymity and efficiency, and to spend more time, drawing out the story behind the items to identify any common root causes.

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders NorenUp ↑