Category: Coaching (Page 10 of 11)

Its Purpose?
This helps people new to a project answer questions about the domain more effectively and where the system fits into it.

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

How Did We Execute It?
We followed domain driven design as much as possible applying several techniques described in the book. We aimed for a Ubiquitous Language, reducing the number of terms for the same thing to a single one. This flowed into the code as well, where domain terms were used for domain classes, and namespaces for related concepts.

We tried to model all of the business processes and rules in a domain layer (the inner most tier on an onion ring model of our system), so that they were easily testable and people knew the first point to look for when answering a question about the domain. A side benefit of this is not tying the domain rules to a particular choice of technology or framework, and makes inconsistencies in the domain much more visible.

Many different factors affected the way in which we coded including aspects from Domain Driven Design, Object Oriented Design (such as encapsulation, responsibility, decoupling and reuse), testability, and readability. Our standards by default exclude comments where possible replaced by representing as much intent as possible in the code itself. We focus on what it does and why. I’ve found “What” tends to be best represented by production code, whilst “Why” is better explained in tests because you can better represent different contexts there.

Given that I’ve been with the project for some time and seen quite a few people flow on and off, I believe that given a handful of system patterns and a high level picture of how it fits together, it’s much quicker to bring people on board. Equipping them with knowledge of where to find information and seek answers for their own questions, you spend less time answering questions and it fits much better into their own mental model.

Why Is It Important?
Following Domain Driven Design and well refactored code brings many more benefits than just effective onboarding (think flexible, adaptable and much more robust and consistent) though I want to specifically focus on its impact on onboarding for the purpose of this entry. Even though these are great development practices, an emphasis on both of these has such a significant positive impact on onboarding of people.

Enabling others to find the answers to their own questions is much more effective because they depend less on others to work out their mental model and help them fill the gaps in that model.

Its Purpose?
Many of the techniques I’ve written about are ideal for covering a broad range of people and a broad range of topics. Each is useful for their own particular purpose, but I feel it important that you understand who you’re onboarding, and customise each of your techniques or at least the way you execute them to help them become more effective.

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

How Did We Execute It?
Although everyone on our team went through many of the same onboarding strategies and techniques, I sat down with each new person to find out a little bit more about them. I found it important to ask questions such as:

• What do they want to get out of the project?
• What have they accomplished that they’re particularly proud of in the past?
• How do they think they learn the best?
• What are they worried about?

Each of their answers don’t immediately necessitate the change to any session, but it gave me a much better idea of how I should adapt it, or expand on the session in the way that best suits each individual.

Why Is It Important?
Everyone that I’ve worked with is very different – some learn more effectively in different ways, and many have very different backgrounds and experiences. I feel it’s important as a coach to understand where they come from, and their different needs, tailoring content and the way information is conveyed to their particular style. Some people feel that the Socratic method is always an effective technique, though is often executed in a way that can be patronising and demeaning, particularly for more experienced people. Telling war stories or success stories is sometimes more effective, with the little anecdotes sticking in their memories. For others, visual techniques for conveying information is the most effective way they can learn. Others just need to do it themselves.

In short, there is no “Golden Hammer”, so don’t try to use it on everyone.

Its Purpose?
Individuals progress through different stages of learning. Not everyone will progress at the same pace, and at some point, people will move beyond the initial learning stage and will start to learn more if they are doing it by themselves with less explicit direction.

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

How Did We Execute It?
As individuals new to the team demonstrated more knowledge and understanding about the system, we started giving them more ownership of a particular story card. They would create the Tiny Tasks for a story, and own the design for it. As the technical lead, I would only intercede if they wanted an opinion about a particular design, other than that they would be given space they needed to finish a story card without any explicit instructions.

Why Is It Important?
There are many different ways that people learn and many different models describing each way. In Aikido, they describing learning using Shu-Ha-Ri and is one often used as an analogy of learning software concepts and patterns. Another model talks about the 4 Stages of Learning where an individual progresses from Unconscious incompetence towards the ultimate stage of Unconscious Competence though may progress via two others stages of Conscious incompetence and Conscious Competence. The common theme between most learning models is recognising an initial stage for a person who needs explicit direction and further stages where explicit direction is no longer required.

Many of the onboarding (and really just learning) techniques help address most of the initial stages (Shu or Unconscious Incompetence) of learning and it’s important to keep in mind that individuals will reach the second stage at different rates. If you continue to apply the same approach to teaching students who have transcended to the next level, you will find they become more resistant, and less appreciative and more than likely much more argumentative and resentful.

The key to Letting Go is recognising when individuals progress to that next level and give them the appropriate freedom to accomplish specific goals with little to no guidance. It’s important to still create a safe environment for them to make mistakes but they will learn much more by doing it themselves.

Its Purpose?
Acting as a teacher, coach or mentor helps to reinforce the concepts on all the different subject matters you cover whilst mentoring, therefore turning a student into a teacher is an opportunity you should make the most of. Vocalising your opinions and thoughts on a particular subject works to further deepen your understanding of the topic matter. It also has another benefit of exposing any gaps you may have when your student asks you questions.

Photo taken from Golbog’s photostream on Flickr under the Creative Commons license

How Did We Execute It?
We’re lucky enough on our project to pair program and we’ve found it an extremely effective technique at spreading knowledge about the system. When are team formed, we co-ordinated some strategic pairing, understanding that we had people at various stages of learning about the system. We made sure that people who’ve been working on the system pairs with people newer the system, effectively positioning them in the role of a “mentor” for newer people.

Why Is It Important?
Continuous cycling between student and teacher are common patterns you see in all types of martial arts classes because they recognise the importance of putting a student in the position of a teacher. Often you see many of the senior students instructing newer students on how to improve their technique even though they themselves haven’t yet achieved mastery.

Teaching others is an important part of the learning cycle, strengthening and deepening the things that you think you know so it’s important to create these opportunities and take advantage of them where you can.

Its Purpose?
Tech huddles give people an opportunity to reflect on their learnings, and helps to shift those lessons learned from one person to the rest of the group in a time-efficient manner.

Photo taken from Water Lemon’s photostream on Flickr under the Creative Commons license

How Did We Execute It?
Thanks to the idea initially proposed by Behaviour Driven Dan North, we spent about half an hour at the end of the day almost every other day where we would talk about the following topics:

• Any learnings from the day to share with the wider group including IDE tricks, Environment tips, cool patterns, nice bits of the code, any patterns that have been particularly useful at solving something;
• Warnings that may be useful for the other developers (such as watch out for this class – it’s particularly nasty); and
• Any questions or puzzles people may have that they haven’t been had answered through out the day

Why Is It Important?
Learning is an essential part of coming on to a new project. Setting aside time to explicitly think about what people have learned gives them a bit of chance to reflect on their learnings and then by expressing it, helps reinforce those learnings. A beneficial side effect is that more knowledge is transferred within the team that would be very slow to do via other mechanisms such as just pair programming.

Tech Huddles also give a chance for people to gain more context about why something is strange, or doesn’t understand the way that something is done, or the way that something works.

Its Purpose?
Breaking down complex or larger blocks of work into very small, defined tasks helps people focus on learning one thing at a time. Each item should be as small as possible, with enough detail that the newbie either doesn’t need to ask someone how to complete it, or wouldn’t take them long to find out. Each task completed helps people celebrate small successes, and helps them make progress without being completely overwhelmed.

Photo taken from Controvento’s photostream on Flickr under the Creative Commons license

How did we execute it?
Our story cards are written on index cards, and before starting development we would discuss the requirements with our Business Analyst and Quality Assurance person. For each block of work, an experienced person would write down each task that might be needed to complete that block of work. Each tiny task would be as granular as possible and we wrote each on to a separate sticky note. We strung them together and put them on top of the story card on our wall.

A tiny task must be as simple and as clear as possible such as “New DB column to table X”, “Property to domain object”, “Modify Hibernate Mapping File” or “Refactor XXX domain object” with certain assumptions already being clear (i.e. each code task would have a test).

Tiny task lists can and will change, with our developers adding and removing more tiny tasks as they discovered more detail. Small to-do tasks found during development also ended up being written out as tiny tasks to be addressed at a later point. We would encourage developers checking in for each tiny task as much as possible although in reality this ended up being a small handful of tiny tasks (i.e. 3 or 4).

As people became more accustomed to the patterns in the system, and the things that might be needed to implement a small group of functionality, developers wrote tiny tasks less and less.

Why Is It Important?
People need successes to learn, and a safety net when they fail. Clear and easily achievable tasks help people build their confidence, either giving them a feel for how quickly they are progressing, or giving them a basis to talk over where gaps in their knowledge may be. Tiny tasks also give a certain amount of independence as some people learn certain things only by doing them themselves and either succeeding or failing.

Its Purpose?
To help people understand what parts of the system have excessive code-smells and need either refactoring or redesign.

How did we execute it?

1. Maintain a list of the technical debt – We have a list of all the technical debt in the system on our wiki. As a team, we identify parts of the system we want to address as a whole and discussed different strategies for implementing it. Some of the debt stays on there until we all agree on a common approach, although we try to remove as much of it as we can, especially if they are small things
2. Walkthrough the list with new people – We sat down and expressed our concerns by walking through the list and explaining perhaps how it came about and what effects each item on the list have.

Photo taken from Jekemp’s photostream on Flickr under the Creative Commons license

Why Is It Important?
All big projects have some part of the system that doesn’t seem particularly right. Given commercial time constraints, you never have the time to address all the issues to make every single bit of the code perfect. It’s better to keep people aware of these compromises so you address them when you have time.

From experience, I’ve also found it’s very easy for new people to projects to criticise parts of the code that obviously aren’t ideal. It’s a very healthy process having new eyes on the material to bring a different point of view and offer different approaches, although there are better ways they can express their concern without making incumbent developers feel criticised.

Providing the opportunity to openly discuss all areas of the system the team would like to collectively improve each of them has been an effective way at meeting all of these goals.

Photo taken from Radiospike’s photostream under Creative Commons.

Its Purpose?
Visible Architecture helps new team members form a common understanding about how the patterns and constructs in the system interact. It helps them to identify clearer boundaries of responsibility that should not be crossed. It may describe external or internal systems or devices the application may interact with and how they relate to the system. It may also help them understand how the application is deployed and configured.

How Did We Execute It?
We actually ran two sessions to complete this – one ended up describing the physical architecture and how it gets deployed. The other ended up describing the software architecture and focused on the patterns in the system.

For the physical architecture diagram, we drew on sheets of flip chart paper a box for each machine in one colour, then each executing application in another colour on the machines. We also drew circles around the boxes grouping them and gave them a physical name since the servers are grouped together but each group is distributed around the world. Each unique executable was given a code to which we drew a legend on the side to give them a name. We ended up with nine unique executables (it’s the most minimal set for our application requirements), though with many instances of these based on the redundancy needs and distributed nature of this application.

For the software architecture one we first drew onion ring layers of the systems, added labels to each of them and talked about which how the parts should interact and their dependencies. We applied this to the testing layers as well to demonstrate their dependencies on the onion rings that we just drew and their own set of onion rings. We also talked about the patterns in the system and in which layers you would find them.

Techniques Found Useful For Running It

• Flip chart or whiteboard – It was useful to be able to draw relationships between individual executables to show what parts really communicate with each other, and other ones that communicate or depend on a database.
• Colour codes – Given how busy our diagram got in the end, the colours helped people to easily identify what was what.
• Executable code names –Writing each executable name on every box would have taken a long time and made the diagram more confusing. It was more useful to give them a shorthand code such as XX01 or XX02 and to describe it on the side.
• Onion ring layers – Helped people solidify the boundaries to the system in their own heads.

Why Is It Important?
Architecture diagrams are popular for a big reason in many systems as they help people visualise the larger parts of the system. It forces people to take a broader look at the system and provides a better context for the smaller programming tasks. It helps them raise suspicions when one part of the system starts getting too tightly coupled to another as they can understand where the responsibilities lie.

I’ve found that ad-hoc and lo-fidelity diagrams are much more useful than using one built specifically in a single tool as anyone can adapt them there and then in front of everyone and it helps someone show questions they may not be able to ask.

Next Time I Might Try:

• Team Participation First – Getting team members to first draw up what they see as the patterns might help demonstrate where misunderstandings or gaps in knowledge lie and to have better idea of where to focus the discussions.