Behaviours of a Tech Lead

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.

Einstein

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.

When Retrospectives Go Wrong: Controlling the conversation

One of the most important points that Kerth, Larsen and Derby emphasise in their books is that the facilitator should not have an interest in the conversation. As I heard someone once say most succinctly, “If you have a point of view to share, you should not be facilitating”. This particular bad smell typically happens when this rule is violated. I’ve first hand seen this the most when a person in a naturally authoritative position (think project manager, technical or team lead) facilitates.

I remember sitting in one retrospective where the facilitator (a project manager) ran the retrospective pointing at people asking them for a single item (what went well/less well). They would often literally drill the person, asking for more details, and often commenting on their input, saying things like “that’s a pretty stupid idea”, or “you really should’ve done … instead of …” before turning around and writing it up on a flip chart. When they had finished, they decided which topics they wanted to talk about further, then returning to the group without even involving them in the decision making process. I sat, aghast, silently observing as people uncomfortably shifted in their seats wanting to get their stories out in the open yet afraid it wouldn’t go anywhere productive, and worse, be judged for it.

The result… an empty ritual, empowering a single individual, and the only outcome of no beneficial change.

Crowd Control

The above image comes from Misschelle’s Flickr stream under the Creative Common’s licence

What to do about it?
The first step is to get an independent Retrospective Facilitator. Try really hard to get one. I know that finding facilitators are easy, and finding a retrospective facilitator may be more difficult though I’m sure you’ll find the results will be much better.

If you can’t find one and you’re the one facilitating, focus on the process, and less about the content. Your goal should be to ensure everyone has an opportunity to build the shared story, everyone has an opportunity to add their insights and everyone has input into the final solution. Do not push for the solution you think is best, and do not ignore people when they have something to say. Make it clear when you are expressing an opinion as a person-with-a-stake. Empower the group with a mechanism that gives you feedback when they feel you are directing the conversation too much. Believe me, it’s hard but it’s definitely worth it.

And what about the previous situation? (more…)

When Retrospectives Go Wrong: Conflict of Interests

I heard one story recently from a colleague where a technical lead facilitated the retrospective. They’d collected sticky notes from everyone, placed them around an exercise at the front and began reading them out. The strange thing is that they read only the ones they wanted to read out, blatantly skipping many of the others.

Why the lead would only read out the ones they did, I don’t know. Perhaps they thought they were the most important (based on their point of view), perhaps they were a random selection. I’m not sure. It’s clear what impact it had on the participants. People became frustrated that they weren’t being listened to, didn’t feel appreciated for their input, and I’m sure many of them felt the activity a waste of time. Apparently it broke down to the point where they started shouting out for the lead to read out the notes.

Tug of War

Image taken from TimmyGUNZ’s Flickr photo stream under the Creative Commons licence.

What to do about it?
Kerth emphasises getting an independent facilitator (though versed in the industry) to run your retrospective. From experience I know this to be difficult for heartbeat retrospectives. If so, people who have direct significant influence (i.e. typically project managers, technical or team leads) either shouldn’t facilitate, or be extremely aware of this conflict of interests and do something about it.

I’ve learned it’s important to be clear which, of your roles, you represent when you say something. Something like, “With my technical lead hat on, I’m wary of this suggestion because of …” Another technique is to accept you will be biased and ask the group to raise a flag you when they don’t feel you’re being neutral. If you see the flag, you must do something about it.

Concluding Thoughts
Facilitation is not for everyone. Participants and facilitators should understand where conflicts of interest lie and how it may affect some of the conversations. Mitigate for this by planning to have an independent facilitator or by putting another system in place to prevent these biases creeping in.

Why XP is the most popular agile methodology

XP, like many of its waterfall breathen makes it easy to follow. It caters to those people in the Shu phase of learning. It’s easy to follow and it’s easy to get wrong without guidance. It provides a set of values and principles as well as a set of practices to help you achieve them. It’s probably less useful for people in the Ha or the Ri phases of learning.

I don’t want to criticise XP since there’s plenty of material already out there about for that. Rather, I want people to understand where it fits in. I thank the XP community for showing us how practices help to bridge the gap between principles and values as well as showing us that simply focusing on practices (or one approach) proves limiting. I also want to emphasise that XP’s practices aren’t the only way of doing this. The fact that XP works for beginners is both its strength and weakness.

As an agile coach, I often use different sets of practices to help bridge people into the other phases that brings more awareness and thought into everday processes. After all, part of respecting people is understanding each of their specific needs.

The Extended Agile Reading List

Update (20 Feb): I probably want to add the same disclaimer that I did on the previous post. I highly recommend doing reading on these things and I do want to emphasis that reading will only get you so far, so try to find someone who’s worked with in this way before (i.e. an agile coach) to help you apply all these concepts appropriately.

Building upon the Essential Agile Reading List, here’s the extended one that includes either books that I’ve not read (and have been recommended) or those that help facilitate further understanding or more advanced practices. Buy all of them via Amazon’s Listmania here.

Methodologies and principles

Additional context

Teamwork

Continuous Improvement

Project Management

Requirements and planning

Development practices

If you do Test Driven Development all the time, you’re doing something wrong

I’m a big fan of Test Driven Development, and even more of a fan of Behaviour Driven Development. So it makes me sad to see really great developers adopt these techniques a bit too dogmatically.

Most developers operate in two modes when they’re writing code. Test driven development helps amazingly with only one of them. Use it for the alternative and you’ll quickly become frustrated, hate TDD and never use it again.

What are these modes? Experimentation and, what I call Focused mode.

Experimentation mode’s main objective is learning. It might involve poking at a library, tool, language or framework to understand how it works, how to interact with it, and perhaps understand some of its limitations. You might learn how to configure it, how to deploy it, and even how to test it. If you write code, it usually is throw away code because you don’t apply the same level of code quality because it stops you learning about things quickly. When people apply TDD during this mode, the first normal hurdle is they don’t know where they should be test driving it because they haven’t learned where the cost-benefits payback lies. They spend a long time writing their test only to find out the thing they’re doing won’t work in that way and then sulk over the time spent writing the test.

Focused mode’s main objective is producing something that will be put into production, used by people and extended upon. Here you want to write just enough code to provide the correct functionality. This is the most ideal time to apply TDD. You care about the quality of the code you produce here.

Recognise what mode you’re operating in, and understand where to apply (and where not to apply) TDD to get maximum benefits. In short, avoid TDD during experimentation and use it when you’re focused.

What Analysis Skills Are Useful

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.

Secret Sauce: Embedded Coaching

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.

The Essential Agile Reading List

One of the searches that stumbled across my blog was the “Agile Coaching Reading List”. Running the same query returned a huge mish mash of lots of different things so I thought I’d put together my list of essential reads. Of course, simply reading the books won’t mean that you’re an expert (and I suggest working with another coach to develop that) though it’ll definitely help in providing context, advice or skills that you need to practice.

Methodologies and principles

Additional context

Teamwork

Continuous improvement

Requirements and planning

Development practices

Reading

You can easily add all of these books to Amazon from this list here.

Would you recommend anything else? What did I miss? Please leave a comment if you do. I’ll also post the other books I still think are worth reading that didn’t quite make the cut and why.

Onboarding Strategy: Explain Your Rituals

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.

Prayer Wheel Rituals

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.

« Previous PageNext Page »