thekua.com@work

Its Purpose?
Explicitly identifying code patterns in the code base as well as how and why they’re used helps new team members learn more about the system faster. Explaining the system in terms of well known patterns helps new team members identify variants and where patterns are being abused/mis-applied.

How Did We Execute It?
In trying to hand over some work to the support group, the team assembled a list of all patterns used in the system. We listed the pattern name, a reference to the pattern (either book or web link) and how it was being used in the system. We also wrote down the benefits or concerns each was bringing to the codebase. We listed each of these on the team wiki on a page called “System Patterns”.

When new people joined, I would print a copy of the wiki page, and then during or after walking through the System Architecture, helped them understand where they might use them or see them being used.

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

Why Is It Important?
Patterns are excellent vehicles for communicating intent and solutions to common problems. Identifying and explaining the system as a set of patterns helps new team members understand the system in much larger chunks, making it easier for new people to focus on absorbing incidental information. It also allows them to focus less on how the code works together, and more importantly focus on what the code does and what value it brings.

Well known pattern names help to identify common problems in the domain, and what the team’s general approach is for solving them.

The number of patterns also indicate a qualitative attribute of your system. If you have a very large system, and only a small number of patterns it potentially indicates that everything is done in very different ways and needs some refactoring. Alternatively if these small number of patterns are used everywhere in the system, then it could already be a very well refactored system. I would also consider looking at a very large set of patterns for a small code base as that might indicate over-design and excessive complexity. In both cases, I would watch out for patterns with only a handful of uses to see if they are actually useful or not.

Things To Watch Out For
Some new team members may not understand all the patterns used in the system. Giving them reading references helps though you may need to do more work to help them understand the pattern.

What I Might Try Next Time
I would revisit this list of patterns with new team members after they’d been in the code base for a while. I think although it’s useful to introduce the catalogue early, it would help to reinforce some of the larger picture after they’ve had an opportunity to discover more detail on their own.

Next time I would also try to link to some part of the codebase that implements the “ideal” version of the pattern and the benefits the team reaps.

Comments(0)

During our training classes, we try to convey the importance of effective feedback aimed at either strengthening confidence or improving effectiveness. I feel it’s an important part of learning. We encourage participants to give each other feedback and set aside time once a week with one of the trainers to both give and receive feedback.

For some reason, most people tend to give very ineffective feedback such as “I think that’s good” or “I think you’re lazy”. Breaking these bad habits of giving feedback based on some value or belief judgements is hard to do and is worth the time and effort to unwind. Part of the trick is at least helping people realise when they’re giving ineffective feedback. Helping them formulate effective feedback is the next step.

Comments(2)

Roy Osherove’s very funny song…

Comments(0)

Thanks to all the people who helped me review my first submission to InfoQ titled “A Leaner Start: Reducing Team Setup Times” based on my series of Onboarding Strategies. Check it out here.

Comments(0)

Its Purpose?
Allows new team members an opportunity to express their discomforts, concerns and puzzles about the project in a constructive environment. This strategy focuses on explaining the circumstances or reasoning of decisions and to come up with new approaches and suggestions for improving any identified problems.

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

How Did We Execute It?
I ran this session with the entire technical team. I asked them to think about things that they had questions about, or things that had been troubling them on the project. I asked for them to write each of those items on a sticky note and let them put them all over a whiteboard.

We talked about each item, trying to understand what problem they caused. We talked around some of the drivers and decisions that might have lead to each of these items and alternatives that had been tried or considered. We also highlighted some as known problems and where to find more about what we’d acknowledged about them. I asked everyone to use three votes to help prioritise which items we should talk about.

For each of those items, we talked around the current circumstance and to help understand current forces at play. We also talked around attempts that we’d made to help address them (if any) and where we’d failed and learned from them.

As the final step, we brainstormed on a number of activities we could try out to improve them (attempting to be as specific as possible). Our final board looked like the following:

Why Is It Important?
The newest people to the project have the freshest eyes to see things that aren’t obvious enough. They lack prior context and don’t necessarily understand why the team made certain decisions or design choices. It’s a bad sign if they can’t work it out for themselves very quickly as it implies code is not well refactored enough or they cannot access the right information.

After being on a project long enough, new people who can’t understand these strange peculiarities assume the existing team made foolish or unwise decisions. These assumptions sometimes manifest themselves very strongly in the way they act, and the way they say things. I’ve found they range from something like “Why would you even consider that?” to “What idiot made this decision?” Understandably, the incumbent team no longer wants to listen to the important message behind the new person’s concerns and they no longer attempt to improve the situation.

Creating a safe environment to “air grievances” allows new people to highlight potentially problematic issues, or demonstrate the lack of clarity without focusing on who caused it, or whether or not it was the correct decision. What’s done is done. Instead the team now works together to improve the situation instead of focusing on blame.

I feel it’s still very important during these sessions to cover why decisions were made as some of those factors might still be in play and influence the direction of any solutions developed during this session.

What I Might Try Next Time
If I had lots of people joining incrementally, running this session continuously might not be as beneficial for the entire group, so I might run it individually with new participants. I would also use this strategy even out of the context of on boarding, as I ran it semi-intentionally as a technical retrospective (without calling it as such).

Comments(1)

What’s it about?
Covers techniques and describes the impact of introducing Scrum into large organisations. It also describes why you might choose Scrum to implement and helps evaluate its fit with the organisation.

What I liked about it
Schwaber writes very clearly about some of the consequences of introducing Scrum, including both positive and the negative aspects that I find is very honest and uplifting. He also details some strategies for adopting Scrum incrementally in the organisations. I find it’s refreshing to see many concerns from the enterprise point of view addressed.

What I didn’t like about it
The meat of the book is very short with an appendix describing Scrum taking up almost a quarter of the book. In one way, it’s brevity makes it easy to read though, as a reader, thought more of it was coming. I would have preferred a longer discussion in the book, with an example or set of detailed examples in the appendix instead of a recap of Scrum.

Comments(0)

Replace “Compiling” in the picture below with “My Build Is Still Running…”

What ones can you come up with?

Image taken from XKCD.com under the Creative Commons Licence

Comments(3)

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.

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.

Comments(1)

Seek the answers to the question, “When is this useful?” instead of the classical “Is this useful?”.

Comments(0)

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.

Comments(3)