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.

Scripture-based Agile Coaching: Staying Out Of Arguments

A few years into my professional career, I was a Software Developer back then, I was a hot-tempered fool who easily got into arguments. I was proud of my accomplishments and I felt that I always had the right thing to say. I felt that I always had something to contribute, something important to say.

Fortunately, through the years and through many humbling experiences, I have gained wisdom and self-control. Many Bible verses have helped me learn and relearn this lesson of having more restraint and not getting into pointless arguments. This verse is one I have read recently:

Any fool can start arguments; the honorable thing is to stay out of them.

Proverbs 20:3

One main reason I easily got into arguments, is because I was in a hurry to express my point of view. I hastily assume that I understand what I am hearing and quickly form my response. And most of the time I ended up having the wrong understanding and being a fool. To grow out of this behavior I have taken to heart one of the habits of effective people as defined by Steven Covey: “Seek first to understand, and then be understood.”

This change helped me grow to become a better Agile Coach. I can form healthy working relationships with my colleagues. These relationships are based on trust, respect, and honesty, and not on position nor power. I have found my influence growing, allowing me to do my best to help people do their best.

Scripture-based Agile Coaching – Quick to Listen, Slow to Speak

I am a Christian. I believe in God. I believe God sent Jesus to save us from death for our sins, and give us the gift of eternal life. I believe in the Bible and I study it. I have found that there are a lot of Bible verses that speak to me when I think about my work as an Agile Coach. Here is one of them:

Understand this, my dear brothers and sisters: You must all be quick to listen, slow to speak, and slow to get angry.

James 1:19 New Living Translation

A great Agile Coach should be a very good listener. Through the years I have found myself listening more and speaking less. I do my best to get a good understanding of situations I encounter by listening intently to what others have to say. I make sure to do this first before I speak. This gives me time to carefully think about what I am going to say.

This has been a quite a struggle for me. I am an expressive person with an extroverted personality. I can also be very impatient. In my earlier days as a Scrum Master, I was too eager to speak my mind. I dominated discussions and did not leave space for my colleagues to contribute. I made mistakes, a lot. I have embarrassed myself a number of times because of poorly thought out speech.

In time, I have learned to restrain myself. I improved my self-control and learned to be comfortable with silence in meetings, conversations or discussions. I valued listening more and more. One of Stephen Covey’s 7 Habits of Highly Effective People is “Seek first to understand and then be understood.” I always keep this in mind along with this verse from the Book of James. This helped me in becoming a better Agile Coach.

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

What the heck happened to Remote Agility in 2020?

So 2020 has come and gone, the year the Covid-19 pandemic started. And I did not write a single blog post, not even one! Guess I got some explaining to do. 😅

Well, after my last post in 2019 I was feeling a bit tired of writing. I was dragging my feet (or maybe my hands – for writing 😁) and I was just out of ideas. I planned to pick it up on the next year. 2020 had other plans though. It was a very challenging year. Everyone had to cope with a lot of changes. There were things and activities I had to drop, to focus on what I needed to do. So I did not find myself writing any posts on this blog for the year 2020. I lost sight of my purpose for writing on this blog, which is to share my learnings and insights as a way to contribute to the Agile community. And to help people like me striving to be Agile while doing remote work.

You lose some…

The last year brought significant changes to my lifestyle. My family bunkered down and mostly stayed at home. I can count, using just one hand, the number of times we (all of us, together) went out, and these were just to do drive-bys and drop-offs to houses of relatives and church. I get to go out more because I am the one getting the essentials we need: groceries, water, medicine, supplies from school, and the occasional take-out from restaurants 😄. All of this trips though was planned and executed so that it was fast, efficient (that it minimized the times I had to go out), and safe (done very carefully to lower the risk of exposure as much as possible). I had to be fast, I wasn’t comfortable with wearing face masks and face shields for a long time. This 2020, we have said goodbye (for now) to going to malls, taking trips to beaches and resorts, seeing family, relatives and friends, and enjoying nice meals at our favorite restaurants. It is sad, but we are still fortunate and blessed by God because we could have lost more. I did not lose my job. We did not lose our health. We still have the things we need daily.

Another big change for me is, I had to put in more time and effort in supporting my kids as they do school at home. It felt like I have gone back to school myself! 😅 You’d think that with just staying at home you’ll have more time on your hands, but it turned out for me, I had to do more than I have the time for.

You win some…

Letting go of some things in your life gives space to new things. Last year I increased my effort and time for studying the Bible and meditating on God’s Word. I also grabbed the opportunity to serve in our church, Saddleback. My wife and I volunteered to help in church activities that are done virtually. It was a wonderful chance to apply what I have learned in being Agile and working remotely to serving God and our church.

I have improved my skill in playing the piano! 🥳 We used the SimplyPiano app for self-learning. It was great how one subscription can be used by the whole family, so my kids also learned something new!

My wife gave me a round studio light for my birthday last year and this allowed me to level up my toy photography. 😁 I also borrowed her more powerful camera (more powerful then my phone camera) for better shots. The picture at the start of this post, the picture of Iron Man, that is one of my favorite shots.

That’s life!

If there is one thing that I take seriously in being Agile, it is the ability to adapt to changes. That’s life, change is inevitable. 2020 was a hard year. I think it would have been harder for me if I did not have the experience of working at home and being Agile. Last year, remote work strongly said…

And I was like…

Coming back to the blog

And now I am writing again on this blog. I have learned that “it’s ok not to be ok” (from a Netflix series 🤣). However, I do still want to share my insights and learnings and help anyone who would care to read my blog. So here I am, ready to pick it up again. I’m sorry for being absent. I am grateful for your time in reading what I have to share. I hope it helps you in anyway it can.

A Master of the Agile Arts

In the years that I have been working as a Scrum Master and Agile Coach, I have been blessed with superb mentors who I look up to.  I believe that having a mentor is key to continuous improvement and growth. My current mentor is Ken Furlong. He is the Director of Product in eComEngine and he is an experienced Lean and Agile Coach.

I would often sit-in on meetings where Ken would discuss Lean and Agile principles to new employees joining the company.  I learn a lot from observing how he presents and shares ideas and insights.  He is confident and comfortable in his delivery, there’s a certain finesse in how he answers questions showing his deep knowledge and practical wisdom of Agile principles and Lean practices. He speaks clearly, is concise and straight to the point.  I already have a collection of the analogies he uses to explain principles in a way that people can relate to, making it more easy for the audience to understand the principles.

I asked Ken some questions, centered on being Agile while working with remote teams,  and on this post I am sharing them along with Ken’s answers.

img_5616

As an Agile Coach what is your “plan of attack” when you first start working with a remote team?

The plan is generally the same as when beginning work with a co-located team.  The coach needs to orient themselves to the team’s environment and spend most of their time observing dynamics and just getting to know the team members.  As with a co-located team, part of that process is paying special attention to how their environment (physical or virtual) impacts (for better or worse) the team’s communication and collaboration.  Just as physical space and physical distance can encourage or discourage communication and collaboration, so too can “virtual space” and “virtual distance” (think tooling and infrastructure).  The general principles a coach brings to bear on the situation are pretty much the same, what changes are the specific tactics and recommendations that can vary widely depending on the context.

What do you think are the top three traits of a successful remote Agile team?

It’s hard to force rank traits in general because each situation is different and the different contexts may require different traits on the part of the team.  That being said, it will be hard for any remote team to be successful without these three:

  1. Individuals are self-motivated
  2. The entire team is aligned on the team’s goal(s)
  3. The team has high communication saturation and individuals are highly interactive with one another throughout the day

It’s not to say that those three are sufficient for the team to be successful but they are necessary, in my experience.

As an Agile leader what are the top 5 challenges you have faced when effecting change in a company composed of remote employees?

  1. A lack of engaged team members (which is often bred by siloing, that itself is a result of the remote environment not being compensated for properly)
  2. A dearth of feedback (verbal and non-verbal) to the coach (often exacerbated by a lack of good communication tools, but fundamentally based on the fact that you are not physically co-located)
  3. A lack of data about the team members’ behavior day-to-day
  4. An inability to simply observe without having to “set it up” over a phone or video conversation
  5. An inability to respond to moment-to-moment successes, failures, surprises, learnings, etc.

Remote Agile Leader

Before I joined eComEngine, I was working for companies/organizations doing outsourced software projects. It was my first time to work for a company with its own products as its main revenue stream. It was a refreshing change for a Scrum Master who had to deal with explaining what being Agile means to external stakeholders. The icing on top is the leadership team of eComEngine places a high value in being Agile. I got recruited by the company because they were looking for a Scrum Master. On the previous companies I have worked for, I was either a developer turned Scrum Master because the company wanted to try being Agile or I was a recommended hire because the company wanted to try being Agile. Even before I joined eComEngine, its leadership team has decided that they should be Agile.

Derek McMillan is part of that leadership team. He is the Director of IT for eComEngine and my direct supervisor. He is a strong supporter of being Agile. He has a good understanding of the principles and values and actively advocates being Agile to the whole company. In this blog post, I share Derek’s answer to some of my questions about being an Agile leader.

img_4854

How did you first learn about being Agile?

I started studying Agile about 8 or 9 years ago while working at eComEngine. Up until that point, I had mostly worked with very small developer teams (1 or 2 devs max), but we had plans to scale our developer count up, in order to work on more products at a time. I knew that we would need a more structured way to track work as we added developers.

I had been reading about Agile (Scrum and Kanban) on various tech forums for years, and the concepts seemed very interesting and promising to me. I discussed the idea of trying out Kanban with our company owner, and we both thought it would be a step in the right direction. We started using Jira in Kanban mode, and after a few months both the owner and I became more and more intrigued by Scrum. From there, we started organizing our teams more in alignment with Scrum practices.

As we learned more about Scrum and ran into pain points, we decided that it would be a good idea to consult with an Agile Coach. That engagement illuminated how poorly we had been implementing the various facets of Scrum, and we slowly evolved towards a more pure Agile Scrum approach. This involved us hiring our first dedicated Scrum Master as well as implementing and embracing the requisite meetings and cadences.

As Director of IT for a company with remote workers, what made you choose to be Agile?

The choice really came down to deciding between Waterfall and Agile. I don’t know that the remote aspect of our company was much of a deciding factor. For us, Agile just made more intuitive sense because it addressed so many of the pain points that we had historically hit in a more Waterfall-style approach.

Specifically, Scrum endeavoured to limit developer disruptions by adhering to structured Sprints. Agile assumed that priorities and requirements would be changing over time and accounted for that. We also liked how the teams were self-organizing and could work at a sustainable pace indefinitely as we were keen to create an enjoyable work environment.

What do you think are the top challenges in being Agile while working remotely?

To me, the biggest remote challenge is collaboration. Remote collaboration is difficult whether you’re talking about Agile or any other aspect of business, and central to effective collaboration is effective communication. It is nearly impossible to achieve the same level of interpersonal communication in a distributed environment versus in a traditional office space.

In a company of any size you deal with many different personalities, and in communication there are both verbal and non-verbal cues which affect how effective that communication ultimately is. In a remote environment where you cannot rely on sufficient bandwidth for video conferences, you eliminate all non-verbal cues from the interaction which makes it difficult to have great communication. This impacts everything from fostering engaging retrospective meetings to just the simplest form of one on one meetings. It’s difficult to replace the ability to look the other person in the eye.

What are your recommendations for leaders in company with remote workers, who are wanting to be Agile?

As a leader in a remote company, your first objective needs to be to hire the right people. For any company to be successful, Agile or otherwise, you have to surround yourself with people with strong work ethics who earn your and each other’s trust. Trust is best earned in a remote environment by being responsive to all communications. A direct message from a coworker is the remote equivalent of your coworker knocking on your office door or sticking their head over your cubicle wall. If you do not respond consistently it has the same effect as you never being at your desk in a physical office.

Provide best in class collaboration tools to help mitigate the challenges of remote communication. This includes products that facilitate instant messaging (Skype, Slack, Google Hangouts, etc), group meetings (Zoom, GoToMeeting, Google Hangouts, Amazon Chime, etc) and work coordination (LeanKit, Jira, Rally, etc). You should also invest in online tools which help to better facilitate Agile ceremonies like backlog grooming and retrospectives.

Perhaps the most important requirement for leaders in any Agile company is for them to drink the Kool Aid. If they are not 100% committed to being Agile, then they can never expect the rest of the company to be either. Expect your company’s Agile process to be a journey that has no end; you are always learning where you can do things better and adjusting to improve.