Easy Agile Podcast Ep.31 The Release Train Engineer + SAFe Summit 23

"I absolutely loved my conversation with Sarah, she shared some amazing advice that I can't wait to put into practice!"

We spoke about the agile mindset beyond IT & development teams, how teams such as marketing and finance are starting to adopt the methodology and the benefits of doing so.

In celebration of international women's day, we discussed the future of women in agile, and steps we should be taking to support one another towards an inclusive and enabling environment.

Be sure to subscribe, enjoy the episode 🎧

‍

‍

‍

Transcript

Caitlin Mackie:

Hello everyone and welcome back to the Easy Agile Podcast for 2021. Each episode, we talk with some of the most interesting people in tech, in agile, and in leading businesses around the world to share fresh perspectives and learn from the wealth of knowledge each guest has to share. I'm Caitlin and I'm the Graduate Marketing Coordinator at Easy Agile and your host for this episode. We are thrilled to be back and have some amazing guests lined up this season. So to kick us off, I'm really excited to be talking with Sarah Hajipour.

Caitlin Mackie:

Sarah has so much rich and diverse experience in the agile space. She's an agile coach, a business transformation leader, a project and program manager, and more recently a podcast host and author. She's the jack of all trades and has been in the business agility space for over 10 years. In this episode, Sarah and I chat about the significance of goal setting and in particular goal setting in unpredictable times. We chat about her most recent projects, the Agility Podcast with Sarah Hajipour and her book on Agile Case Studies.

Caitlin Mackie:

And of course with International Women's Day coming up, Sarah shared some amazing advice and her thoughts on the way forward for women in agile. She highlighted the importance of raising your hand and asking for help when you need it, as well as embracing qualities that aren't always traditionally thought of in leaders. It was such a thoughtful and insightful discussion. I got a lot of value out of our conversation and received some great advice, and I'm really looking forward to putting into practice. I know those listening will feel the same. Let's jump in.

Caitlin Mackie:

Sarah, thank you so much for joining us and spending some time with me today.

Sarah Hajipour:

Sure. Thanks for having me.

Caitlin Mackie:

So being our first guest for the year, I wanted to ask you about any new year's resolutions. Are you on track? Are you a believer in them or do you have a different type of goal setting process?

Sarah Hajipour:

That's a great question because we discussed this with a couple of friends and we realized new year's resolution is always going to be some kind of like a huge goal that we don't know if we're going to meet it or not. And thinking agile business agility and as an agile coach, I believe in the fact that let's have smaller goals and review them every three months, every six months and see where we at. Instead of looking into huge goals that we don't know what's going to happen because there's always a lot of uncertainties, even in our personal lives regarding the goals that we set up for ourselves. So yeah, that's how I look at it. Quarterly, quarterly personal goals. Let's say that.

Caitlin Mackie:

Yeah. Yeah. I love that. Yeah, I think if the last year has taught us anything, I think we can all agree how unpredictable things can become. So those original goals.

Sarah Hajipour:

That's true.

Caitlin Mackie:

Yeah. The original goals might have to take a couple of detours. So what would be your advice for setting career goals in uncertain times?

Sarah Hajipour:

That's a great question. For career goals I believe it really matters that you do something that you're interested in at least. If you still haven't found your passion, that's fine especially people like young professionals. It's okay if you haven't found your passion yet, but you can still follow a basically career path starting with things that you like to do, kind of you enjoy and you learn through the way.

Sarah Hajipour:

I was listening to one of the fashion icons on YouTube a couple of days ago and the interviewer was asking her, "What was your career path? How did you get to this place you are now?" And I loved what she told everybody, the students, and that was go and find a career, find a job and learn. You first need to learn a lot of skills before you decide what you're actually good at. You decide, you understand what's your weaknesses and your strengths, right? Because not all of us have these amazing ideas all the time and that's fine.

Sarah Hajipour:

I'm not very much pro-everybody has to be a visionary and everybody has to have like big, shiny goals and ideas. I think that's perfectly fine to just find the kind of job that or the kind of career path that you're comfortable with and then sometimes get out of your comfort zone and then discover as you go. Life is to explore, not to just push yourself on the corner all the time and just compare yourself with everybody else.

Caitlin Mackie:

Yeah. I love that. That's great advice. So you've recently added podcast host and author to your resume. Were they always career goals of yours?

Sarah Hajipour:

No, absolutely not. Well, I'm a little bit of an introverted person. So kind of sit in front of a camera even talking and having people hear me was always like, "Oh my God, I know I need to talk about this even with my teams and stuff," but I will do it only if it's necessary. What got me into podcasting was that I figured there's a lot of questions that I'm finding answers when I'm having conversations and meetups and in different groups, professional groups that I'm in. And I wanted other people to hear those as well. I talked to people who have great insights and have been way longer than me in the career. So I'm learning at the same time. And I wanted to share that learning with everybody else. That's the reason I'm doing the podcast.

Caitlin Mackie:

Yeah, that's great. Yeah, I love that. And I think you kind of touched on this earlier, but I think being in the agile space, sometimes it can be a nice reminder for you to have a bit of a focus, but then reflect and understand sort of where to be more effective and adjust accordingly. I know you mentioned that with your career goals, do you think that those agile principles can be applied beyond the usual use case?

Sarah Hajipour:

I do. I believe that it's a very intuitive like agile is a very intuitive way of working and a way of thinking. That's why now it's expanded to other industries. They didn't stay with DevOps and IT and development. It is now a lot of different industries adopting this because it's a mindset change. And just not just using scrum. It's not just using Kanban. It is about understanding how to be able to reflect on and adapt to the faster changes that are happening in the world. And that also applies to our personal lives as well.

Sarah Hajipour:

I mean, I used to have set goals when I was 18-years-old, I'm going to be this at 30, but did they happen? No. In some aspects I achieved much, much more. And in some aspects I just changed my goal. I think the changes that are happening in the world that are more rapid, it demands us to change as well. Yeah.

Caitlin Mackie:

Yeah. Awesome. So just to circle back a little bit there for your podcast just for our audience listening, what platforms can they access your podcast on?

Sarah Hajipour:

I'm on all of the main platforms. I'm in Apple podcasts. I'm in Spotify, I'm in Amazon. Most of the prominent podcast platforms.

Caitlin Mackie:

Awesome. And then just again, for our audience, your podcast is called the Agility Podcast with Sarah Hajipour.

Sarah Hajipour:

That's correct. Yes.

Caitlin Mackie:

Awesome. That's great. What do you think has been the most valuable lesson you've learned from your podcast so far? Is it something a guest has shared or something you've learned along the way?

Sarah Hajipour:

What I have learned, I have learned a lot from the people that I interview because I make sure that I talk to people who know more than me and have been in this field more than me, and in different industries. The main thing I would say is that agile business agility is about mindset rather than the tools and processes. And the fact that the world overall is moving towards a more human-centric way of working.So basically that's why I say agile is more intuitive rather than just following ABCD. Yeah. This is the core, the main thing that that I have learned from my interviewees.

Caitlin Mackie:

Yeah, amazing. You've also started writing a book at the moment. Can you tell us a little bit more about that? How did that project begin?

Sarah Hajipour:

I actually love this project. In this book, the way I actually started writing the book was the book came first and then the podcast happened. I attend a lot of meetups. So for young professionals and even for professionals who are very much skilled in what they do, meetups are great place to meet and expand your network and learn from your peers. So I was attending all of these and I was learning from people. And then I decided I really want to have one-on-one conversations with them. And eventually I figured that a lot of the agile coaches, a lot of executive levels and a lot of consultants, they have a lot to share, but I didn't see any platform that kind of unifies that.

Sarah Hajipour:

I said, "Okay what are the learnings that we can share?" A lot of the mistakes because of the meetups groups, people feel safe to share and be vulnerable. And I was in multiple meetups so I heard very similar stories from people, the mistakes that have been repeated by a coach somewhere else. So I thought that'd be a great idea to put these in agile cases. So it's going to be Agile Case Studies and share it with everyone so. Especially the young coaches or stepping into the business, there's a lot of unknowns. I don't want them to be afraid. I don't want them to think, "Okay, this is a huge task." There's always going to be a lot of unknowns.

Sarah Hajipour:

Yes, I just see that. I kind of want to give that visibility that everybody else is experiencing the same, even if they have 25 years of experience, which is amazing, right?

Caitlin Mackie:

Yeah.

Sarah Hajipour:

And that's the reason I started writing the book. So I interview with agile coaches and agile consultants that have been around at least five to 10 years and led agile transformation projects. And then from there, one of my interviewers once said, "You should do a podcast. I like to talk about this too." I'm like, "This is great" and that was like the week after I was like running around looking for tools to start my podcast.

Caitlin Mackie:

Oh, amazing. Sounds so good. What's the process been like? How have you found from ideation to where you are now, and then eventually when you're publishing it?

Sarah Hajipour:

For the podcast?

Caitlin Mackie:

For the book.

Sarah Hajipour:

For the book, so I go to these meetups and I listen to what's the coaches and the executives are sharing. The ones that are exciting for me are kind of a new for me, I will ask them, I connect with them over in LinkedIn and people are so open to sharing their experience with you. I've never had even one person said to tell me, "No, I don't want to talk about this or anything." People want to share. So I approach and I say, "Hey, I have a book outline or guideline. It's a two pager." I send it to them and I asked them if they are interested to talk to me about this and they let me know and then I'll select a time.

Sarah Hajipour:

And first session, it's like a half an hour. It's a kind of a brainstorming session. What are the key cases that they feel they want to share? Then we pick one and the session after that, they'll actually go through the case with me. I record it, draft it and then share it on Google Drive back and forth until we're happy with the outcome.

Caitlin Mackie:

Yeah. Awesome. Do you have a timeline at the moment? When can we expect to be able to read it?

Sarah Hajipour:

I'm looking forward to around the end of 2021, because it's 100 cases and I think that I'll have that.

Caitlin Mackie:

Yeah. Awesome. It's so exciting. Lots to look forward too.

Sarah Hajipour:

Thank you.

Caitlin Mackie:

Now, I also wanted to touch on International Women's Day is coming up and you've been in the agile space for a few years now. I assume you've probably witnessed a bit of change in this space. Have there been any pivotal moments that have sort of led to where you are today?

Sarah Hajipour:

Well, I think that a lot of women are being attracted to the agile practice, the different agile roles. And I have seen a lot more women as scrum masters, as product owners and as agile managers or agile project managers. A lot of different roles are being kind of flourishing in this area. And I've seen a lot of women contribute. One my goals actually in my book and on my podcast is to be able to find these women and talk to them regardless of where they are in the world. Yeah, I just feel that women can grow really in this area in the agile mindset, because women are more the collaboration piece.

Sarah Hajipour:

I can't tell we're less competitive. I haven't done research on that, but I have discussed it with people. Do you think that women are more collaborative rather than competitive? Because competition is great, but you need a lot of collaboration in agile and a lot of nurturing. You need to have that nurturing feeling, the nurturing mindset, that's what a scrum master does. One of the key characteristics of a scrum master has to be they have to have this nurturing perspective to bring it to the team.

Caitlin Mackie:

It's funny you mentioned because I actually have read some stuff myself about women typically possessing more of that open leadership style and that open leadership seems to complement the agile space really nicely so.

Sarah Hajipour:

That's exactly, yeah.

Caitlin Mackie:

Yeah. Yeah. That's great and I think there's lots that we can take from that, open leadership and the direct leadership. So men and women coming forward and finding that middle ground and yeah, I feel like agile is a great space to do that in?

Sarah Hajipour:

Yeah, I totally agree. Yeah.

Caitlin Mackie:

Yeah, yeah. So what drove your passion? I guess what made you want to pursue a career in this space?

Sarah Hajipour:

I love the collaboration piece and I love the vulnerability because like people are allowed to be vulnerable and in the teams that they work in. And it is a culture that is more human rather than super strict. We're not allowed to make mistakes. We're not allowed to be wrong. Leaders are supposed to know everything right off the bat. But in reality, that's not the case. Leaders have to feel comfortable not knowing a lot of things that are not even known. But a lot of times I always say we're in the unknown unknown zone. And in that zone, even leaders are not supposed to know everything.

Sarah Hajipour:

So a lot of it starts with what are the other things that I learned from my interviewees is that it all starts with the leadership. So the agile transformations, the leaders have to first create that atmosphere of collaboration and of trust and psychological safety among themselves. And then only then they can help with teams to be able to thrive in those kinds of atmospheres as well.

Sarah Hajipour:

Women in agile and women in leadership. I like to say and what I see is a lot of men and women both that are changing their perspective from process of tool-centric to people-centric because it works better for everyone. And I see change really happening in all industries. I see it in retail. I see it in construction, obviously in IT, in finance system. And there's men and women like hand-in-hand trying to kind of embrace this way of thinking and this way of working.

Sarah Hajipour:

And women are being more comfortable to grow and kind of raise their hand and say, "Hey, I can make each page. I can take this role" because they understand because they bring that psychological safety that women for ages, it has been a workplace has been something that was mostly men and we're gradually getting into the workforce or the business world as females. So that psychological safety has allowed women to raise their hand and grow in different roles and leadership roles obviously.

Caitlin Mackie:

Yeah, yeah. I couldn't agree more. Has there been any resources or networks, things like that that have helped you along your journey?

Sarah Hajipour:

Learning from everybody else like creating a network, expanding my network to kind of coming in and saying, "Hey, I don't know. I want to know." There is all of these amazing things that are happening. I like to understand how this works and I remember it was one of these founders. Who's the founder of Apple? Oh my God. Don't tell me.

Caitlin Mackie:

Steve Jobs.

Sarah Hajipour:

I love this quote from Steve Jobs that says, "There has never been a time where I asked for help and people didn't help me." So just raise your hand and say, "I need help." And what does that help that I need? I need to know about this. What does it mean? What does scrum mean to you? How does it work in your industry? How does it work? And really I think that was the key for me up until now to connect with people and just be vulnerable and let them teach me.

Caitlin Mackie:

Yeah. I think my next question would be about how do we amplify that diverse and empowered community of women and our job in increasing the representation of women in agile? And yeah, what do you think is key to achieve a supportive and enabling environment?

Sarah Hajipour:

What I have seen and realized is that women really need to be and are being more supportive of each other. There was a study in HBR, Harvard Business Review in 2016 that said, "If there is only one woman in the pool of the interviewees, there's a zero chance for that woman to get the job, even if she's the best." So this calls for not which women are actually working great on that. Not being the queen bee, but also engaging and including other women. Because the more women in different roles, the more we are going to be receptive in those communities. That I think is a key that we understand that and support each other, help each other, build the communities around it.

Sarah Hajipour:

There is a community Women in Agile that is in different cities and different parts of the world that I'm a member of as well doing a great job. It's not just women actually in those groups. I see men participating as well, but it's predominantly women are trying to give each other insights from all aspects of the agile practices, the agile ways of working and stuff. Yeah.

Caitlin Mackie:

Yeah. So I think what's the way forward? I guess what's your prediction for women in agile? What do we need to do to continue that momentum?

Sarah Hajipour:

I think women will do great in anything and everything they put their minds in, regardless. We're human bottom line and we all have this potential to be able to grow in whatever we put our mind and heart on, regardless of our gender. So I would love for women to kind of be able to get that holistic perspective that regardless of their gender, they can do anything and they are, we are.

Sarah Hajipour:

We read about other women who have been successful in the fields of business that you felt that probably women can't do like women astronauts. There are women physicists. Women engineering leads and all of these that have been less common. The world is changing for the better and that's great.

Caitlin Mackie:

Yeah, yeah. I absolutely love that

Sarah Hajipour:

It's a great time to be alive.

Caitlin Mackie:

Yeah. That's exciting. Yeah, exactly.

Sarah Hajipour:

Yes.

Caitlin Mackie:

Yeah. I definitely think that we are beginning to see a huge increase and the visibility of female role models across so many industries. So it's great to have that. But Sarah, this has been such a great conversation. I wanted to finish with a final question for you and that was if you could give one piece of advice to women just starting their career in their industry, what would it be?

Sarah Hajipour:

I would say maybe the best advice that I can give is that we do have the power. And we need to look, number one, beyond gender and kind of have that belief that we can do anything that we want. And second is don't be shy to open up and build your community like build a community, join a community of agile practitioners of agile coaches, even people, specifically people who know more than you.

Sarah Hajipour:

And don't be afraid to ask help. Don't be afraid to say, "Hey, I'm new to this and I love to learn from you guys." Don't be afraid to put yourself out there and you're going to learn a lot that you wouldn't even expect. Just like you're going to get the result so you're going to hear things beyond what you've expected. There's a lot to human potential that could be unleashed when you just put yourself out there and let others contribute to your growth.

Caitlin Mackie:

That's amazing. That's great advice, Sarah. Loved every minute of our conversation. So thank you so much for joining me today. I really appreciate it.

Sarah Hajipour:

My pleasure. Thank you so much for having me.

In this episode, I was joined by Sherif Mansour - Distinguished Product Manager at Atlassian.

We spoke about styles of product management and the traits that make a great product manager. Before exploring the idea of a shared brain and the role of a product engineer.

Sherif has been in software development for over 15 years. During his time at Atlassian, he was responsible for Confluence, a popular content collaboration tool for teams.

Most recently, Sherif spends most of his days trying to solve problems across all of Atlassian’s cloud products. Sherif also played a key role in developing new products at Atlassian such as Stride, Team Calendars and Confluence Questions. Sherif thinks building simple products is hard and so is writing a simple, short bio.

Hope you enjoy the episode as much as I did. Thanks for a great conversation Sherif.

"Thoroughly enjoyed my conversation with Jon, he shared some great perspectives on the impact of the Agile manifesto" - Amaar Iftikhar

Amaar Iftikhar, Product Manager at Easy Agile is joined by Jon Kern, Co-author of the Agile Manifesto for Software Development and a senior transformation consultant at Adaptavist.

Amaar and Jon took some time to speak about the Agile Manifesto. Covering everything from the early days, ideation, process, and first reactions, right through to what it means for the world of agile working today.

They touch on the ideal state of an agile team, and what the manifesto means for distributed, hybrid and co-located teams.

We hope you enjoy the episode!

Transcript

Amaar Iftikhar:

Hi everyone. Welcome to the Easy Agile Podcast. My name is Amaar Iftikhar. I'm a product manager here at Easy Agile. And before we begin, Easy Agile would like to acknowledge the traditional custodians of the land from which we broadcast today, the people of the Dharawal speaking country. We pay our respects to elders past, present, and emerging. And extend that same respect to all Aboriginal, Torres Strait Islander, and First Nations peoples joining us today.

Today, we have on the podcast Jon Kern, who is the co-author of the Agile Manifesto for Software Development and an Agile consultant. If you're wondering, you're correct. I did mention the Agile Manifesto for Software Development. The Agile Manifesto. So Jon, welcome for being here and thank you for joining us.

Jon Kern:

Oh, my pleasure, Amaar. Thank you.

Amaar Iftikhar:

Yeah, very excited to have you on. Let's just get started with the absolute basic. Tell the audience about, what is the Agile manifesto?

Jon Kern:

Well, it's something that if you weren't around, and I know you're young, so you weren't around 21 years ago, I guess now, to maybe understand the landscape of what software development process and tooling and what most of us were facing back then, it might seem like a really obvious set of really simple values. Who could think that there's anything wrong with what we put into the manifesto? But back in the day, there were, what I practiced under as a... I'm an aerospace engineer, so I was in defense department work doing things like fighter simulation, F-14 flat spins and working with a centrifuge and cool stuff like that. And subject to a mill standard specification, which makes sense for probably weapons systems, and aircraft manufacturing, and all sorts of other things. But they had one, lo and behold, for software development. And so there was a very large, what I would call heavy handedness around software development process. We call it heavyweight process. Waterfall was the common term back then, and probably still used today.

And there were plenty of, I would say the marketing juggernaut of the day, IBM and Rational unified process, these large, very much like Safe. Where it's a really large body of work, awesome amount of information in it, but very heavy process even though everything would, say you tailor it, it could be whatever you wanted. I mapped my own lightweight process into REP for example. Sure. But the reality was we were facing kind of the marketplace leader being heavyweight process that was just soul crushing, and from my perspective, wasting taxpayers' money. That was kind of my angle was, well, I'm a taxpayer, I'm not going to just do this stupid process for process sake. That has to have some value, has to be pragmatic. So lo and behold, there were a handful of us, 17 that ended up there, but there are a handful of us that practiced more lightweight methods. So the manifesto was really an opportunity for coming together and discovering some of the, what you might think of as the commonality between many different lightweight practices. There was the XP contingent. I first learned about Scrum there, for example. Arie van Bennekum, a good friend, he taught us about DSDM. I don't even remember what it stands for anymore. It was a European thing.

Alistair and Jim Highsmith, they had, I forget, like crystal methodologies. So there was a fair amount of other processes that did not have the marketing arm that erupted, or didn't have the mill standard. So it was really all about what could we find amongst ourselves that was some sort of common theme about all these lightweight processes. So it was all about discovering that, really.

Amaar Iftikhar:

You all get together, the principles kind of come to fruition, and let's fast forward a little bit. What was the initial reaction to the original manifesto?

Jon Kern:

Yeah, it was even kind of funny that the four values, the four bullets is as simple as it was. The principles came a bit later. I want to say we collaborated over awards wiki, but the original... If you go to Agile uprising, you can see I uploaded some artifacts, because apparently I'm a pack rat. And I had the original documents that Alistair probably printed out, because he was the one... He and Jim lived there near Salt Lake City. So it was like, "Hey, let's come here." And we like to go skiing, so let's do it here. So he arranged the room and everything. And so there's some funny artifacts that you can find. And the way that it actually came about was an initial introduction of each of us about our methods. And really I think a key, we left our egos at the door. I mean I was a younger one. Uncle Bob, some of these, he was at Luminar, I know I have magazines still in the barn that he was either the editor of, or authors of for people who don't remember what magazines are. Small little booklets that came out. So Uncle Bob was like, Ooh, wow, this is pretty cool.

And I wasn't shy because I had a lot of experience with heavyweight methods. So I really wanted to weigh in on... Because I had published my own lightweight method a few years earlier. So I had a lot of opinions on how to avoid the challenges of big heavyweight process. So the culmination as we were going out the door and after we had come up with the four values was I think Ward said, "Sir, want me to put this on the web?" And again, this is 2001 so dot com and the web's still kind of new so to speak. And we're all like, yeah, sure, why not? What the hell, can't hurt. We got something, might as well publish it. I don't think to a person, anybody said, "Oh yeah, this is going to set the world on fire because we're so awesome." And we were going to anoint the world with all of this wonderful wisdom. So I don't think anybody was thinking that that much would happen.

Amaar Iftikhar:

Yeah. So what were you thinking at that time? So how would the principles that you had come up with together, was that maybe just for the team to take away? Everyone who was there? What was the plan at that time?

Jon Kern:

I think it was a common practice. Like I said, there were other groups that would often meet and have little consortiums or little gatherings and then publish something. So I think it was just, oh yeah, that's a normal thing to do is you spent some time together and you wrote things down, you might as well publish it. So I think it wasn't any deeper than that other than Bob, I think Bob might say that he wanted to come up with some kind of a manifesto of sorts or some kind of a document because that's I think what those sort of... I was never at one of those gatherings, but you know, you could see that they did publish things. I have a feeling it was just something as innocent as, well we talked, wrote some things down, might as well share it.

And then the principles, there were a lot of different practices in the room. So some of what I would say the beauty of even the values page is the humility at the top is it's still active voice. We are uncovering not, hey all peasants, we figured it all out. No, we're still uncovering it. And the other thing is by doing it, because I'm still an active coder. And plus we value this more on the left, more than on the right. Some people might say it's a little ambiguous or a little fuzzy, but that's also a sign of humility and that it's not A or B. And it really is fuzzy, and you need to understand your context enough to apply these things. So from a defense department contracting point of view, certainly three of the four bullets were really important to me because I learned... Sure, we did defense department contracting. But it's way more important to develop a rapport with the customer than it is... Because by the time you get to the contract you've already lost, which goes along with developing a rapport with the customer, the individual.

And one of Peter Codes, when we worked with customers and whatnot, one of our mantras was frequent tangible working results, AKA working software. You can draw a lot and you can do use cases for nine months, but if you don't have anything running, it's pretty, I would guess risky that you don't have anything, no working software yet. So it really was I think an opportunity to share the fact that some people thought two weeks and other people thought a month. Even some of the print principles had a pretty good wide ranging flexibility so to speak. That I think is really important to note.

Amaar Iftikhar:

Yeah, no, absolutely. And it makes sense. Did you or anyone else in the room at that time ever imagine what the impact downstream would be of the work that was being done there?

Jon Kern:

Not that I'm aware of. I certainly did not. I remember a couple times in my career walking in and seeing some diagrams when I worked with the company Together Soft, and we'd build some cool stuff and I'd see people having some of the... Oh yeah, there's a diagram I remember making on their wall. That's kind of cool. But nothing near how humbling and sort of satisfying it is. Especially I would say when I'm in India or Columbia or Greece, it almost seems maybe they're more willing to be emotional about it. But people are, it's almost like they were freed by this document. And in some sense this is a really, really tiny saying it with the most humility possible. A little bit like the Declaration of Independence, and the fact that a handful of people... And the constitution of the United States. A handful of people met in a moment of time, never to be repeated again and created something that was dropped on the world so to speak, that unleashed, unleashed a tremendous amount of individual freedom and confidence to do things. And I think in a very small, similar fashion, that's what the manifesto did.

Amaar Iftikhar:

As you mentioned, there was a point in time when the manifesto was developed and that was almost over 20 years ago. So now the way of working, and the world of working has drastically changed. So what are your thoughts on that? Do you see another version coming? Do you think there are certain updates that need to be made? Do you think it's kind of a timeless document? I'd love to hear your thoughts on that.

Jon Kern:

Yeah, that's a good question. I personally think it's timeless and I welcome other people to create different documents. And they have. Alistair has The Heart of Agile, Josh Kerievsky's got Modern Agile.

There's a few variations of a theme and different things to reflect upon, which I think is great. Because I do believe, unlike the US Constitution, which built in a mechanism to amend itself, we didn't need that. And I believe it captured the essence of how humans work together to produce something of value. Mostly software, because that's what we came to practice from, is the software experience. But it doesn't take a lot of imagination to replace the word software with product or something like that and still apply much of the values that are there with very, very minor maybe adjustments because frequent tangible working results.

There might have to be models, because you're not going to build a skyscraper and tear it down and say, "Oh, that wasn't quite right," and build it again. But nonetheless, there are variations of how you can show some frequent results. So I think by and large it's timeless. And I would challenge anybody. What's wrong with it? Point out something that's somehow not true 20 years later. And I think that's the genius behind it was we stumbled on... And probably because most of us were object modelers, that's one of the things we're really good at, is distilling the essence of a system into the most critical pieces. That's kind of what modeling is all about. And so I think somehow innately, we got down to the core bits that make up what it is to produce software with people, process and tools. And we wrote it down. That's why I think it's timeless.

Amaar Iftikhar:

Yeah, no absolutely. I think that was a really good explanation about why it's timeless. I think one of the principles that comes to mind in a kind of modern hybrid or flexible working arrangement is one of the principles talks about the importance of face to face conversations. And in a world now where a lot of conversations aren't happening physically face to face, they might be happening on Zoom. Do you think that still applies?

Jon Kern:

Yeah, I think what we're finding out with... Remote was literally remote, so to speak, back 20 years ago. I was working with a team of developers in Russia and we had established enough trust and physical... I would travel there every month. So kind of established enough of a team, and enough trust in the communication that we could do ultimately some asynchronous work because different time zones. And me being in the east coast. 7:00 AM in the US was maybe 3:00 PM in Russia if I recall. St. Petersburg. So we were able to overcome the distance, but it's hard to beat real life. And I would often sometimes even spar a little bit with Ron Jeffries that on the one hand you could say the best that you can do is in person. But on the other hand, I could argue a little bit of some of the remoteness makes things... You have to be a little more verbose, possibly a little more precise, but also a little more verbose. A little more relaxed with... You might take a couple of passes to get something just because, I mean there are two time zones passing in the night. But that was based off of some often initial face to face meetings, and then you could go remote and still be successful and highly effective.

So I think it's important that teams don't just say that they can still do everything. And zoom is way better than 20 years ago, admittedly. Zoom gets, at least you can see a face. But nothing replaces the human contact. And I think also for wellbeing, I think human contact is important. So I would still say that the interaction aspect in the manifesto is still best served with a healthy dose of in-person. And that's kind of the key about most things in Agile. It's to me it's about pragmatism, and not just being dogmatic but rather, what might work better for us? And even experimenting with try something a little bit and see how that works. So even how you treat the manifesto, you should treat it in an Agile manner so to speak.

Amaar Iftikhar:

Yeah, no absolutely. That's a great point. On that note, as an Agile consultant or the Agile guy, what have you seen are the best practices or what works, what doesn't work for distributed teams?

Jon Kern:

Well I think the things that are most challenging that I've run across big companies and even smaller ones is that... I don't know if it's natural, God forbid if it's natural, but tendencies that I've seen in some companies to set up silos where you're the quality control, you're the UX, you're the front end, you're the back end, makes my headwater explode. Because that's building in a lag and building in communication roadblocks and building in cooperation which is handed offs from silo to silo, versus collaboration. So I've seen more of that. And I get it, you might want to have a specialty, but customer doesn't care. Customer wants something out the door. If I showed up and I'm going to pull a feature off the stack, what do you mean I can only do part of it? I don't get that. And yeah, I know I'm not an expert in everything but we probably have an expert that we can figure out what the pattern is. So I find that sort of trend, I don't know if it's a trend, but I find that's a step backwards in my opinion. And it's better to try to be more cross-functional, collaborative, everybody trying to work to get the feature out the door, not just trying to do your little part.

Amaar Iftikhar:

Yeah, a hundred percent. I think knocking on silos is a big part of being agile, or even being digital for that matter. And often the remedies for it too are there at hand, but it's a lot harder to actually be practical with it, to actually implement it in an organization, a living, breathing business where there's real people and there's dynamics to deal with, and there's policies and processes to follow. So I guess as generic as you can be, what is your thought as an Agile consultant to a business that's kind of facing that issue?

Jon Kern:

One of the things that... Adaptive is what my colleague John Turley has really opened my eyes to. I tend to call it the secret sauce, or the missing piece to my practice. And it has to do with individual's mindset and what we call vertical development. So it might sound like weird wishy-washy fluffy stuff, but it's actually super critical. And I've always said people, process, and tools for, I want to say since late nineties probably, I mean a long time. And the first I've been able to realize why sometimes I would have just spectacular super high performing teams and other times it'd be just really, really well performing but not always that spark and sometimes kind of like, eh, that was a little meh. And a lot of it comes down to where people lie on in terms of how they make their meaning and what their motivational orientation is, command and control versus autonomy.

So what we do is we've learned that we can help people first off recognize this exists, and help people with what we call developmental practices. Something that, even the phrase, you probably heard it, like safe experiments. Failure, or trying something and failing. Well if you chop someone's head off for it, guess what? They're just going to probably stay pretty still and only do what they're told, not try to... I have a super high dose of autonomy in me, so I've long lived by the, better to beg forgiveness than ask permission, and always felt as long as I'm trying to do the right thing to succeed and do the best for the company, they probably won't fire me if I make a mistake. But not everybody has that amount of freedom in the way they work. So you have to help establish that as management, and that's a big thing that we work with, with teams.

And then we also start with the class. If you've ever watched office space, and if you haven't you should, but the, what is it that you do here? So there's a great, the consultants Bob and Bob coming in, the efficiency consultants, "So Amaar, what is it that you do here?" But literally that's something, whether we're helping teams build a new product, is okay, what's the purpose? What's the business purpose of this product? What is it that you do here? What do you want to do with this product? What value does it provide? Same thing with anything you're working with as a team. And that's why whether it's software, producing some feature that has an outcome that provides value to the customer, or some product. But the point is if you don't understand that, now it's making, the team is going to have a real hard time being able to make decisions which are helping us move forward.

So if you help everybody understand what it is we're here to do, and then try to get the folks that might reflect all the different silos if you're siloed, but all the different elements. How do we go from an idea to cash, so to speak, or idea to value in the customer's hand? And have a good look at that. Because there are so many things that just sort of... Technical data often creeps into software code bases. And the same thing, we sort of say the organizational debt, the same thing can happen. Your process debt. You can just end up with, all right, we want the development team to go faster, John and company, can you come in and help coach us? We want to go agile. Sure, okay yeah. All right. We roll up our sleeves, we look around and after an initial kind of value stream look, like, wait I'm sorry but there's a little tiny wedge, it's about 15%, that's the development. And then you spent the 85% thinking about it.

Let's pretend we could double the speed of development. Which was initially the... Yeah, we need the developers to code faster or something. That's a classic. And no you don't, you need to stop doing all this bullshit up front that's just crazy ass big waterfall project-y stuff with multiple sign-offs. And matter of fact, one of the sign-offs, oh my gosh it only meets once a week, and then if you have a typo in it, you get rejected. You don't come back for another... Are you insane? You spent eight months deciding to do eight weeks worth of work. Sorry, it's not the eight weeks. So things like that, what I recommend anybody self inspect is try to... If you're worried about your team, how you can do better is just start trying to write down what does your process step look like and what is a typical time frame?

How much time are you putting value into the... Because a lot of times people batch things up in sprints. That's a batch, why are you putting things in a batch? Or they have giant issues. Well that's the big batch. So there's lots of often low hanging fruit. But to your point, it's often encrusted in, this is the way we work and nobody feels the ability to change or even to stop and look to see how are we working. So I think that's where we usually start is let's see how you actually work today. And then while we're doing that you can spill your guts, you can tell us all the things that hurt and that are painful and then we'll try to design a better way that we can move towards, in terms of working more effectively. Because our goal is to help teams be able to develop ways to do more meaningful and joyous work, really. Because it's a lot of fun when it's clicking and when you're on a good team and you're putting smiles on the customers' faces, it's hard to almost stay away from work because it's so much fun. But if it's not that, if it's drudgery and you're just a cog in the machine and stuff takes months to get out the door, it's a job. It's not that much fun.

Amaar Iftikhar:

Yeah. A lot of the points that you mentioned there strongly resonated with me, and the common pain points. It sounds like you've kind of seen it all. And by the way if you haven't seen office space, definitely need to watch it. It's a really good one. You've mentioned now a lot about of the element of the challenges that a distributed team faces. Now I want to flip it over and ask you what does the perfect distributed team look like today that lives and breathes agile values?

Jon Kern:

Yeah. I don't know if you can ever have such a thing, a perfect of any kind of team. So I would say harking back to the types of distributed teams that I've worked with, and this goes back to the late nineties. So I've been doing this for a long, long time. Only really done remote, whether it was with developers in Russia or down in North Carolina, or places like that. And I think that the secret was having a combination of in-person... If you want to go somewhere as a group, there are things you can do to break the ice, to establish some, what you might call team building type activities.

And not just, hey let's go do a high ropes course and be scared out of our wits together. But rather also things that are regarding why are we here, what are we trying to achieve? And let's talk about whether it's the product we're trying to build, and take that as an opportunity to coalesce around something and get enough meat on the bone, enough skeletons of what it might look like. Because there's good ways to start up and have a good foundation. And that's part of what I've been practicing for decades. If you get things set up properly with understanding that just enough requirements, understanding... And I do a lot of domain modeling with UML and things like that, just understanding what the problem domain is that we're trying to solve to achieve the goals we're looking for, have a sense of the architecture that we want. So all those things are collaborative efforts.

And so if you have enough of a starting point where you've worked together, you come in and, let's say you even had to go rent someplace, because nobody lived near office, so you all flew somewhere. I mean that's money well spent in my opinion. Because that starts the foundation. If you've broken bread so to speak, or drank some beers, or coded together and did stuff, and then you go back to your remote offices to take the next steps and then realize when you might need to meet again. So that's really important to understand that the value of establishing those relationships early on so that you can talk bluntly. And I have some good folks that I run a production app for firefighters since like 2006.

Amaar Iftikhar:

Yeah, very cool.

Jon Kern:

And that friend that I've worked with, we are so tight that we can... It makes our conversations, we don't have to beat around the bush, we don't have to worry about offending any, we just, boom, cut to the chase. Because we know we're not calling each other's kids ugly. We're just trying to get something done fast.

And building that kind of rapport takes time and effort and working together. And that's what I think a good successful distributed team, you need to come together every so often and build those relationships and know when you might need to come together again if something is a problem. But that I think is a key to success is it shortens the time. Because you may have heard of things like the group forms, if this is performance on the Y axis they form and they're at some performance level, then they need to storm before they get back to normal, and before they start high performing. So it's this form, storm. You get worse when you're storming. And storming means really understanding where we're at. When we argue about, I don't think that should be inheritance, Amaar. And then you're like, "Oh bull crap, it really..."

And again, we're not personal, but we're learning each other's sort of perspectives and we're learning how to have respectful debates and have some arguments, so to speak, to get to the better place. And I've worked in some companies that are afraid to storm, and it feels like you're never high performing.

Everyone's too polite. It's like, come on. And I love when I worked with my Russian colleagues. They didn't give a crap if I was one of the founders. And I'm glad, because I don't want any privilege, I don't want anything like that. No let's duke it out. May the best ideas win. That's where you want to get to. And if you can't get there because you don't have enough of a relationship, and you tend not to say the things that needed to be said because you're being polite, well it's going to take you really long to succeed. And that's a lot of money, and that's a lot of success, and people might leave.

So I think the important thing is if you're remote, that's okay, but sheer remote is a real challenge. And you have to somehow figure out, if you can't get together to learn how to form and storm, and build those bonds face to face, then you need to figure out how to do it over Zoom. Because you need to do it, because if you don't, if you never have words, then trust me, you're still not high performing.

Amaar Iftikhar:

Yeah, I kind of feel like being fully remote now is being offered as almost a competitive advantage to candidates in the marketplace now, because it's a fight for talent. But if I'm understanding correctly, what you are saying is that in-person element is so important to truly be high performing and those ideas kind of contradict each other, I feel.

Jon Kern:

Yeah. And again, having been remote since the late nineties, I've been doing this a long time. And commuting to Russia is the longest commute I ever did, for three years. I mean that's a hell of a long flight to commute there over seven times, or whatever the hell it was. Anyway, I used to say that that being remote is not for everyone, because it really isn't. I mean you have to know how to work without anybody around, and work. I mean it has its own challenges. And yeah, it might be a perk, but I think what you need to do is look at potentially what the perks are and figure out too, can I fold them into... It doesn't have to be all or nothing. And I think that can be a easy mistake to make maybe is to, all right cool, we don't have to have office space. That's a lot of savings for the company. Yeah, but maybe that means you need to have some remote workspaces for occasional gatherings, or figure it out.

But yeah, I think even... And certain businesses might work differently. In the beginning of building a product, I want to have heavy collaboration and I want to get to a point where it's almost, I feel like the product goes like this where once you get things rolling and you kind of get up, get some momentum going, now the hardest thing to do is be in front of an agile team, whether they're in-person or remote. Once things are rolling and rocking and kicking and it's like everything's clicking, you can just bang out features left, like boom, boom, boom. Yeah, okay then we probably need to be...

Unless we've got ways that we're pairing or things like that. I will say when we're together, mobbing is easier. I'm sure there's ways to do it remote, but being in a room, I don't know, it's a lot easier than coordinating over Zoom. You just, hey there's this problem, let's all hang out here after standup because we're just going to mob on this. So it doesn't take a whole lot versus anything remote, there's a little extra, okay, we've got to coordinate, and even different times zones, gets even worse. So yeah, don't get carried away with remote being the end all be all. Because I have a feeling there's going to be a... I would wager there will be a backlash.

Amaar Iftikhar:

And I'll take that back coming from the Agile, the person who does this day to day who helps teams become agile, I'll definitely kind of take your word for it. Plus with my experience too, I've seen nothing really beats a good white-boarding session. That is really hard to replicate online. I mean we have these amazing tools, but nothing quite mimics the real life experience of just having a plain whiteboard and a marker in your hand. That communication is so powerful.

Jon Kern:

Great point. You're so, right, because I had just with the one company that I was with for five years, we were doing high level engineered to order pump manufacturing sales type tool for... So it was my favorite world because it blended my fluid dynamics as an aerospace engineer, plus my love for building SaaS products, and building new software and things like that. And even having a young, we would interview at Lehigh University and we'd have some young graduates that would be working with us, and being able to bring them into the fold, and there was a room behind where my treadmill was and we'd go in there, we'd have jam sessions on modeling and building out new features. And man, you're right. Just that visceral three dimensional experience. Yeah, Miro's great. Or any other kind of tool, but yeah, it's not the same. You're absolutely right. That's a great point. You're almost making me pine for the good old days. [inaudible 00:42:04]

Amaar Iftikhar:

I think the good old days very much still exist. I think even now, it's kind of been a refreshing time for me to be with Easy Agile. I've only been here for just under two months now. And there's a strong in-person dynamic. And again, it's optional, where if people are remote or they're hybrid or they need to commute once in a while, it's a very understanding environment. But once you're in the office or you're in person, you kind of feel the effect you were describing, you're motivated to deliver for the end customer. You just want to come back. It's an addictive feeling of, I want to be back in person and I want to collaborate in real time in person.

Jon Kern:

That's beautifully said, because that's... One of the companies that we're beginning to engage with in South Africa, they're at this very crossroad of struggling with, everybody's been remote, but boy, the couple times we were together, got so much done. And you're describing the flame of, the warmth of delivering and let the moths come to the flame. I mean nurture it and then fan the flames of the good and let people opt in and enjoy it. And still sometimes, yeah, I got to say home, I got the kids or the dog, that's okay too. But giving the option I think is where we're going to head. And I believe the companies that are able to build that hybrid culture of accepting both, and neither mandating one nor the other, but building such a high performing team that basically encourages people to opt into the things that make the most sense at that time. And I think that those companies will rule the day, so to speak.

Amaar Iftikhar:

Yeah, absolutely. It's been so nice to chat with you John, and I've really enjoyed this. I want to leave the audience off with one piece of advice for distributed agile teams from you. We've talked a lot about the importance of in-person collaboration. We've talked about the principles of the agile manifesto. Now, what would the one piece of advice be when you're thinking of both? When you want the agile manifestos to be something that's living and breathing in distributed agile teams, what one piece of advice can you give businesses today right now who are going through the common struggles? What can you tell them as that last piece of advice?

Jon Kern:

Well, I think kind of a one phrase that I like to use to capture the manifesto is, "Mind the gap." In my sort of play on words, what I mean is the gap in time between taking an action and getting a response. Whether it's what do we do about the office, what do we do about remote, what do we do about this feature, what do we do about this line of code? The gap in time is, it's sort of a metaphor about being humble enough to treat things as a hypothesis. So don't be so damn sure of yourself one way or the other about the office or remote or distributed. But instead, treat things as a hypothesis. Be curious and experiment safely with different ways and see what works. And don't be afraid of change. It's not a life sentence to, you got to run your business or your project or your team one way for the rest of your life. No. Don't tell the boss, but work is subsidized learning. I never understood people who just keep doing the same thing because they weren't given permission. Just try it. So that's what my departing phrase would be regarding making those decisions. Mind the gap and really be humble about making assumptions, and test your hypotheses, and shorten the gap in time between taking actions and seeing a reaction.

Amaar Iftikhar:

Oh, that's awesome. Thank you. I really wish we could let the tape roll and just keep talking about this for a couple more hours, but we'll end it right there on that really good piece of advice that you've left the audience off with. Jon, thank you again for being on the podcast. And we've really, really enjoyed hearing you and learning from your experiences.

Jon Kern:

Oh, my pleasure. Any time. Happy to talk another couple hours, but maybe after some beers.

Amaar Iftikhar:

Yeah.

Jon Kern:

Except it's your morning, my evening. I'm going to have to work on that.

Amaar Iftikhar:

Yeah.

Jon Kern:

My pleasure, Amaar.