A lack of clarity could put the brakes on any journey to success.
 |
Photo by Joshua Sortino on Unsplash |
This quote by Steve Maraboli sums up the results of having ambiguity fester in a team, especially one that has a common goal of achieving a successful Sprint. It is simple. Lack of clarity amongst team members (whether agile or not) can disrupt, stall, or block them from achieving their goal. An Agile team consists of individuals who boast different expertise, but, for this discussion, I’ll be focusing on the development team.
The development team often consists of programmers and testers. As you can imagine, the team of programmers will have a make up of people who think differently, because of expertise, background or just simply because of who they are as an individual. Owing to this, there will be moments where everyone has a different idea about how to build a particular feature. There will also be moments when what to build is not clear to one or more persons on the team. How do you rid your team of this lack of clarity? I am proposing a fix. One that will cost you and your team nothing. Two words, that if I say them slowly, sounds like a master plan for devs: Technical......Design.
What is it?
Technical Design serves as a blueprint that developers and testers can use when developing and testing application features. In a more practical sense, it can be described as a session held by developers, to outline how a particular feature should be built. This is not dictatorship territory, meaning, it should be a joint effort between senior and junior devs. Every opinion and insight counts in these sessions because then, teams can consider all the possible angles of approach. In theory, it can sound complicated, so I will provide a practical guideline for carrying out tech design.
How to do it?
Effective tech design sessions can be done in several ways. Here is a guideline that I have created (based on my experience), that details how to conduct tech design when the team is huddled in the same space or even working remotely.
In Office
Here are a few tips on how to do tech design with a co-located team.
➧Have a member of the development team volunteer to lead the charge – It is good to have someone stand and guide the session. If this does not happen, you will find that the conversation quickly becomes scrambled/disorderly.
➧Make stories/tasks visible – A guessing game of what is to be talked about during the session will not work. It helps to have a visual. If you use an issue tracking software like JIRA, you can easily show the list of stories or tasks. A physical Scrum board (or Kanban board) can also be used to show the stories in question.
➧Point out each story/task and read them aloud to the team – This helps to grab everyone’s attention to the artifact being discussed.
➧Jot down steps or ideas given on how to build the feature. – This acts as a written record of what is discussed and the agreements made. Can you imagine the confusion at the end of the meeting or during the Sprint, if everyone remembers something differently? The use of whiteboards, sticky notes or any (allowed) writing surfaces should do the trick.
➧Save steps and ideas written in the previous step – Take a picture and share it in the team’s group (Slack or other) so the devs can use it as point of reference, even after the session has ended.
Working Remotely
Here are a few tips on how to do tech design with a team that is working remotely.
➧Have a member of the development team lead the charge – I might sound like a broken record but I cannot stress enough how important this is.
➧Share your screen – It is important for the person leading the session to share their screen because it helps to create a single point of focus for the team. Can you imagine how cumbersome it would be if everyone was trying to navigate the stories on their own screen? It would be chaotic because each person would want to talk about a particular story when they get to it (even if it was already discussed). Now, at the mention of the stories, you know where I am heading and you are right - point out each story and read them aloud.
➧Have someone take notes – Now, seeing that this is being done remotely, and you do not have the use of your whiteboard, have someone take notes. Remember, you have to listen to suggestions, mediate, and navigate the stories. You do not want to risk missing important notes while trying to do it all. Popular software like Microsoft Word or Microsoft Sticky Notes can be used.
➧Record the session – Now, if you or any of your teammates are like me, as forgetful as they come, you will need a recording of the tech design session. Using the video call tool or an independent screen-recording tool, save a video of the session. You should then share this recording in your team’s group for everyone to have access to it. A video can be continuously replayed and is worth more than a thousand words….I am sure of it. This step should not be substituted with the previous one. A recorded video helps the team to remember the broader discussion, while the notes with the steps narrows the discussion to a simpler format.
➧Do not move on until you have heard from everyone on the dev team – facial expressions might not be visible, so verbal confirmation that everyone is on the same page is vital.
➧Use chat to send links to resources – Tech design sessions often reveal how your senior devs think. They have been in the game and have seen, not all, but a lot. There is a great chance that the feature being discussed is one they have implemented before. Use this chance to have them share links to coding resources like past projects, videos or (the best of them all) stack overflow threads.
I remember when I volunteered to steer my team’s tech design sessions. I did it for myself because I figured that if I could lead that conversation, it would help me to understand how we were going to approach a particular problem. I soon realized that I was armed with the knowledge to tackle and complete any story in our Sprint backlog. I hate the feeling of ignorance. What happens if my teammate becomes ill and cannot complete his assigned story? Should I say that the story was not clear? Tech Design eliminates the lack of clarity and sets the team on their journey to having a successful Sprint.
The development team often consists of programmers and testers. As you can imagine, the team of programmers will have a make up of people who think differently, because of expertise, background or just simply because of who they are as an individual. Owing to this, there will be moments where everyone has a different idea about how to build a particular feature. There will also be moments when what to build is not clear to one or more persons on the team. How do you rid your team of this lack of clarity? I am proposing a fix. One that will cost you and your team nothing. Two words, that if I say them slowly, sounds like a master plan for devs: Technical......Design.
What is it?
Technical Design serves as a blueprint that developers and testers can use when developing and testing application features. In a more practical sense, it can be described as a session held by developers, to outline how a particular feature should be built. This is not dictatorship territory, meaning, it should be a joint effort between senior and junior devs. Every opinion and insight counts in these sessions because then, teams can consider all the possible angles of approach. In theory, it can sound complicated, so I will provide a practical guideline for carrying out tech design.
How to do it?
Effective tech design sessions can be done in several ways. Here is a guideline that I have created (based on my experience), that details how to conduct tech design when the team is huddled in the same space or even working remotely.
In Office
Here are a few tips on how to do tech design with a co-located team.
 |
| Photo by Christina @ wocintechchat.com on Unsplash |
➧Have a member of the development team volunteer to lead the charge – It is good to have someone stand and guide the session. If this does not happen, you will find that the conversation quickly becomes scrambled/disorderly.
➧Make stories/tasks visible – A guessing game of what is to be talked about during the session will not work. It helps to have a visual. If you use an issue tracking software like JIRA, you can easily show the list of stories or tasks. A physical Scrum board (or Kanban board) can also be used to show the stories in question.
➧Point out each story/task and read them aloud to the team – This helps to grab everyone’s attention to the artifact being discussed.
➧Jot down steps or ideas given on how to build the feature. – This acts as a written record of what is discussed and the agreements made. Can you imagine the confusion at the end of the meeting or during the Sprint, if everyone remembers something differently? The use of whiteboards, sticky notes or any (allowed) writing surfaces should do the trick.
➧Save steps and ideas written in the previous step – Take a picture and share it in the team’s group (Slack or other) so the devs can use it as point of reference, even after the session has ended.
Working Remotely
Here are a few tips on how to do tech design with a team that is working remotely.
 |
| Photo by Chris Montgomery on Unsplash |
➧Share your screen – It is important for the person leading the session to share their screen because it helps to create a single point of focus for the team. Can you imagine how cumbersome it would be if everyone was trying to navigate the stories on their own screen? It would be chaotic because each person would want to talk about a particular story when they get to it (even if it was already discussed). Now, at the mention of the stories, you know where I am heading and you are right - point out each story and read them aloud.
➧Have someone take notes – Now, seeing that this is being done remotely, and you do not have the use of your whiteboard, have someone take notes. Remember, you have to listen to suggestions, mediate, and navigate the stories. You do not want to risk missing important notes while trying to do it all. Popular software like Microsoft Word or Microsoft Sticky Notes can be used.
➧Record the session – Now, if you or any of your teammates are like me, as forgetful as they come, you will need a recording of the tech design session. Using the video call tool or an independent screen-recording tool, save a video of the session. You should then share this recording in your team’s group for everyone to have access to it. A video can be continuously replayed and is worth more than a thousand words….I am sure of it. This step should not be substituted with the previous one. A recorded video helps the team to remember the broader discussion, while the notes with the steps narrows the discussion to a simpler format.
➧Do not move on until you have heard from everyone on the dev team – facial expressions might not be visible, so verbal confirmation that everyone is on the same page is vital.
➧Use chat to send links to resources – Tech design sessions often reveal how your senior devs think. They have been in the game and have seen, not all, but a lot. There is a great chance that the feature being discussed is one they have implemented before. Use this chance to have them share links to coding resources like past projects, videos or (the best of them all) stack overflow threads.
I remember when I volunteered to steer my team’s tech design sessions. I did it for myself because I figured that if I could lead that conversation, it would help me to understand how we were going to approach a particular problem. I soon realized that I was armed with the knowledge to tackle and complete any story in our Sprint backlog. I hate the feeling of ignorance. What happens if my teammate becomes ill and cannot complete his assigned story? Should I say that the story was not clear? Tech Design eliminates the lack of clarity and sets the team on their journey to having a successful Sprint.
0 comments: