patkua@work

The intersection of technology and leadership

Category: Coaching (Page 8 of 11)

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

February 5, 2008 / / 17 Comments

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

February 3, 2008 / / 0 Comments

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

January 28, 2008 / / 0 Comments

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

January 21, 2008 / / 13 Comments

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

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

January 9, 2008 / / 5 Comments

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.

Splitting Groups

January 7, 2008 / / 2 Comments

We do a lot of group work during training so we split a class into smaller groups for more effective discussions. Over the last few months, we’ve used a number of techniques for splitting a large group and I thought it might be useful for some future trainers, meeting facilitators, or on projects where you need to randomly divide into different groups. They include:

Splitting Groups

Picture provided from Ben Tubby’s photostream under the Creative Common license

  • Counting Off – Determine how many groups you want to split the group into (e.g. 3). Get everyone to count off to that number (i.e. 1, 2, 3, 1, 2, 3). Ask for people with the same number to come together. Variations include letting the participants to count off, or to direct the count off (pointing randomly around the room). You might also use other similar concepts such as city names, animal names or different sorts of fruit and vegetables (staying away from numbers avoids the “We’re number 1 syndrome”.
  • Line Up – Ask the group to arrange themselves into a line using some sort of order. This is a little bit more of an energising activity to introduce movement into the class. Different systems you can use include people’s height (shortest to tallest), first name or last name (alphabetical order), birth day and month (avoid year just in case people are sensitive about their age). Vary it up again by choosing ascending or descending order. Once they’re in a line, ask them to validate and then split the group using either Count Off, or simply split the line into equal groups.
  • Group by Token – In this activity, decide on how many groups you’d like and how many people should be in each group. Pick a token system and choose the same token to represent the number of people in a group, and different tokens to represent different groups. We’ve used coloured notes, coloured lego blocks, different types of sweets. Put them into a box or a bag, and get people to pick one and then find people of the same group. For instance, if I had twelve people and wanted three groups of four, I might choose to put into a box, four blue lego blocks, four red lego blocks and four white lego blocks for people to choose from.

2007 in Review

January 6, 2008 / / 0 Comments

I’m back from holidays, having been disconnected for the last ten days or so. I’ve finished uploading my holiday snaps (check them out here if you like) and checking all my emails so it’s time I got around to reflecting back on last year and what this new year may hold (even if it’s just that little bit late). I don’t do the whole New Year resolution thing although I try to revisit what goals I have.

In terms of conferences…

  • I attended the Retrospective Facilitator’s Gathering held in Phoenix this year that continued to fuel my existing passion for one of, what I consider, one of the most effective agile practices. It’s helped me communicate even more with people about my passion for the tool, continued to refine my approach and understanding of the tool and helped others to see the value they add. It’s also put me in touch with a whole heap of other people that share this similar passion. I’m sometimes referred to as *the* retrospective guy in the UK office and even though I don’t agree with that statement (I don’t know everything there is to know about retrospectives, and I’m certainly not perfect at running them – I’m just passionate about them). I’ve even helped to organise this year’s gathering.
  • I helped Tom Sulston out with his workshop, The Daily CI and I ran my Reface Your Team Space session at XP2007 in Como, Italy. Though I enjoyed the two sessions, I thought last year’s conference ran much smoother and had much better content than this year’s.

In terms of writing…

  • I published my first article on InfoQ after writing a series of blog entries on Onboarding Strategies. I want to continue to add and refine these as I still think there’s important lessons here that I hear teams fail to do everyday.

In terms of opensource…

  • Even though I’d contributed patches and bug fixes to some projects, last year I released my first real open source project, an API for printing to Zebra-branded printers written in .Net called Sharpzebra. I’ve hosted this project on Codeplex and I hope it eases someone else’s problems printing to this proprietary language.

In terms of growth and lessons learned…

  • I’ve read much more on Lean and Theory of Constraints this year, and starting to feel like I have a better grasp of the concepts. Applying them in a practical fashion in terms of noticeably different practices is the much more difficult step I need to take next. For other people’s reference, read books like “The Goal”, “The Elegant Solution”, “The Toyota Way”, “Lean Thinking”, and “Toyota Talent”. I’m sure there’s much more to read as well.
  • Only eight months after a disappointing situation, I finally made it to India to help conduct some training, giving me a full time focus on coaching, training and facilitation techniques. I also have to thank one of my fellow trainers, Rixt who’s been fantastic at helping me to be more aware of many other techniques and approaches that I then could practice and apply during the training sessions. I feel that the delivery methods for the course improved significantly over the three months the whole training team worked together on.
  • This year I also first officially lead (at least from a technical point of view) an all TW team, and under fixed bid conditions, high expectations from the client and a very complicated domain with a few new people, delivered a very successful project to a very happy client. Reflecting on the experience, I extracted out many of the onboarding strategies I wrote about, and then applied it as the team almost doubled in size for the next release.
  • I’m also very proud of the way, as a team, we handed the leadership over seamlessly to another person as I prepared to head to training. Transitioning the tech lead role is often executed haphazardly, leading to inconsistent visioning, confusion amongst the team and general chaos. I’m pleased that when I left the team, it was like they could work without me (which is a good place to be!)
  • I stayed at the same client for most of the year, although ended up on two different projects – one of which I worked on the year before. Seeing the same project, or introducing new people to the same project months later taught me so many lessons about what decisions or approached work or don’t work taking a long term view of a project. I can’t recommend it enough to anyone to make sure they understand the consequences of the choices they make beyond their own time on the project.
  • Tim Bacon (an alumni Thoughtworker and fellow agilist) introduced me to the Amplify Your Effectiveness crowd that seems to align strongly with members of the agile community. That, and the Getting Things Done crowd.
  • I created two new retrospective exercises, one that I’ve blogged about called The Three Word Starter, and another I’m yet to blog about though I tried with a couple of teams in India.
  • It’s not about what models you use, it’s about how you use them. This year, I’ve learned so many different models from so many different people, and although they appear trivial, watching people who really harness their energy constantly amazes me. I need to remind myself, it’s not about whether or not a tool is good – it’s how it’s used and how it’s applied.
  • Doing the things you say is much more powerful than simply saying things. It demonstrates commitment, and belief in the things that you value and is often an effective way of leading change in teams. I’ve seen people say things and then do something completely else, confusing people to no end. Others simply say things and don’t do anything about it, making it less likely to occur.
  • Effective feedback earlier is better than no feedback at all. It’s better than feedback too late to do anything to do with it. Of course, this takes energy yet it’s a very powerful thing if people respond to the feedback (it’s not always guaranteed). You can do at least your part by ensuring the feedback is timely, and well constructed.

Personal takeaways from training

December 19, 2007 / / 1 Comment

I’ve really enjoyed my time facilitating and training experienced co-workers. It’s a great opportunity to share some of my stories and given me some time to focus on really refining some skills and deepening my knowledge as a coach and facilitator. I’ve learned some important lessons that future trainers or coaches may benefit from.

EnergyBalance your energy
A day of successful training should leave you with that satisfying yet slightly exhausting feeling. Presenting, facilitating and responding to the needs of the class take energy and students respond well when you demonstrate your own passion for it. Putting this energy into all your sessions will take its toll and makes you susceptible to falling ill. For my first two training courses, I fell ill immediately the week after and I’ve noticed this same cycle with the other trainers.

Find your sustainable pace by understanding your own limits, getting enough rest, and spending enough time on yourself to recharge. The alternative of a lethargic, sick, trainer running a class is definitely not effective.

Learn about learning
Training experienced hires brings a different dynamic compared to those straight out of college or university. The vast array of backgrounds, different working experiences and varying degrees of openness to the material requires a more versatile approach to the material. Understanding everyone’s different learning styles, and understanding different models equips you with better techniques to help everyone in the class learn.

Learn about things like Shu Ha Ri, the four stages of competence, Visual-Auditory-Kinaesthetic approaches, Kolb learning models,

Avoid sticking to the same training technique (such as lecturing) as it gets boring (and ineffective) very quickly.

ScrumWork as a training team
We work as a team of Subject Matter Experts (SME) and trainers with a background in training. Each role brings different aspects and understanding how to bring out both during a session is important. Respect the trainers that bring with them a plethora of training techniques, and (more likely) a deeper understanding of learning models. Respect the SME who brings the material to life with their own personal stories and (more likely) a deeper understanding of the material and its relevance to the real world.

Find ways to work together and to be able to support each other during a session. Use special signals or cues to allow seamless flows between each trainer.

Become aware of your own biases
I think it’s important to separate what people say, and how you feel about it. An important part of facilitation and training is ensuring everyone is listened to. Immediately reacting to a student’s comment doesn’t do this and the level of participation will drop off. Encourage contributions by first acknowledging their comment – “What I hear you say is … Is this correct?” Separate the observation from the evaluation.

Read the book on Non Violent Communication as it explains it much better than I do.

Onboarding Strategy: Catalogue of Patterns Applied

November 27, 2007 / / 0 Comments

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.

Catalogue

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.

Onboarding Strategy: Airing of Grievances

November 23, 2007 / / 1 Comment

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.

Grievances

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:

Board

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).

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders Noren — Up ↑