The Working Genius Assessment

My long-time mentor and friend Lynn Rogala introduced me to the Working Genius Assessment. It is a model created by Patrick Lencioni, author of the book The Five Dysfunctions of a Team. The assessment gives you insight about your working genius types and help you understand what activities give you joy and fulfillment. The model also tells you about your weaknesses and what drains your energy or frustrates you.

When you share your Working Genius Assessment results with the people you work with, and they share their results with you, you get more value from the assessment. The model is designed to help people learn how to work better with one another. The types of Working Geniuses represents the different activities done by teams to accomplish an objective, from start to finish.

I have the Woking Geniuses of Galvanizing and Tenacity.

• Galvanizing – The natural gift of rallying, inspiring and organizing others to take action.
• Tenacity – The natural gift of pushing projects or tasks to completion to achieve results.

At work I have earned the reputation of being the “Jiminy Cricket” of the organization, making sure we are staying true to our objectives and following through with what we said we are going to do. Other times people say I am a trickster and trouble-maker, like Loki, asking tough questions or making trouble to get people to do something or rally them to new ways of doing work.

You can learn more about the model here – https://www.workinggenius.com.

If you are wanting to take the assessment, Lynn is a Certified Working Genius Assessment Facilitator and you can book an appointment with her using this link. If you want to know more about Lynn, here is her LinkedIn profile – https://www.linkedin.com/in/lynnrogala/. Please note that I am not getting any commission for this. I am putting my Working Genius of Galvanizing in action and just sharing something I have found to be helpful.

Passionate Product Leadership

Last July I attended Jeff Patton’s Passionate Product Leadership Workshop. It was a live online training course which ran for 4 days and each session was 4 hours long. Zoom and Mural were used for the workshop. It as an amazing, superb learning experience! Jeff is an excellent teacher. You can read more about him here: from this page.

I was presented with the opportunity to take this course and at first I was hesitant to take it. I was thinking how this will help me become a better Agile Coach. Fortunately, I have a great mentor, Daniel my boss, who reminded me of my aspiration to be an “enterprise level” coach. And so I took the course and I learned how to help my company be better in the area of Product Leadership. I engaged more with the Product Managers and shared what I have learned to everyone in the company: from Development Teams to our Marketing Team and to the Customer Success department as well

Key Takeaways from the Workshop

There are three important questions that everyone involved in product development should be asking at every step of the process:

• Is it valuable?
• Is it feasible?
• Is it usable?

Anytime you do not have a satisfactory answer to any of these questions, you should be thinking and discussing a change in your plans. Anytime your team spends significant time arguing about any of these questions, you should pause and rethink your strategy.

The answers to these questions come from different perspectives on the product. This leads to the next key takeaway, it is good to have a triad of leaders in product development. The triad consists of: a leader on the business side of product management, a technology leader, and a user experience leader. Actually it doesn’t have to be a trio of leaders, this could take form as a “core product team” consisting of people who collaborate to make decisions.

To make smart decisions, the Core Product Team needs all the valuable inputs it can use. Another key takeaway is, everyone contributes what they can to the product development process. Silos should be broken down and collaboration among people from different departments should be encouraged. Product Managers should not lock themselves in a room while they “design the product and write specifications”. Development teams should not just wait to be handed requirements before they contribute to the product.

More to come…

I have more learnings to share and I will do so in other posts. I am grateful to have attended Jeff Patton’s workshop and I am eagerly sharing and applying what I have learned. Without a doubt, the knowledge and wisdom I have gained is helping me become a better Agile Coach.

Random Agile Thought – The Ideal Team Player

This was shared by my boss, Daniel: according to Patrick Lencioni, the ideal team player has three characteristics:

• Humble (does not think less of self; think of self less)
• Hungry (aggressively pursues goals)
• Smart (emotionally smart, in interactions with others)

I like it! 😁 I have always looked up to people who has these three traits. I have always enjoyed working with them.

A growth mindset requires a humble attitude. You must be open to learning. You acknowledge that you do not know everything and you accept help from others. This does not mean you are not confident with your skills or knowledge; rather, you accept that in a team, you can do more by working with others.

Passion and drive are important motivators for successful individuals. They also bring this with them when they join teams and so this directly influences the success of teams.

It is important to be intelligent and skilled. It is equally important not to be a jerk if you are in a team. Respect, trust, openness, empathy, and kindness all propel a team forward to success. So yes, being emotionally smart is an important characteristic.

I hope this random agile thought helps you and your team be more Agile. 😊

Random Agile Thoughts – Completing a Goal

In one of the conversations we (me and my fellow Agile Coach) have with my boss, we were given this scenario:

The team was not able to complete a goal it has set. The team worked hard on the target, but in the end failed to meet the criteria required for goal completion.

And we were asked this question: “What will you say to the team?”

My answer is this:

I would say to the team that we have failed to complete the goal we have set for ourselves. We acknowledge the hard work we put into this effort and we appreciate the learnings we have gained. I would encourage the team to think about why we were not able to complete the goal. This reflection will help the team grow and become better.

I think the completion of the goal is more important than the effort put into completing the goal. When you set a goal, you set it because you are after the value you will gain from it. You don’t set a goal just to work on the goal. You don’t set a target just so you can try to hit it. You set a target because you want to hit it.

I am not discounting the effort and the learnings you gain from doing the work to meet a goal. This all very important. I am just saying that you do not lose sight of the bottomline – you have to complete the goal.

I hope this random thought helps you to be more Agile. 😊

Thoughts on Asynchronous Communication

Lately I have been reading about Asynchronous Communication. It is an interesting topic to me because it plays an importantly role in working remotely. What is Asynchronous Communication? Here is a definition I really like:

Asynchronous communication is the art of communicating and moving projects forward without the need for additional stakeholders to be available at the same time your communique is sent.

Embracing Asynchronous Communication by GitLab

Examples of Asynchronous Communication

A number of activities we do regularly, falls into the category of Asynchronous Communication. In addition, advancements in technology have been making them easier to do. We do these activities to avoid long and draining meetings, control our focus, manage timezone differences, and work with more flexibility in how we allocate our working hours.

Collaborating in Documents

Google has made it easy for us to share documents with others. Software like Google Docs, Spreadsheets, and Slides, make it easy for us to help one another in writing documents. These tools allow us to give others, editor or commenter access to documents we share with them. This is one form of Asynchronous Communication.

We do this when we want to get feedback for what we have written. We share the document and grant commenter privileges and our colleagues can read it at their own time and post comments on the document for us. We do not need to come together for a meeting, we just set expectations on when we want to get the feedback.

We do this when we write a document together with our co-workers. We share edit privileges and everyone contributes to the content being written. Again, we do not have to be in a meeting to do this together. Each contributor takes the responsibility of reading what has been written so far, checking the history of the document, editing what they want to change, and adding more content. Each person can do this at their own pace just as long as it falls within the expectations of the group on when they want to finish the document. In other cases, writing may never be “done”, the document evolves over time.

Chatting

Chatting can be a form of Asynchronous Communication. When you send a message with the expectation that it is ok if the recipient does not respond immediately, that is Asynchronous Communication. Sometimes people would also say that they are busy and they will get back to the chat message as soon as they can. This century, chatting has become a natural form of communication for everyone.

An important behavior to develop is managing when we respond to chats. You can manage the way you are notified by your chat tools. Working agreements can be set to have a shared understanding about responding to chats. You can set the appropriate status (like busy) in your profile. It is very important as well to just have only one chat tool used by the company / organization. You don’t want the burden of using and managing multiple tools.

Emails

I think it is unfortunate how email got a bad rep over the years. It doesn’t help that the marketing for collaboration tools commonly say “they should replace email”, “better than email”, “don’t bother with emails”. I consider email to still be an important form of Asynchronous Communication. I think if you manage your inbox properly you can leverage the advantages of using email.

I find emails helpful in collaborating on straightforward tasks or mini-projects. One recent experience I have in using emails for this kind of effort, is when my fellow Agile Coach and I were tasked with finding a good online Kanban tool. Our boss gave us the details of the task and instructions in an email. We did not have questions because it was all clear and the criteria for a “good tool” were well-defined. We were also given candidates to look at. I responded thru email to accept the task and give an estimate of how long it will take me to finish my assessment. My fellow Agile Coach responded in the same way. The next email we sent individually included the results of our assessments. From the results there was clearly a winner among the tools and we have made our pick. We did not meet, we just exchanged emails.

Training Videos

For teaching and sharing knowledge, training videos have become indispensable. The investment in making the videos can easily be paid off by the reusability of the training provided by the videos. It feels good when you have control over how you go through the training sessions. When you feel you need to review a part of the training, you can just rewatch it. Sure you lose the ability to interact with the trainer and other participants but most of the time you don’t need that. Most of the time you just need to digest the knowledge from the videos and apply it in your work. For internal trainings, the trainers could make time for conversations with the participants easily as they work together.

Pros and Cons of Asynchronous Communication

Let’s start with a list of advantages first:

• You can manage when you would allocate the time to digest information and make a response – as long as it is within the agreed expectations of people you work with
• You can avoid unnecessary meetings, freeing you from scheduling challenges and conflicts
• You can avoid disruptions – for you, as well as for your colleagues
• You have a recorded history of changes and exchanges, most tools you would use for Asynchronous Communication provides this feature

And then here are some disadvantages I can think of:

• Things will “fall through the cracks“ if you and your workmates don’t have discipline to follow-through with agreements on Asynchronous Communication
• You might misuse Asynchronous Communication
• Requires managing and organizing of numerous files, online resources, and tools
• You may forget to respond, participate and provide feedback

The disadvantages I listed can be overcome if you and your colleagues have a shared understanding of working agreements, ownership for the success of your group, and a great sense of responsibility.

Closing thoughts

There are many other forms of Asynchronous Communication besides the ones I have discussed here in this post. The ones I wrote about are the forms I commonly use. Perhaps on another post I’ll talk about the other forms I know of.

Asynchronous Communication does not mean to eliminate meetings. It helps us in avoiding unnecessary meetings and saving time and effort. It makes us ask if we really a need a meeting, and consider other forms of communication which may be better suited for the need that we have.

Working with Remote Agile Teams: Retrospectives

Facilitating retrospectives is a tough challenge.  Facilitating retrospectives while working remotely is, most of the time, an even tougher challenge.  In Retrospective Meetings, the body language and non-verbal cues from participants is an important factor in the quality of the discussions and outcome of the meeting.  Not being able to see this, makes it really hard to do retrospectives while working remotely.  If you can have everyone on video in the online meeting for the retrospective, that is great, but even then you still have other challenges to face.

In this post, I share some learnings I have gained from facilitating retrospectives for remote teams.

Setting the stage

A big part of the effort in preparing for a retrospective meeting is understanding the context of the meeting. When you are co-located with the team in an office, it is easy to make observations, have quick chats with team members, and be “in-tune” with what is happening with the team. When working remotely you have to make an extra effort in connecting with the team. In doing so before the retrospective, you can make sure you have a good understanding about concerns the team would want to discuss in the meeting.

Flow of the meeting

When you are in an online meeting, it is easy to get distracted and lose track of what is happening in the meeting. As the facilitator of the retrospective, you need to guide the team through phases of the meeting. This is the flow of the meeting that I use:

1. Review action items and previous discussion items
2. Generate new discussion items
3. Select items to discuss
4. Agree on new action items and improvements to do
5. Closing of the meeting

During the meeting, I make sure to state clearly the phase or step we are in.  Groupmap also helps in directing the flow of the meeting.  In the tool there are visual indicators and UI interactions which helps remind participants about the phases of the meeting.

Facing Challenges

Encouraging active participation, dealing with periods of silence, and good engagement of participants in the meeting are common challenges encountered during retrospective meetings.

I think that in meetings with remote teams it is hard to avoid calling out names of individuals to have them speak. I usually want to avoid doing this, because I think participants should speak up whenever they want to say something and that they can choose to stay silent if they really have nothing to add to the discussion. However, calling out names can help participants take turns talking, like when two or more people start answering a question at the same time during the meeting. Calling out names can also be, sometimes, the only way to encourage participation especially if the team is newly formed and is just starting to get to know one another.

In online meetings without video, long periods of silence can be more uncomfortable as participants can’t see each other. I learned that as a facilitator, you should allow this period of silence to go on without speaking up. This gives the team the space they need so they can push themselves to be more engaged in the meeting. Eventually someone will speak up. Having video and being able to see one another makes dealing with this challenge easier. Everyone can see the body language of one another and the facilitator can also use the non-verbal cues for better handling of the period of silence.

Sometimes the team may not be in the mood for doing a retrospective.  Sometimes they are too busy with their current workload and would want to just focus on that.  In these instances, it may be more helpful to the team to cancel the retrospective.  I have also ended retrospective meetings early when I have observed that the team’s energy is quite low or they are not interested in doing the retrospective.  This does not mean that you would not be having retrospectives anymore, rather the team just needs space and time to overcome the current challenge they are facing.

Same old, same old

Overall having a retrospective meeting with remote teams is almost the same as having it with a co-located team. As a facilitator, you make sure that the team is engaged and actively participating as they discover improvements that they want to make to become a better team.

Working with Agile Teams Remotely: Planning and Backlog Grooming

The team I am currently coaching follows Lean Software Development and uses Kanban. For us the weekly planning meeting involves discussing the Product Backlog Items (PBIs) we have ready for implementation, and agreeing on what we think we can get done for the week. We hold backlog grooming meetings as needed, when there are PBIs to be estimated by the team. At the least we have a grooming meeting once per week. On this second blog for the “Working with Agile Teams Remotely” series I am writing, I will share what it is like for us to do planning and grooming meetings.

The Tools

We use Zoom for our online meeting. Sharing your video is encouraged but not required. Screen sharing is done as needed, usually it is the Product Owner who is sharing his screen as he explains details of PBIs. As I said in my previous post, we do not experience any issues in audio quality while we are doing screen sharing so it really helps in having a good understanding of what is being discussed in the meeting. Sometimes we would record the meeting so that team members can review it when they need to refresh their memory on what has been discussed. Zoom has a nice feature which allows you to record the meeting on the cloud. This way it is readily available to the team to view it and you don’t have to bother with uploading / downloading a video file.

Our Kanban board is on our instance of LeanKit. It is expected that everyone in the planning meeting is looking at the board on LeanKit as needed. Information about the PBI is stored on the card representing it on our Kanban board. This substitutes for being able to stand in front of a physical board, discussing the plan for the week.

For estimating PBIs we play Planning Poker.  We do this on planningpoker.com which is easy to use and easy to customize according to your needs. You only need an account for the moderator of the game and the rest of the players just have to click on a link to join a game. The tool has all the features you need to play a proper Planning Poker game with a team.

Challenges

One of the main challenges in doing planning and grooming meetings with a remote team is maintaining the focus of the members. It is easy to get distracted and get disengaged from the meeting, especially if you are not sharing video. Ideally when you meet in person, the attendees of the meeting would not bring their laptops to the meeting and you can easily see if they are paying attention to what is being discussed. If you are in an online meeting, the attendees may be viewing something else on their own screens or maybe getting distracted and spacing out because of other distractions in their home offices.

You may also get challenged by looping discussions. Sometimes expressing ideas in online meetings can be more difficult compared to in-person meetings. You lack the visual cues which can help you in explaining. There is also no easy way of breaking up a conversation. When you are in the same room, a simple gesture like raising your hand can signal the need to break the discussion. In an online meeting you have no choice but to speak up and break up the conversation as politely and as nicely as you can.

These challenges do get easier as you gain more experience in holding this kind of meetings with remote teams. It’s part of the growth of the team, the more meetings you do with them, the better the next ones will be.

 

Generous Gratitude and High Performing Teams

At the start of this new year, 2019, our pastor from church encouraged us to practice having generous gratitude for everything that God does for us.  One of the suggestions we were given is to say a prayer of thanks every morning.  This would develop the habit of always being thankful to God. This got me into thinking about how practicing generous gratitude can also help Agile teams.

If Agile Teams are expected to go on a never-ending quest of improving how they work, then positive reinforcement should happen and promote desired behaviors.  I think expressing gratitude and saying thank you goes a long way in positive reinforcement.  And it’s just an easy and simple gesture to do.  I think this should be a habit of a high performing team.

This also ties into the Agile core value of Respect.  I believe that saying thank you to someone who helped you in anyway shows your respect to that person.  In return, that person will feel good about being able to help you and I think you will also earn that person’s respect.  This leads to better collaboration.  Building up respect for one another also develops trust among team members.

There is no denying that it feels good to be appreciated for what you do.  Expressing gratitude to one another should be a habit of any team.  It will surely help in being Agile. And this is for everyone on the team.  Yes, even for the Scrum Master or Agile Coach.  While people on those roles are often the ones doing the thanking, they also feel great when they are appreciated.  Just because coaches don’t seek out attention and recognition doesn’t mean they won’t be happy receiving some thanks once in a while.

Thank you for reading.