thekua.com@work

When I go into different organisations, I see many of the people doing the work (analysis, development and testing) split across multiple projects. In my experience there are plenty of reasons why this is just a bad idea, and probably the biggest one that I see is that the split priorities for an individual conflict with a model for ideal teamwork.

What does your organisation have more of? Teams or groups of people “working together”?

There’s a big difference between the two, particularly if your organisation is interested in tapping into the benefits of teams. Unfortunately most of the time organisations miss the mark.

How can you convert groups of people into teams?
Split priorities create natural conflicts between groups. A lot of management theory I’ve read describes how to get the most out of teams by rallying them towards a shared goal or set of goals. At the individual level, setting different goals for different people establishes a dynamic that, at some point, individuals’ priorities will conflict and without a broader shared goal, will go unresolved. Setting the same priority for everyone is, in effect, putting everyone into the same team. Leaving people split across multiple projects, is in effect, setting different sets of priorities for an individual.

Comments(9)

In the spirit of Goldratt’s understanding of metrics, “Tell me how you are going to measure me and I will tell you how I will behave,” here are some questions I ask myself when I play the role of a Technical Lead.

Picture of Einstein figurine taken from Dunechaser’s Flickr stream under the Creative Commons Licence.

• Have I fostered a learning environment? Do people feel safe to make mistakes, and more importantly, learn from them and share them with the rest of the team?
• Have I fostered an attitude of continuous improvement? Can people talk openly about what they see on the project, determine what impact it has or how people feel about it, and encourage more of it (if it’s a good thing) or try something different (if it’s less than ideal). Do people feel empowered to do things without feeling like they need authorisation every step of the way.
• Does the development team collaborate well with the other parts? Do they talk to other people with respect, and do they try to involve them as much as possible where it makes sense?
• Does the development team balance the needs of the business with the demands of the technology and toolset? Are they doing what’s right for the business in the long term? Do they share the same vision?
• Do I act as I say? Even though this sounds obvious, I’ve seen many people fail at this and, as a result, the non-verbal cues that conflict with verbal cues and confuse the team.

And of course, this resource is a useful one too.

Comments(0)

I’ve worked with some analysts who think their job is to scribe, writing down what users say into documentation. Sure, some skills of an analyst might require some scribing though rarely is it the entire job. Here’s a list of things I’ve observed excellent analysts focus on.

• Focus on differences, look for patterns, and highlight these differences to the stakeholders. Determine where the origins of these differences come from. Is it a real reason, or is it an inconsistency because the domain vocabulary is a little bit too loose. Are the differences driven through something that adds value or do they come from coincidences.
• Involve more than just the stakeholders. Talk to developers or operations people and involve them in meetings. Understand the potential costs and brainstorm options with them to weigh up each options costs and benefits. Different points of view (ala Wisdom of Crowds) results in higher quality results.
• Go beyond what people say what they want. Don’t follow the “customer is always right” saying blindly. They may know what they want deep down. They just may not be able to express it. Also be sure that you’re talking to the right customer. Different groups of end users have different interests that are separate from stakeholders. A solution needs to balance all of their needs. Use scenarios and personas to draw these out.
• Clarify the vocabulary. Look for synonyms. Encourage people to use the same word all the time as much as possible. Use clarifying techniques, “Oh, do you mean X?” or contrasting techniques, “So you don’t mean X, you mean Y”, or “Do you mean X or Y or Z”.
• Drive for as much consistency as possible. Drive it through everything where possible beyond just vocabulary. Think about how features complement each other, and how the behaviours work.
• Customer time is important. You really want to prepare for meetings. Ensure people now about the agenda, questions (using both specific, directed or open), priorities.

Comments(0)

One of the biggest teases developers use on their peers when they move into a non-developer or a less developer focused role is to tag them as “Post-technical”. I’ve heard this term ever since I joined the industry. My other interests around team work, organisational processes, coaching and training seem congruent with this attitude.

How do I try to balance these roles? Embedded coaching.

It’s as simple as working in the role of a developer and a coach at the same time. There’s something about working “on the front lines”, so to speak, that earns you a certain level of respect that you wouldn’t get if you were on the same team in the role of a project manager, or something you wouldn’t earn if you visited as a coach or advisor. It lets you build that trust and rapport on a daily basis that gives you insight into the things that drive people mad, or the things others may not feel comfortable stepping up and saying out loud.

Of course, there are benefits to also doing coaching from an outside point of view though I do think that embedded coaching is undervalued and often unavailable due to the delicate mix of skills required.

Comments(0)

Its Purpose?
Every project has meetings or events that repeat. Sometimes they occur daily, others weekly and others less regularly. Sometimes they are informal and ad hoc, other times formal and repeated. It’s important for new people to understand what you call each of these rituals, how they work and why these rituals exist. Understanding what you call them, how they run and why helps them become a fully participating team member faster.

How Did We Execute It?
Before any repeating meeting we would have, if we had a new team member, I would explain what we were about to do, and explain the reason we met. Some rituals I didn’t explain in great detail how we would conduct the meeting since it would be faster to let them experience one. I intentionally explained it in front of the group to ensure we all had agreement about what we were all about to do, and to help remind newer participants why we have them again.

Here’s what it may sound like (you may of course, have different resons for running stand ups in the example below that are just as perfectly valid):

Explaning what: We’re about to start our “Daily Stand Up Meeting”.
Explaning how: In this brief meeting, we stand in a circle facing each other and share information that we think others will be interested in such as what we did yesterday, what we’re planning to do today, and most importantly any blockers we currently have.
Explaining why: We do this in the morning to help start our day and talk about what we did yesterday to helps others understand what progress we’re making. We talk about what we’re planning to do today to double check our priorities are correct for the day, and we want everyone to talk openly about our blockers because we want individuals to feel supported by the team in overcoming any blockers.

Here’s another example:

Explaining what: We’re about to meet for our “Tech Huddle”.
Explaining how: In this session, we want everyone to share an important lesson they learned today, or a gotcha others should know about
Explaining why: The system is becoming complex, and everyone may discover new things (or even old things over again). By sharing some important lesson or a gotcha, we accelerate the learning process and avoid costly mistakes caused by relearning the same thing over and over again.

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

Why Is It Important?

It’s difficult for team members to fully participate in rituals unless they understand what expectations you have for them and understand why it’s important to participate. Explaining what you call the ritual, and how you conduct each ritual and the roles team members play is a first step in the right direction. Once they understand the what and the how, the new people understand what the name of your ritual means to them and are now enabled with the ability to participate. Explaining to them the purpose of the ritual and the drivers behind it them helps build a reason for them participate.

Giving them both the ability (what the ritual is called, how it is run and how to participate) and the motivation (the signficance and value of the ritual) helps new team members stand out less by helping them avoid coping strategies of silence (”I don’t know what to do, so I’ll just sit and watch what others do)” or resentment (”What a crock! Why are they wasting my time?”)

You gain a secondary benefit from explaining the ritual following the what-how-why strategy. Explaining the what and the how helps you understand how consistently you repeat your rituals, leading to standardised work. Explaining the why helps you focus on the value of your ritual. Often many rituals lack value and, as a result, you should drop them.

What I Might Try Next Time
The next time I explain my rituals, I think I’m going to try to write what I say down to see if I’m being consistent. This might also work well as project documentation useful in handover to support or to observers who sit outside of the project.

Comments(4)

Shouldn’t be sitting in ivory towers dispensing design documents or ideas with no basis of reality.

They should be coding. They should hang around to see how their decisions pan out.

They should be hunting down smells, listening to the team about painful areas, thinking about how to turn them around. They should work with the team to co-ordinate a strategy for redesign or a series of refactoring to turn complex code into simpler designs.

They should be sharing their experience in collaborative ways with the team to create several design choices, to clarify the pros and cons and to refine them to a best choice.

They should still be looking at the bigger picture, and always looking for ways to share that big picture. Part of it might be an XP Metaphor (or the Shared Vision). It might come out looking like an architecture diagram.

I’m sure of missed some things, and I know for a fact, most software architects can’t meet even these. Fortunately I get to work with many who do.

Comments(0)

I’ve been lucky enough to meet Jean Tabaka before I’d read her book. She’s a very humble and knowledgeable lady, and you can see both of those attributes in her book about effective collaboration. It’s probably heavy reading for some people. For the right kind of people, I imagine it’s very easy to digest. If you’re working on projects in a team, especially as a team leader or a project manager, it’s a great book that equips you with lots of practices and tools that come in handy every single day. Even if you’re not working in any of aforementioned roles, as a member of any team, it offers lots of gems worth digging for.

Don’t be daunted by the book’s thickness - Tabaka’s laid the four hundred or so pages well with a decent index and table of contents, making it easy to jump around to topics that interest you. I fortunately had a few hours in the airport and the plane to give me a good chance of reading the detail of the sections that interested me.

A lot of the topics that Takaba covers are very relevant to any environment in which you’re working and even more so in agile development teams where collaboration is key. I definitely relate to many of the stories that she talks about, littering the book and giving real examples of the tools in practice. It’s well written and many of the models are useful straight away.

There’s a little bit of repetition - some of it probably because it’s written in a way that allows you to digest chapters on their own, and maybe so that it really lets the lessons sink in. It also talks about a number of topics that aren’t directly related to facilitation though are still useful in their own way for setting a better context such as leadership and specific agile methodologies. In a way, a lot of the practices draw from many other disciplines and although not necessarily completely new, are presented in a very easy to digest manner.

I’d definitely add this to my recommended reading list, especially for people who want to improve the effectiveness of their teams.

Comments(0)

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)

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(0)

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(0)