The intersection of technology and leadership

Category: Teams (Page 5 of 8)

Lack of retrospectives a smell?

On our current project, we haven’t run many retrospectives. Gasp! Anyone who knows me might be shocked to hear that.

I’ve pondered whether or not that this has been a bad thing for our project. I’m a huge advocate for using retrospectives to help encourage people to create change on their projects. I’m a huge advocate for using retrospectives to bring the team together and understand what’s going on. Fortunately I’m lucky that our team has some very strong people with probably 40% of them having true skin-in-the-game experience working on agile teams that things just get done and more importantly, things continuously improve.

I definitely believe that without all the experienced agile team members, we wouldn’t have overcome all the different and sometimes bizarre situations (ask me if you see me!) thrown our way. Do I think retrospectives still offer us some value? Yes, but probably not for the reasons that most people use it for.

It’s amazing what a bunch of energised, passionate and people with the “solve the right problem once” attitude can achieve. I’d only wish that more teams were made up of people like this more often!

Humility starts with you

One of the things most important to me when working with teams is to demonstrate constant humility. To me, you need humility in order to have courage and in order to learn. You need humility in order to have good collaboration and interactions with people.

During one of our last stand ups, I apologised in front of everyone for making the quick commit before rushing off (I had a taxi waiting). That small quick commit broke the build so I thanked the team members who fixed it for me. Everyone had a good little a laugh about it because I’m the biggest advocate for encouraging people to practice good habits (unlike what I did).

Of course I’m embarrassed for breaking the build but I’m delighted that I can say sorry in front of my team without being slapped over the wrists. It’s important to acknowledge that people make mistakes – even experienced people who have been working in this fashion for ages. It’s more important to ensure that we have a safe environment where people can make mistakes, and learn something from it, rather than being punished for it.

A model for understanding retrospective impact

Steven List asks the question, Are Retrospectives an Anti-pattern? Of course, retrospectives are a topic close to my heart so I naturally wanted to share my view of them. The conversation apparently started on the Kanban Development mailing list and Steven’s post already captures some great discussion. I won’t repeat it here, but I find the dialogue echoing the same sentiments about other agile practices and whether or not they’re useful. For me, it’s too extremist and not particularly helpful. They make it sound like you need to choose from two positions: Either you run retrospectives, or you don’t.

I think the more interesting question is, “When are retrospectives most useful?” To help explain my thoughts, I’ve put together the following: A Model for understanding Retrospective Impact (click on it for a slightly bigger view).

A model for understanding Retrospective Impact

What is a retrospective?
Being specific and clear about this term is important in the discussion about whether or not retrospectives are useful. Some people’s understanding of a retrospective can differ from other people’s depending on each of their experiences. The conversations on the Kanban list seem to imply retrospectives are solely an iteration focused ritual (and of course, there is no such concept of a Scrum or XP iteration in Kanban). Though I appreciate Kerth’s original definition, I think in the agile community, Derby and Larsen’s definition better captures its essence:

A special meeting where the team gathers after completing an increment of work to inspect and adapt their methods and teamwork.

I like this definition best because its ties the concept of improvement (inspect and adapt) based on a shared understanding (the team) according to some unstated time period (an increment of work, noting it’s not specifically tied to an iteration).

What is impact?
I think it’s also important to define the term impact. One of the definitions by the Oxford Dictionary seems most appropriate:

a marked effect or influence

I want to emphasis that you can have a high impact retrospective without necessarily taking a lot of time, and that the opposite is entirely possible too (a long retrospective with a low impact). Note that I’m not going to discuss how to run retrospectives that have the highest impact (a totally separate topic worth its own set of posts).

Effect of team dynamics
The state of the team has an enormous influence on the impact of retrospectives. A high performing team will naturally have better communication amongst its members, and are more likely to fix things that get in the way of their goal. There will naturally be better and more frequent individual improvements, identified and implemented more frequently without the call for a specific meeting. This doesn’t mean that retrospectives are never a practice they call upon. Rather, it’s a practice that has less impact as there are many other items in the toolkit that get called upon. Sometimes it’s important for the group to get together, establish a common understanding and to inspect and adapt noting there may not be any specific regularity to these particular meetings.

In contrast, a dysfunctional team are less likely to call upon individual improvement practices, and thus, retrospectives play a more important role, providing an explicit opportunity to improve. I use the term dysfunctional in this sense to capture a broad category including newly formed teams, or simply groups of people. This does not necessarily mean the team cannot advance, nor that it hasn’t had a chance to advance, just simply the state it exists in.

Environmental Effects
I would classify a majority of environments as chaotic. In chaotic environments, improvement isn’t second nature. Through practices that start with good intentions such as auditing (“I want to have confidence you are doing what you say you are doing”), people in these environments become afraid to suggest changes, and are often fearful of attempting anything different because they’ve been punished for a failed experiment in the past. In these chaotic environments, retrospectives have a significant impact by providing an explicitly safe environment for teams to make, commit to, and hopefully be supported in making changes. Retrospectives have a higher impact in these environments because the majority of other activities doesn’t encourage learning, innovation and improvement.

In contrast, a nurturing environment welcomes fail fast innovation, rewards learning from failed experiments and supports continuous improvement in an explicit, non document centric approach. In these environments, the outcomes from implementing improvements and passing on tacit learnings is more important that meeting audits and compliance. Retrospectives have less impact in this environment because individuals are more likely to suggest and implement improvements without the need for a special meeting, and without the need for an entire team. Once again, it doesn’t necessarily imply that retrospectives are not useful (some issues require a shared understanding across the entire team) or that they are regularly scheduled events.

Avoid deciding between whether or not you run retrospectives. Consider when is it best for you to run a retrospectives instead.
Understand what situation you find yourself in using the model above and ask yourself whether or not retrospectives have the potential for the most impact (dysfunctional teams and chaotic environments), or where energy is better spent pursuing other activities because retrospectives have less, but not zero, impact (high performing teams and nurturing environments).

In the next set of posts, I hope to describe different situations I’ve seen first hand and what impact retrospectives had in relation to them.

Leave a comment and let me know what you think.

How do I tell if a team is agile?

Vivek asks what are the signs you use to tell if a team is agile? I prefer not to count the practices they might be using because that is almost too easy (to get wrong).

Example: I remember talking to a person about their team who claimed they did lot of automated testing. They apparently had tests but upon further questioning I found many of their tests didn’t work and hadn’t worked for quite some time. I continued to ask questions about their practices and they mostly seemed excessively ritualistic without the team benefiting from them.

Ticking off a checklist about practices is easy to do, yet hard to do well. I prefer to ask questions with a less explicit goal in mind. I care more about how people do what they do rather than what they are doing right now.

I prefer to look for consistent behaviours across what they are doing that tell me:

  • they care about what they’re doing
  • they understand why they are doing what they are doing, and actively question when it’s not clear to them
  • even better is that they can explain to people why they do what they do as a team and what value each part of their process has (I dare you to try that with your current team)
  • they help each other out even if it’s beyond their normal roles because they don’t believe that people fit in boxes perfectly. And most importantly;
  • they’re constantly trying to improve the environment they are in.

What other ones do peope look for? I’m sure there are plenty more.

What do you have more of?

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”?

Teams and Groups of people

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.

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.

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.

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.

Software Architects Of Today

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.

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders NorenUp ↑