Easy Agile Podcast Ep.1 Dominic Price, Work Futurist at Atlassian

"The episode highlights that Interaction, collaboration, and helping every team member reach their potential is what makes agile work" - Terlya Hunt

In this episode join Terlya Hunt - Head of People & Culture at Easy Agile and Caitlin Mackie - Marketing Coordinator at Easy Agile, as they chat with Jazmin Chamizo and Rakesh Singh.

Jazmin and Rakesh are principal contributors of the recently published report "Reimagining Agility with Diversity, Equity and Inclusion".

The report explores the intersection between agile, business agility, and diversity, equity, and inclusion (DE&I), as well as the state of inclusivity and equity inside agile organizations.

“People are the beating heart of agile. If people are not empowered by inclusive and equitable environments, agile doesn't work. If agile doesn't work, agile organisations can't work."

📌 What led to writing the report
📌 Where the misalignments lie
📌 What we can be doing differently as individuals and business leaders

Be sure to subscribe, enjoy the episode 🎧

‍

Transcript

Terlya Hunt:

Hi, everyone. Thanks for joining us for another episode of the Easy Agile podcast. I'm Terlya, People & Culture business partner in Easy Agile.

Caitlin Mackie:

And I'm Caitlin, marketing coordinator at Easy Agile. And we'll be your hosts for this episode.

Terlya Hunt:

Before we begin, Easy Agile would like to acknowledge the traditional custodians of the land from which we broadcast today, the Wodiwodi people of the Dharawal nation, and pay our respects to the elders past, present and emerging, and extend the same respect to any Aboriginal people listening with us today.

Caitlin Mackie:

Today, we'll be joined by Jazmin Chamizo and Rakesh Singh. Both Jazmin and Rakesh are principal contributors and researchers of Reimagining Agile for Diversity, Equity and Inclusion, a report that explores the intersection between Agile business agility and diversity equity and inclusion published in May, 2021.

Terlya Hunt:

We're really excited to have Jazmin and Rakesh join us today. So let's jump in.

Caitlin Mackie:

So Jazmin and Rakesh, thank you so much for joining us today. We're so excited to be here with you both today, having the conversation. So I suppose today we'll be unpacking and asking you questions in relation to the report, which you were both principal contributors of, Reimagining Agility with Diversity, Equity and Inclusion. So for our audience tuning in today who may be unfamiliar the report, Jazmin, could you please give us a summary of what it's all about?

Jazmin Chamizo:

Absolutely. And first of all, thank you so much for having us here today and for your interest in our report. Just to give you a little bit of background of our research and how everything started out, the founder and the owner of the Business Agility Institute, Evan Leybourn, he actually attended a talk given by Mark Green. And Mark who used to be, I mean, an Agile coach, he was referring to his not very positive experience with Agile. So this actually grabbed the attention of Evan, who was a big advocate of agility, as all of us are. And they decided to embark upon this adventure and do some research trying to probe on and investigate the potential relationship between diversity, equity and inclusion and Agile.

So we had, I mean, a couple of hypothesis at the beginning of the research. And the first of hypothesis was that despite the positive intent of agility and despite the positive mindset and the values of Agile, which we all share, Agile organizations may be at the risk of further excluding marginalized staff and customers. And the second hypothesis that we had was that organizations who actually embed diversity, equity and inclusion directly into their Agile transformation and then strategy may outperform those organizations who don't. So we actually spent more than a year interviewing different participants from many different countries. And we actually ended up seeing that those hypothesis are true. And today, we would like to share with you, I mean, part of this research and also need to encourage you to read the whole report and also contribute to this discussion.

Terlya Hunt:

Amazing. And Jazmin, you touched on this a little bit in your answer just then, but I guess, Rakesh, could you tell us a bit more about what was the inspiration and catalyst for writing this report?

Rakesh Singh:

Yeah. So thanks for inviting once again. And it's a great [inaudible 00:03:51] talk about this beautiful project. The BAI was actually into this activity for a long time, and I happened to hear one of the presentation from Evan and this presentation actually got me interested into business agility and associated with DEI. So that was one thing. And second thing when Evan talked about this particular project, invited all of us, I had been with transformation in my job with Siemens for about three decades for a very long time. And we found that there were always some people, whenever you do transformation, they were not interested or they were skeptical. "We are wasting our time." And okay, that was to be expected, but what was surprising that even though Agile came up in a big way and people thought, "Okay. This is a solution to all our miseries," even though there was a focus on culture, culture was still our biggest issue. So it appeared to me that we are not really addressing the problem.

And as Jazmin talk about our goal and our hypothesis, and that was attractive to me that maybe this project will help me to understand why some [inaudible 00:05:12] to get the people on board in some of the Agile transformation.

Terlya Hunt:

Thank you. That was awesome. I think it definitely comes through in the report that this is a topic that's near and dear to all of you. And in the report you mentioned, there's a lack of consensus and some misalignment in defining some of these key terms. So thought to frame the conversation today, Jazmin, could you walk us through some of these key definitions, agility, diversity, equity, and inclusion.

Jazmin Chamizo:

That's a great question now, because over the last year, there's been a big boom on different topics related to diversity, equity and inclusion, I mean, especially with the Black Lives Matter movement and many different events that have affected our society in general. And with the rise of social movements, I mean, there's been a lot of talk in the area of diverse, equity and inclusion. And when we talk about agility, equality, equity and inclusion and diversity, I mean, it's very important to have a very clear understanding of what we mean with this terms. Agility is the mindset. I mean, it's really about having the customer, people, at the very center of the organization. So we're talking about agile ways of working. We're talking about more collaborative ways of working. So we can bring the best out of people and then innovate and put products into the market as fast as possible.

Now, when we were thinking about agility and this whole idea of putting people at the very core and customer at the very core of organization so we can respond in a very agile and nimble way to the challenges that our society presents at the moment, we found a lot of commonalities and a lot of similarities with diversity, equity and inclusion. However, when we talk about diversity, equity and inclusion, there's some nuances in the concepts that we need to understand. Diversity really refers to the mix. It refers to numbers, to statistics, all the differences that we have. There's a very long list of types of diversity. Diversity of gender, sexual orientation, ways of our thinking, our socioeconomic status, education and you name it, several types of diversity.

Now, when we talk about equality, I mean, we're talking about applying the same resources and support structures, I mean, for all. However, equality does not actually imply the element of equity, which is so important when we talk about now creating inclusive environments. With equity, we're talking about the element of fair treatment, we're talking about social justice, we're talking about giving equal access to opportunities for all. So it's pretty much about leveling the filed, so all those voices can be part of the conversation and everybody can contribute to the decision making in organizations and in society. So it's that element of fair treatment, it's that element of social justice that the element of equity has to contribute and that we really need to pay attention to.

And inclusion is really about that act of welcoming people in the organization. It's about creating all the conditions so people, everybody, can thrive and everybody can succeed in an organization. So I think it's very important, I mean, to have those definitions very clear to get a better understanding of how they overlap and how there's actually, I mean, a symbiotic relationship between these concepts.

Caitlin Mackie:

Yeah. Great. And I think just building on that, interaction, collaboration and helping every team member reach their potential is what makes Agile work. So your report discusses that there are lots of overlaps in those values with diversity, equity and inclusion. So I think, Rakesh, what are those key overlaps? It seems those qualities and traits go hand in hand. So how do we embrace them?

Rakesh Singh:

So if you see most of the organization which are big organization and being for about two decades or so, and you compare them with the startup organization, so in the traditional setup, normally people are working in their functional silos, so to say. And so the Agile transformation is taken care by one business function. It could be a quality team. It could be a transmission team. And DEI normally is a domain of an HR or people who enter the organization. And the issue is that sometime these initiatives, they are handled separately and the amount of collaboration that's required does not happen, whereas in a startup company, they don't have these kind of divisions.

So looking that as a basis, what we need to look at is that the organization should be sensitize that they work together on some of these projects and look at the underlying what is the commonality, and we can possibly either help each other or complement each other, because one example is, if I can give, it's very easy to justify an Agile transformation relating to a business outcome, okay, but any people related change is a very long-term change. So you cannot relate that to a business outcome in a shorter timeframe. So I call Agile and DEI as symbiotic. An Agile can be helped by a DEI process and DEI itself can be justified by having an Agile project. So they are symbiotic.

Now, what is the common thing between the two? So there are four items. I mean, there are many things which are common, but four things which I find are most important. Yeah? The first thing is respect for people, like Jazmin talked about being inclusive. So respect for people, both Agile and DEI, that's a basis for that. And make people feel welcomed. So no matter what diversity they come from, what background they come from, they're feeling welcome. Yeah? The second part is the work environment. So it's a big challenge to create some kind of a psychological safety. And I think people are now organizing, the management is now understanding that they think that they have provided a safe place, but people are still not feeling safe for whatever reason there. That's one thing.

The other thing is that whatever policies you write, documentation, policies or announcement, the basic things that people see, is it fair and is it transparent? Yeah? So I used to always see that if there are two people given bonus, if one person get 5% more, no matter how big is the amount, there's always felt that, "I have not got my due." Yeah? So be fair and be transparent. And the last one is that you have to invest in people. The organization need to invest in people. The organization need to invest in enabling them with opportunity to make use of new opportunity, and also grow and through learning. So these are four things that I can see, which actually can help both being an agile, and also having inclusive environment in the company.

Caitlin Mackie:

The report mentions that some of those opportunities to combine agile and diversity equity inclusion are being overlooked. Why do you think this is?

Rakesh Singh:

So I think that the reason why they're being overlooked is that, it's basically, educating the leaders. So it's just, if I'm in the agile world, I do not really realize that there are certain people related aspect. I think, if I just make an announcement, people will participate. Okay? So that's the understanding. On the other side, we got an input from quite a few responders saying that some of the DEI projects are basically words, are not really sincere about it. It's a waste of time. "I'm being forced to do certain training. I'm forced." So the sincerity part, sometime there's a lacking, so people have to be educated more at a leadership level and on at a employee level.

Caitlin Mackie:

I think a really interesting call out in your research is that many agile processes and rituals are built to suit the majority, which excludes team members with diverse attributes. Jazmin, what are some of those rituals?

Jazmin Chamizo:

Yeah, that's a great question. Now, if you think about agile and agile rituals and for example, I mean, daily standups, a lot of those rituals have not actually thought about diversity, or the design for diversity and inclusion. I mean, agile is a very on the spot and is a very, who can talk, type of rituals. But there's a lot of people, I mean, who might need more time to process information before they can provide inputs, so fast. So that requirement of processing information or giving input in a very fast manner, in daily standups, that might be overlooking the fact that a lot of people, with a different type of thought processing styles or preferences may need more time to carry out those processes.

So that would be, I mean, number one; the fact that it's very on the spot and sometimes only the loud voices can be heard. So we might be losing a lot of opportunities, trying to get feedback and input from people with different thinking styles.

Now, also, if you think about organizations in different countries, where English is not the native language of a lot of people, they may also feel a lot of disadvantage. This happens a lot in multinational organizations, where people whose, you know, first language is English, they feel more confident and they're the ones who practically may monopolize now the conversations. So, for people who's first language is not English, I mean, they might feel at a disadvantage.

If you think about older employees who sometimes may not be part of an agile transformation, they might also feel that are not being part of the team and they may not have the sense of belonging, which is so important in an agile transformation and for any organization. Another example, I mean, would be people, who because of their religious belief, I mean, they need maybe to pray five times in a day, and I mean maybe a morning stand up might mean very difficult to adapt to, or even people with disabilities or language differences, they feel a little intimidated by agile. So there's a lot of different examples. And Doug report actually collects several lived experiences, by the respondents that we interview that illustrate how agile has been designed for the majority and for a more dominant type of culture and that highlights the need to redesign many of these rituals and many of these practices.

Caitlin Mackie:

Yeah, I think just building on that in your recommendations, you mentioned consciously recreating and redesigning these agile ways of working. What are some of the ways we can rethink and consciously create these?

Jazmin Chamizo:

Mm-hmm (affirmative). Well, the good news is that, during our research, and during our field work and the conversations that we had with some organizations mean there's a lot of companies and organizations that have actively implementing them different types of practices, starting from the way they're managing their meetings, their rituals, their stand ups, giving people an opportunity to communicate in different ways. Maybe giving some room for silence, so people can process their information or providing alternative channels for people to communicate and comment either in writing or maybe the next day. So it doesn't have to be right there on the spot., and they don't feel under that type of pressure.

Now, another example would be allowing people, I mean, to also communicate in their native language. I mean, not necessarily using English, I mean, all the time as, I mean, the main language. I think it's also important for people to feel that it can contribute with their own language, and also starting to analyze, I mean, the employee experience. We're talking about maybe using non-binary options in recruitment processes or in payroll. So, I mean, starting to be more inclusive in the different practices and analyzing, I mean, the whole employee journey. I mean, those are some examples that we can start implementing to creating a more inclusive environments. And the one that is the most important for me is encouraging leadership to intentionally design inclusive work environments through the use of, like creating environments that are really where people feel safe, where they have this. Psychologically safe.

Terlya Hunt:

The whole section on exploring and challenging existing beliefs is so interesting. And I would definitely encourage everyone listening to go and read it. I could ask you so many questions on this section alone, because I think it was full of gold, and honestly, my copy is highlighted and scribbled and I read it and reread it, there was so much to absorb. The first thing that really stood out to me as a HR practitioner in an agile organization was this belief that focusing on one or two areas of diversity first is a good start. And from your research, what you actually found was that survey respondents found this method ineffective and actually harmful for DEI. And in your research, you also reference how important it is to be intentional and deliberate. So I guess, how do we balance this need for focus and creating change with these findings that being too narrow in our focus can actually be harmful? Might throw this one to you, Rakesh.

Rakesh Singh:

So actually, thanks to the reform data report, very interesting, in fact, we presented to quite a few groups. And one of the thing that I observed when we are talking about some of the beliefs and challenges, there were immediate to response say, "Hey, we do experience in our area." So, what we realized is that this whole aspect, as Jazmin talked about, many dimensions. So if you look at inclusiveness, and diversity and equity across organization, there are many streams, and many triggers. As diversity, we understand, okay, in very limited way, it may be gender, or it may be religion or country, but actually, it's much more in a working environment, there are many dynamics which are [inaudible 00:22:15]. So the challenges, what we saw was that if you pick up a project in a very sincere way and say, "I'll solve one problem, okay?" Let me say I solve problem of a region or language, yeah? Now the issue is that most of the time, we look at the most dominant and identify that problem.

So what happens is that you actually create an inequity right there, because there are other people they are suffering. They are, I won't say, "Suffering," but they're influenced by other factors of diversity and they felt, "Okay, nobody's really caring for me." Yeah? So you have to look at in a very holistic picture, and you have to look at in a way that everybody is on board, yeah? So you may not be able to find solution to every specific problem, but getting everybody on board, and let people work in some of the environment or either psychological safety or the policy level, so create an environment where everybody can participate, and issues can be different so they can bring up their own issues, and make sure they feel that they they're cared for. And that's what we actually observed.

Terlya Hunt:

And the second belief I thought was really interesting to call out was that this belief that we will adapt to somebody's beliefs if they ask. And your research found that not everyone is able to disclose their needs, no matter how safe the working environment, so that by relying on disclosure is the first step in the process,. Organizations will always be a step behind and, and also place the burden of change on marginalized groups. What are some things we can do, Rakesh, to remove this pressure and to be more proactive?

Rakesh Singh:

So there are a couple of things that we need to look at when we talk to people, actually, they discussed about the problem, and they also recommended what could be right, we are doing it. And we also discussed among ourselves. So one thing which was very clear that there was a little doubt about the sincerity of leadership. And so, we felt that any organization where leader was very proactive, like, for example, what is the basic reason, if I have a problem, if I talk about it, I am always worried what will happen when I disclose it? And is it the right issue to talk about it? So, these are the questions would inhibit a lot of people not to talk about it at all. So, that's where the proactive leadership can help people to overcome their inhibition and talk about it, and unless they discuss about it, you'll never know if there's a problem. So, that's the one thing. So, that's the approach.

So there are a couple things that we could also recommend, is proactive leadership to start with, and something which can be done is there are a lot of tools available for the managers, yeah? People leaders, I would call it. Things like coaching, so you have a grow model where you can coach an individual person, even as a manager or as an independent coach, then having a facilitation techniques. When I started my career, they were not a training on facilitation, just going to the room and conduct the meeting. But they're very nice tools, facilitation techniques, which can be brought out to get people to participate, and so things like that can be very useful for being proactive and drawing people out of their inhibition. That definitely is with the leader. That's why we call it servant leadership. It is their job to initiate and take the lead, and get people out of their shell.

Terlya Hunt:

It ties quite nicely into the next question I had in mind. You both actually today have mentioned a lot of challenging beliefs, and calling things out. We need to build this awareness, and create safe spaces, and create psychological safety in our teams. What are some examples of how we can create safe spaces for these conversations?

Rakesh Singh:

The examples of someone creating safe places is ... I would say that educating people and the leaders. What I have seen is that if the leadership team recognizes that and educates the managers and other people ... You need to actually train people at different level, and create an environment that everybody's participating in the decision making, and they're free to make choices within, of course, the constraint of the business.

The focus, where I would put it, is that there are many educational programs and people would like to educated, because I normally felt that I was never trained for being a good leader. There was never training available. But these days we find that a lot of educational programs highlighting a various issue, like microaggression, unconscious bias, psychological safety. People should understand it. Things like being empathetic. These terminologies are there, but I find that people don't really appreciate it and understand it to the extent that they need to do, even though they are in a leadership position.

Caitlin Mackie:

Thanks for sharing, Rakesh. I really love what you mentioned around proactive leadership, there. Your research found that 47% of respondents believed organizations who achieved this unity of Agile, and diversity, and equity, and inclusion will reap the benefits and exceed competitors. Jazmin, what did these organizations do differently?

Jazmin Chamizo:

Yes. That's a great question. Actually this ties very nicely with idea of servant leadership, inclusive leadership, and how leaders have this incredible challenge of creating workspaces that are psychologically safe, as Rakesh just mentioned. This is really everybody's responsibility, but it has a lot to do with a very strong leadership.

We found that several other organizations that we interviewed, they had a very strong leadership team, that they were really committed with diversity, equity, and inclusion in their agile transformation, and they were able to put DEI at the very core of the organization. That's number one, having a very strong leadership team that's actually committed to diversity, equity, and inclusion, and that does not perceive DEI efforts as isolated actions or initiatives.

This is something that we're seeing a lot nowadays. As a DEI coach and consultant, sometimes you see, unfortunately, several organizations that only try very isolated and very ... They don't have long-term strategy. What we have seen that actually works is having this committed leadership team that has been able to put DEI at the very core of their strategy.

Also a team that has been able to serve as an advocate in diversity, equity, and inclusion, and agility, and they're able to have advocates throughout the organization. It's not just one person's job. This calls for the effort of the whole organization and individuals to commit to DEI and be actively part of the agile transformation.

Also, I would say, leaders that embrace mistakes and embrace errors throughout the process. This is something that came up a lot during our conversations with people in different organizations, that in many cultures and in many organizations, mistakes are punished. They're not perceived as a source of opportunity.

One of the tips or best practices would be having leaders who are able to show the rest of their organization that mistakes are actually learning opportunities, that you can try things out of the box, and you can be more innovative. That even if you fail, you're not going to be punished, or there won't be any consequences because of that, and, quite on the country, that this is actually a learning opportunity that we can all thrive on.

Caitlin Mackie:

Yeah. I completely agree. What benefits did they see?

Jazmin Chamizo:

They definitely saw a greater working environment. This is something that was quoted a lot during our interviews with respondents, that individuals saw that they had the chance to try new and innovative ideas. Definitely greater innovation, more creativity. Business morale actually ultimately went up, because they saw that the organization was actually embracing different perspectives, even if they fail. This definitely called for greater innovation.

I would say innovation, more creativity, and a better working environment. Absolutely new products, new ideas. That if you think about the current circumstances with COVID, this is what organizations have to aim at. New products, more innovation to face all the challenges that we have nowadays.

Terlya Hunt:

Powerful things for the listeners to think about. Here at Easy Agile, our mission is to help teams be agile. Because we believe for too long the focus has been on doing, when the reality is that Agile is a constant journey of becoming.

There's a specific part in the report that really stood out to me that I'd like to read. "Agility is a journey with no fixed endpoint. The road towards creating diverse, equitable, and inclusive environments is the same. Agility and DEI can be pursued, but never fully achieved. They are a process of ongoing learning, reflection, and improvement. A team cannot enter the process of improving business agility or DEI with a mindset towards completion, and any model that unites Agile and DEI will ultimately be ineffective if those taking part are not ready to embark on an ongoing quest for self improvement."

I absolutely love this quote. Rakesh, let's explore this a little bit further. What more can you tell me about this?

Rakesh Singh:

Actually there's an interesting thing that I would like to share to start with. We wanted to look for a organization who would help us interview their people and talk to their people. The way organizations responded ... Some responded, "Shall I allow my people to talk to somebody? It could be a problem." But then we got other organizations, they were actually chasing us. "We would like to be part of this, and we would like to get our people interviewed." They were very positive about the whole thing.

I happened to talk to the DEI corporate manager, a lady, and the way she was talking was ... She was so much, I would say, passionate about the whole thing, even though at least I felt that they were very high level of awareness of DEI. But the quest for learning and finding out what they could do better was quite astonishing and quite positive.

That's where my answer is, is that ... If you look at the current pandemic, and people realized that, "Okay. We have to work from home," initially some people found it great. It's a great thing. Work-life balance. "I can attend my home." But after some time they found it's a problem. There's other problem.

The point is that, in any organization, where it's a business or a social life, or people, it just keeps changing. There's no method or policy which is going to be forever valid. There's a continuous learning process that we have to get in.

What we need to do is focus on our goal that we want to achieve. Depending on the environment, that's what we call business agility. Now bring it to people as well, because it is a people ... We talk about customer centricity, and all that. But finding it's the people who are going to deliver whatever organization want to. You have to see how their lives are getting impacted.

We are discussing about getting people back to office. The problem is that, a city like Bangalore, it's a very costly city and very clouded city. People have gone to their hometown and they can work from there. Now, to bring them back, you have to approve them back again. To cut short the explanation, our life is changing, constantly changing, and technology and everything is putting ... People have to look at methods and approach of how they can be adapting themself on a continuous basis.

Learning is a continuous process. In fact, when I got into Agile and people ask me, "How many years of experience you have?" I generally say five years, because anything that I did before five years is actually the wrong practice. You have to be continuously learning, and DEI and Agile is no stranger to this situation.

Caitlin Mackie:

I love that. I think fostering that continuous learning environment is really key. I suppose, on that, a few of the recommendations from the report are centered around getting deeper training and intentional expertise. Jazmin, what further recommendations, or courses, or practitioners are there that people can engage with after this episode?

Jazmin Chamizo:

Sure. An important part of our report was a series of recommendations to the entire agile community, and practitioners, to organizations, and agile coaches. You can see that. You could get more specific information in our reports. I would like to encourage all of you to read. Definitely when it comes to agile coaches and consultants, we're encouraging people to learn more about diversity, equity, and inclusion because one of the insights and the learnings we drew from this research is that diversity, equity, and inclusion is not specifically included in the agile world.

When we talked to the respondents in many different countries, they did not spontaneously made the connection between agility, Agile, and diversity, equity, and inclusion. But the more we talk about it, they discovered that, indeed, they were very closely overlapped. There was a symbiotic relationship between them, because you're putting the person and everything that relates to that individual on the very core of the organization, on the transformation.

Definitely we do encourage ... Leaders and agile coaches need to start learning more about our DEI, building that proficiency, learning more about unconscious bias and the impact of unconscious bias, and discrimination, and racism that we'll continue to see in organizations. They're more mindful of those voices that are not being heard at the moment in the present conversations. They can learn different techniques or different methods to be more engaging and more inclusive.

When it comes to the agile community in general and influencers, it is important to mention that Evan Leybourn, the founder of the Agility Institute, is having at the moment some conversations with important institutions in the agile community, such as the Agile Alliance, because we are looking for ... That's what Gen Z-ers are looking for. There's a big call out there for organizations to embrace this type of transformation, but putting DEI at the very core of the organization. That's what I would like to say.

Contribute to the discussion. This is a pilot project. That we are hoping to conduct more research on other DEI areas related to agility. We would like listeners to be part of the conversation, and to contribute with their experience, to improve the state of agility in the current moment.

Caitlin Mackie:

Thank you both so much for joining us today. Thoroughly enjoyed our conversation. I can't wait to see how Agile and diversity, and equity, and inclusion evolves in the future. Thank you.

Jazmin Chamizo:

Thank you so much for having us. It's been a pleasure.

Rakesh Singh:

Thanks a lot to both of you. It was nice to share our experience. Thank you very much.

"I had an inspiring conversation with Renae around the benefits of leaping out of your comfort zone and aligning team behaviour " - Chloe Hall

Chloe Hall- Marketing Coordinator at Easy Agile is joined by Renae Craven - Agile Coach, Agile Trainer, Scrum Master Coach and QLD Chapter Local Leader at Women in Agile.

Join Renae Craven and Chloe Hall as they discuss:

• Renae’s journey to becoming an Agile Coach and Agile Trainer
• Taking a leap out of your comfort zone
• The importance of taking time to gather feedback and reflect
• Building a team environment where everyone feels safe to contribute
• Aligning team behaviour and how prioritising learning impacts team delivery
• Why sitting all day is bad for you and how to bring movement into your work routine
• + more

Transcript

Chloe Hall:

Hello and welcome back to the Easy Agile Podcast. I'm Chloe, Marketing coordinator at Easy Agile, and I'll be your host for today's episode. Before we begin, we'd like to acknowledge the traditional custodians of the land from which we broadcast today, the people of the Dhuwal speaking country. We pay our respects to elders past, present, and emerging, and extend that same respect to all Aboriginal Torres Strait Islanders and First Nations people joining us today. Today we have a very exciting episode for you. We will be speaking to Renae Craven. Renae is an Agile coach, Agile trainer, scrum master coach, BASI Pilates instructor, and runs her own Pilate Studio.

Renee is also a chapter local leader at Women in Agile Brisbane and is the host of the podcast The Leader's Playlist alongside David Clifford. Renae's passion in life is to help people to be a better version of themselves by raising your awareness of areas they wish or need to improve them and to support them in their learning and growth through these areas. According to Renae, coaching is not about telling people what to do. It is about questions to allow them to dig deeper, uncovering realizations and their desire for change. Welcome to the podcast, Renae. Thank you so much for coming today. Really appreciate it and very excited to unpack your story, your journey, and all the success you have achieved, which is amazing. How are you today anyways?

Renae Craven:

I'm all, I'm good. Thank you, Chloe. It's Friday, so I'm always a bit wrecked on a Friday. Looking forward to sleeping in on the weekends and things like that. So yeah, Friday I'm already, always a little bit dreary, but other than that I'm fine.

Chloe Hall:

Well, that's good. Friday afternoon definitely can always do that to you. I'm very pumped for a sleep in as well. I think let's just get straight into it. So some of that I wanted to start was I just want to unpack you as a person, Renae, and kind of your story, who is Renae and the journey you've taken to become so successful today. So if you wanted to provide a little bit of background about yourself.

Renae Craven:

How far back do I go? So I did IT at uni, Information Technology at uni. So I started my career out as a graduate developer, software developer, pretty crap one at that.

Chloe Hall:

Surely not, I don't agree with that. I can't see it.

Renae Craven:

I knew enough to get by, but it was definitely not going to be something that I was going to do for the rest of my life. But back then I was 20 and kind of just was doing things that you were supposed to do when you grow up. You're supposed to go to school and you're supposed to do well in grade 12 and go to uni and get a degree and then get a job.

Chloe Hall:

Definitely.

Renae Craven:

So yeah, I ticked all those boxes and found myself with a degree in a job in a good organization. And I was in that development job for a couple of years and then I kind of moved more into team leadership and I was a team leader for a while and then I became a scrum master back in 2010. So that was when I discovered Agile.

Chloe Hall:

Okay. Yup.

Renae Craven:

And I think the rest is kind of history. So when I discovered Agile, things started to make more sense to me. Talking to people, having teams, working together, collaborating together, solving problems together, getting multiple brains onto a problem. That kind of thing was one thing that I never made sense to me when I was a grad straight out of uni. And I'm like, "What do you mean?" Because even during my university, I was a little bit different and I was remote. I did university remotely years ago and with a group of four others, there were four others, it was a group of five. We did everything together, we did all our group assignments, we studied together, we ate lunch together, we just kind of did.

Chloe Hall:

So with the exact same group?

Renae Craven:

Yeah. All the way through uni. I went from that kind of group setting to working and more of an individual on my own like if I've sat in a cubicle with walls that were higher than me, I didn't have to speak to anyone else if I didn't want to. And that never really sat well with me. It was never kind of who I was. So when Agile was, Scrum specifically was here's all these people we're going to throw together in a team and here's all of the problems and you work out together how you're going to solve it.

Someone's not going to tell you what to do or how to solve it, you've got to figure it out as a team, it was a much more, cool this is what makes sense, this works better. Why wasn't it always like this? So yeah, that's kind of where my Agile journey started and it kind of progressed as I did scrum mastering for quite a few years in different organizations, different scenarios, different contexts. And then I guess I was able to comfortably call myself an Agile coach I would say maybe 5, 6 years ago. I mean, there's nothing really that you can do that you go tick, Oh, I'm an Agile coach now.

Chloe Hall:

There's no kind of straightforward degree or certification.

Renae Craven:

No, it's really just experience. And I had experience around and people were telling me, "You can call yourself a coach, an Agile coach now, you've got plenty of experience". I'm like, "Yeah, but I feel like there's so much more that I need to know or that I could learn". So I don't really feel comfortable. But I was working for a consultancy, so that was just how I was being marketed anyway. So that was kind of 5, 6, 7 years ago that that started to happen. And then I do other things as well, like Agile training. I love training people, I run training courses, do the coaching as well. And then I've got my Pilates as well.

Chloe Hall:

Just an all rounder, a lot going on, that's for sure. I think as well, I just want to unpack, you had that transition when you were a graduate developer and you found it quite isolating. And then you came into this concept of Agile when you are working in teams. Was it when you started doing that Agile, did that kind of spike like a passion, a purpose of yours and that's what led you down that Agile training, Agile coaching road?

Renae Craven:

I think, I mean purpose, I still don't know if I know what my purpose is in life. Passion. I think what it helped me understand about myself is where some of my strengths were. And my strengths aligned with what was needed to be a scrum master and a coach later on. So the ability to facilitate, that's a big part of being a scrum master, a big part of being one of the key things about being a coach. And that was just something that I was kind of naturally able to do, but I didn't know until I started doing it, if that kind of makes sense.

Chloe Hall:

Yeah. I feel like, isn't that always the way, It's like you don't know something or you don't really know your strengths until you just step into it. You've really got to get out of your comfort zone and just try new things, experience new things. Otherwise, you're never going to know.

Renae Craven:

Yeah, exactly. So yeah, can't trying to create that equal participation in a room or in a workshop from a facilitation and facilitating a group of people from different walks of life to an outcome and just letting it kind of flow and let the conversations flow. But still, you've got to get to this outcome by the end of the day or end of the workshop. That was something that I was naturally able to do. And I mean, my first workshop, how I facilitated that, I don't even remember what it was, but I'm sure how I facilitate now is very, very different. But it was still something that I loved doing, that I enjoyed doing. And the training part of it, it's funny because at school I used to hate public speaking. I used to hate.

Chloe Hall:

You sound like me.

Renae Craven:

Yeah. All of that, how I used to get up in English and do an oral exam and things like that. I hated all of that stuff. I was very happy to just hide in the background and never answer a question or never cause any trouble or be disruptive or whatever. Except in maths class I was a little bit disruptive in math class.

Chloe Hall:

I am resonating so much with you right now because I was literally the exact same. And I've always had a bit of a passion for math. So in maths I was super outgoing, would ask so many questions. But in English my biggest fear was public speaking. I just could not stand up for the life of me. It was the worst. I was always so nervous, everything about it. And I think that's really interesting to see how far you've come today from what you thought back then. Was there any type of practices, lots of work that you had to do on yourself to get to this point today?

Renae Craven:

I think similar to what you said before, you got to get out of your comfort zone. And I think, especially early on in my career, that being pushed out of my comfort zone. There's a few leaders that I was working for at the time that, well a handful of people that over the years have pushed me out of my comfort zone. And in the earlier days where I wouldn't have done that for myself. So doing that for me or I didn't really have a choice because I was a good girl and I followed orders back then. It was just something that I went, "Oh okay, well that's cool". I'm glad in hindsight, I'm glad he did that because I wouldn't be where I am right now if I wasn't thrown into the pilot team, the pilot agile team. So yeah, there's things like that where I've been pushed into my comfort zone and just had a go and found out that, oh, it wasn't so bad after all.

Maybe I could do that again. And then you start to build your own kind of resilience, you go, well I've did this before so that's not much harder. I reckon I could do that. Or it's kind of thinking about it like that, but it's also changing. It was shifting my mindset to be you've got to get out of your comfort zone, you've got to screw up to learn. The way that it was at school where you got rewarded for being correct, you got rewarded for doing the right thing. And that's not how I learn. That's not how a lot of people learn. You have to screw up to then go.

Chloe Hall:

Definitely.

Renae Craven:

Okay, well next time I do that I'll do this instead.

Chloe Hall:

Yeah, definitely.

Renae Craven:

Or getting that feedback of how you did this, well next time maybe you could do this or whatever it is. Just getting that feedback. Whereas, I never got any of that at school. It was always Renae's perfect angel child, whatever it was.

Chloe Hall:

Still, nice though, but yeah.

Renae Craven:

Nice for the parents. Can we have more of Renae's in our class, nice for mom and dad. But in hindsight, it didn't really do much for setting me up for how.

Chloe Hall:

For reality.

Renae Craven:

Yeah

Chloe Hall:

Really.

Renae Craven:

Exactly.

Chloe Hall:

Especially because I've recently gone through that transition from graduating uni into a full time job and working for Easy Agile, I'm always being pushed out of my comfort zone in a good way. Everyone's so supportive, they're always like, "Oh Chloe, try this, try that". And I'm just like, "okay, yep, I can do it". And if it doesn't go amazingly well that's okay. I've learned something and I can do it better next time.

Renae Craven:

Yeah.

Chloe Hall:

You can't just sit in your comfort zone forever, you don't get that feeling of when you do something outside of your comfort zone, you just feel so good after and you're like, oh, prove to myself I can do this.

Renae Craven:

Yep. And I think the big part of that is acknowledging the learning is sitting down. So one of the things we do, I do as a coach is one of the key times for a team or an individual to learn is to actually sit down and reflect back and then what was good, what was bad, and what am I going to do differently the next time. And I coach teams to do that, but I have to do that myself as well. So kind of realizing that as a practice, that's something that I have to do is sit down and when I do these things I would need to gather feedback and then I have to sit down and reflect on how it went. What I think I can do better or do differently the next time around I do something like this so that I am also myself improving in the things that I do. So it's really having that time and that practice to learn to sit down and what did I learn?

Chloe Hall:

Yeah, I do. And I agree with that. You need to take the time to understand, reflect, realize what you have learnt. Otherwise, life is so busy and you just keep going and going and going and you can just completely forget and it's good to take that moment. I really like how that's something that you do in your Agile coaching as well. What else do you do when you're coaching teams? What other elements are there?

Renae Craven:

Some of the stuff I've already spoken about, having that equal, trying to get that equal participation, equal voice. Trying to, the buzzword is psychological safety, but trying to make, trying to build an environment for a team where everyone feels safe to ask a question or to voice their opinion or whatever it is. And when we've come from, as a coach, what we're doing is usually coaching teams, people, organizations, through a shift from a certain way of working to an Agile way of working. And that means that the whole telling people what to do and when to do it and how to do it is gone. That's gone. And now you want to build that capability within the team itself. So creating that safe space so that the

team can ask questions and understand what they have to do so that they can collectively deliver something as opposed to someone just telling them what to do.

So it's using your brain, using the collective group brain as well, instead of just having, not using your brain really, just waiting to be told what to do and then you'll know what to do, you just do it. But collectively solving a problem together as a team and then figuring out as a team how we're going to solve that or how are we going to deliver that is something that is quite, that's the bit I love as a coach, working with teams, building that kind of environment where they do feel safe to ask the dumb questions and things like that.

Chloe Hall:

And not have to be like, I think this is a silly question, but you definitely want to remove that.

Renae Craven:

And I think the other part is the learning still, it's exactly the same. It's taking the focus, trying to get the focus off, we must deliver and then we'll do some learning stuff if we get time trying to flip that around so that your, "No, no, no, you need to learn in order to get better at delivery". So take that focus, because a lot of teams will just say, we've got all these deadlines, all of this delivery pressure, we have to get this stuff done. We don't have time to sit down and think about what we've learned or how we can get better as a team. They're never going to get better as a team if they just keep in this endless delivery cycle. Making the same kind of time wasting things over and over and over again. So it's kind of flipping the mindsets of the teams as well to go, "No, hang on, we need to do this otherwise we're not going to get better as a team".

Chloe Hall:

Yeah, definitely. And I think that's where the Agile retrospective fits in perfectly. And I know I actually just came out of my retrospective with my team and we do that weekly and it's so good to come out of that with action items too. And it's like, okay, next week this is how we're going to get better. This is how we're going to advance, this is our focus and there's also no hidden problems because it comes up every Friday, we talk about it. So you're not going into Monday the next week with a grudge or you're annoyed about something with the workflow of the team. You've addressed it, you've left it in the last week, you've brought the action with you obviously, and hopefully it's going to get better from there.

Renae Craven:

Yeah, absolutely. And that's the key. It's the whatever we've decided in our retrospective of what we're going to do differently, we're doing that differently the next day or Monday in your case. It's not something we talk about and then we just kind of ignore it and we just talk about it again in two weeks time or whatever it is. It's the putting into practice the decisions you make as a team and those retrospectives all of the time. They're not massive actions either. They're just little tweaks here and there.

Chloe Hall:

Yeah, there's small things.

Renae Craven:

They just kind of build up over time.

Chloe Hall:

And that's the thing, it's like if you do it on a regular occurrence, they are small things, but if you are not doing it regularly, then that's when they build up and they become big things, big problems and massive blockers within the team as well.

Renae Craven:

Yeah, absolutely.

Chloe Hall:

Yeah. So I'm wondering too, Renae, when you do your Agile coaching and your Agile training, so you do that on an individual basis as well as teams. Do you think there's an aspect of the mindset, the agile mindset there, and does each individual need to come to work with that agile mindset for the team to be able to flow better?

Renae Craven:

Mindsets. If everyone had the same mindset then it would be robots or.

Chloe Hall:

True.

Renae Craven:

The world would be very boring.

Chloe Hall:

Very good point.

Renae Craven:

I think that's a bit, for me when I think about a team, an agile team, as long as there's some alignment on how the team behaves, why they exist, what their purpose is and how they treat each other and how they solve problems together, then the mindsets of the individuals within that team, they can be different. And that's fine as long as there's that agreement amongst everyone of this is how we are going to behave. I come up against people all the time who have been forced to work in this agile way. So their mindset's definitely not in the mindset that you need for an agile team, but if they're in an agile team and there's people in that team that have got the mindset or the behaviors that you need to have in order to deliver in an agile way, over time it kind of balances out.

And over time those the mindsets will start to shift as well as they see how other people in their team are behaving, how their leaders are behaving, things like that. So I kind of always think of it as more of a behavioral thing than a mindset thing. How do we make decisions, like I said, how do we treat each other, how do we approach problems, who are our customers, all of that sort of stuff. It's more that behavior that I like to, instead of me thinking, oh, they don't have the mindset, they don't have the mindset, I just kind of look at how they behave. Because at the end of the day, you can't force that

mindset. But as a team, when they start humming to working together as a team, they're going to be delivering what they need to deliver. And they all just, that's the whole cross-functional part of it. You're bringing together different minds, different backgrounds, different experiences, different skills, all of that stuff.

Chloe Hall:

Definitely.

Renae Craven:

You're putting them in a team together so that they can use their skills. They're all those different pieces to solve these problems.

Chloe Hall:

Yeah, no, definitely. I think the way people behave, it has a lot to do with it as well. And I think on that too, you can be in the right type of mindset, you can behave in the right way. And that has a lot to do with the way you're showing up at work as well. It's the way you come to work. If you're had a bad morning, then that's going to impact how you are that day. Or if you've waking up that morning and you have kind of a set morning routine that gets you into that good routine for the day, that good mindset and behavior, then it can help a lot. And I think as well, this is something I'd love to chat to you about too, because you've got the background of Pilates, you're in your own studio and you've been a instructor for how many years now?

Renae Craven:

It'll be a year and a half since I qualified.

Chloe Hall:

Yeah. Nice. Yeah, so I'm also an instructor. I've been teaching I think for about six months now. But I'm just wondering too, so you've got your two passions, Pilates studio owner and then also an Agile coach. Is there that element of setting yourself up for the day in the morning, do you think if someone, they meditate have the type of morning routine they exercise, can they behave better at work essentially? What are your thoughts on that?

Renae Craven:

Yeah, I think definitely the better you feel in yourself or the way feel within yourself, definitely has a direct correlation to how you come across how you behave at work. So yeah, if you've had a rushed morning or a traffic was crap on the way to work or whatever it is, then definitely you're going to be quite wound up by the time you get to work.

Chloe Hall:

Yeah, definitely.

Renae Craven:

It's going to impact the way that you respond to questions or respond to people or respond to your team or whatever it is. Yeah, absolutely. But myself, I don't really have a set routine in the morning. I go to gym but I don't go to gym every day. But the mornings that I do go to gym, I never feel like going because no, I just want to sleep.

Chloe Hall:

It's early. Yeah.

Renae Craven:

Yeah. But I have to go in the morning or I won't go to gym. Gym's something that, it's a bit of a love hate relationship. I know I have to do it, but I don't like doing it.

Chloe Hall:

Not even after? That feeling after?

Renae Craven:

Afterwards is good. It was like, but from, oh thank God that's done.

Chloe Hall:

Yeah.

Renae Craven:

Tick I'm done for the day.

Chloe Hall:

Out of the way.

Renae Craven:

If it was in the afternoon, if I went to gym in the afternoon I wouldn't go. It would just be, "Nah, it's too hard or I can't be bothered, I'm too tired". So getting up first thing in the morning, I set my alarm 15 minutes before my gym class starts.

Chloe Hall:

Wow. That is effort.

Renae Craven:

I know.

Chloe Hall:

That is good.

Renae Craven:

I race to get there but I have all my clothes set out the night before so I don't even have to think. I just get out of bed, I put my clothes on and I get in the car and I drive to the gym and.

Chloe Hall:

I do the same thing.

Renae Craven:

I do my class, I haven't had time to talk myself out of it just yet. But afterwards it's like, oh yes, excellent. That's done for the day. And yeah, it is nice to know that you have done that for the day as you start your work day as well. So on my gym days, that's probably my routine to get myself ready for work. But other days they're a little bit more relaxed I guess. I think if anything having a coffee is my, I cannot deal with the world without coffee. So whether I'm at home or I'm in the office, the first thing I'll do is if I get to the office I'll get a coffee on the way in. So I'm drinking coffee as I walk into the office. So yeah, I guess that you could call that my routine.

Chloe Hall:

No, I think a lot of people, a lot of listeners as well will be able to resonate with that. And I used to be like that and then it just, coffee wasn't sitting well with me. I found it was just really triggering my nerves for the day and everything. So it was so hard. I went from drinking two to three coffees a day to getting off it and now I'll drink like a matcha instead. But that was such a big part of my morning routine as well and getting off it was one of the hardest things I've had to do.

Renae Craven:

Yeah, I did that once. I detoxed for one of those health retreat things years and years ago and I had to detox off coffee and everything actually.

Chloe Hall:

Oh really?

Renae Craven:

Before two weeks leading up to it and yeah, coffee was hard.

Chloe Hall:

Yes.

Renae Craven:

Very, very hard. Because I love the taste of my coffee. I just have it straight, I don't have any milk so I love the taste of my coffee.

Chloe Hall:

Yeah, wow. Okay.

Renae Craven:

But maybe it's also the other benefits of not wanting to kill people that coffee does to me as well. I can deal with the world now. I've had my coffee.

Chloe Hall:

You're like okay, all right. Who needs coaching now? Who needs training? And I'm ready to rock and roll.

Renae Craven:

Yeah, I'm good now.

Chloe Hall:

Yeah. Nice. Yeah. Well the reason as well why I wanted to talk about the whole exercise correlation with work was because I did read your article on LinkedIn about what sitting all day is doing to your body and you're saying how Pilates can help with that. The section that I think resonated really well with me was when you said, when COVID-19 shut down the world and confined everyone working from home, those people who were working in the office environments, you found yourself sitting bent over a PC at home all day and it's back to back virtual meetings, you don't really have that chance to get up, have a break, go for a walk around and everything. And I think, I'm sure a lot of our listeners will be in that reality and even after COVID it is still the case. So I think just for the sake of everyone listening, is there any tips or anything to get you up, get you moving so you're not experiencing that on the daily.

Renae Craven:

I think the other difference is before COVID, sure you were sitting at your desk all day at work but you are also walking to the office and walking to meetings and walking to the kitchen and walking to go and buy your lunch and things like that. And you weren't kind of back to back meetings either. So you had that chance and if you were walking from room to room so you were getting up. Whereas at home it's just back to back meetings and I don't know about you but I run to go to the bathroom in between meetings.

Chloe Hall:

Yeah. I do. I actually do. Yesterday actually bit triggered by that.

Renae Craven:

I did that too yesterday actually. And even at the height of COVID, the back to back meetings were so bad. I didn't even have a lunch break. I was working, I was making my lunch in meetings and daylight saving as well. It always throws things because Queensland stays where they are and it throws everything out so. So in my article actually, it was more of a paper that I had to submit as part of my instructor course.

Chloe Hall:

Oh cool. Yeah.

Renae Craven:

And as well as my 600 hours of practice and.

Chloe Hall:

Yeah. I can relate, I didn't have to do the article though.

Renae Craven:

So I kind of just pulled bits out of that and because I thought this is still relevant and maybe it will resonate with people and especially the people that I'm linked, LinkedIn is the audience, right? So that just things that happen from sitting, sitting down's bad for you, full stop. Where you're working or sitting on a couch all day, whatever it is, sitting down's bad for you. And the longer you sit, the more kind of slouched you get. The more your spine is always kind of in the rounded state, the less you are using your back muscles, your back extensors, the more you're sitting down your pelvis, your hip flexes are shortening because you're always sitting down and that kind of tightens your lower back. And then you've got your, even just using your mouse, you've got that shoulder that's doing extra stuff or backwards and forward stuff constantly. And then your neck as well and your traps, everything gets kind of tight.

So things that you can do. I wrote a, my article's got an example class plan to undo the effects of sitting down all day in an office job. But that class plan uses all of the apparatus. So there's things you can do on the mat or the reformer or the Cadillac or under chair. But I run a few online classes after work and they started during COVID and they're still going. And I designed those specifically to undo, I know those people have been sitting down all day. So my classes are very much unraveling everything that they've done the all day.

Chloe Hall:

The body.

Renae Craven:

I mean my classes, my math classes anyway, they're usually focused around, I mean tips for people not actually coming to a class but undoing, you're doing the opposite of what you've been doing all day. So if you sit all day, stand up, walk around, at least listen to your smart watch when it tells you take a break. Stand up and take a break. And walk out to the letter box and get some sunshine at the same time, if you're lucky there's not much suns around these days.

Chloe Hall:

If it's out, make a run for it.

Renae Craven:

Doing kind of shoulder rolls and neck stretches and hip flexors stretches so that you, like I said, just undoing, doing the opposite of what you do when you're sitting. So think about the muscles or the tendons or whatever they're, even if you're not familiar with what they are, you know there's some at the front of your hip. And when you're sitting you can imagine that they're not being used, they're just being stuck there. So straighten them. Stretch them. If you're rounded all the time in your spine, then press roll your shoulders back, press your chest for and use your back muscles. And I don't even know if people are that familiar with back extensors. I don't know if people understand that. Because you've got your spine and then you've got these muscles that they're twisted that run either side of your spine. I can't remember the scientific name for them right now.

Chloe Hall:

No. Me neither.

Renae Craven:

We just call them back extensors. And when you straighten in your spine, they're working and you're switching them on. It's just working your bicep, strengthening that muscle when you straighten your spine and you can even go past straight and go kind of backwards. You are using those back muscles and you're strengthening those back muscles and it'll stop you being like a rounded.

Chloe Hall:

Yeah, just bent over in the computer all day.

Renae Craven:

Hunched over.

Chloe Hall:

Yeah. That's it. You don't want that.

Renae Craven:

So it's really just doing the opposite or yeah. Joining online classes. I can put you through some exercises.

Chloe Hall:

Yeah, well we'll definitely share that article as well with this podcast so people can see that program or might be something that helps. For me at work we're very fortunate that we have a standing desk and I think that that is just so amazing. Because if I work from home, I don't have a standing desk and I can feel the difference. My body just feels, you just don't feel right and I feel more fatigued and yeah, I just need to get up and move more often.

Renae Craven:

Yeah. If you stand all day, it's the same thing. You've got to sit as well. You've still got to do the opposite. Standing is like, because you can get slouch when you stand as well, so you can still over time get tired and kind of slouch over or you're still kind of tense in your shoulders and things like that. So you can kind of need to still be aware of your posture when you're standing and just self-correct or still go for walks, still give everything a chance to move the way it's supposed to move not stand still all day.

Chloe Hall:

Yeah, definitely. On that, Renae. Yeah. Thank you so much for coming on the podcast today. Really enjoyed this chat with you. I think there's a lot that our listers will get out of it and I definitely want to continue more of this Pilates conversation too.

Renae Craven:

Thank you Chloe. Thanks for having me.

Chloe Hall:

No worries, thank you.

"I loved having the space to talk about common interests - all things technical documentation & information architecture" - Henri Seymour

On this episode of The Easy Agile Podcast, tune in to hear Henri Seymour - Developer at Easy Agile speak with Matt Reiner - Customer Advocate at K15t.

Henri & Matt are talking all things technical documentation (we promise this episode is way more interesting than it sounds! 😉)

✏️ Considering technical documentation as a product
✏️ The value of well written documentation
✏️ Why you should be digitally decluttering often
✏️ Information architecture

So many golden nuggets in this episode!

Be sure to subscribe, enjoy the episode 🎧

Transcript

Henri Seymour:

Hi, everyone. This is the Easy Agile Podcast. We've got an episode today with Matt Reiner. I'm your host for today, Henri Seymour, developer at Easy Agile. And just before we start the podcast, I'd like to acknowledge the traditional Australians of the land on which I'm recording today, the Watiwati people of the Dharawal nation. Pay respect to elders past, present, and emerging, and extend that respect to any Aboriginal or Torres Strait Islander people listening to this episode.

Matt is an experienced content strategist with a history of working in the computer software industry, skilled in agile scrum framework, related tools, communication, technical writing, video production, customer interaction, strategic planning. And he's here today to talk with us about writing and specifically technical writing and documentation. Hi, Matt.

Matt Reiner:

Hi. It's great to be here. Yeah, I'm Matt. I'm into all sorts of content things. And one of those is technical writing, which is, I think more interesting than it sounds. I guess you'll have to decide by the end of the podcast, if you think so.

Henri Seymour:

Technical documentation experts. So when you talk about technical documentation specifically, what do you mean by that?

Matt Reiner:

Well, I feel like that term is actually in the middle of a big change right now. In the past, technical documentation was very strictly like, "Okay, we're a team, we're making a thing, a product." Maybe it's an app, maybe it's, I don't know, a go-kart and we need to have a user manual for that. Technical documentation was someone sitting down and writing down, "Okay, here are all the knobs and switches and here's what they do. Here are all the features. Here's maybe why you would use them."

So putting together that user guide, which traditionally was printed material that you would get with the product. But it's become a lot more over time, partially with the internet, because we can just constantly iterate on content like many of us do with the products that our teams make. And then also we are seeing it in new forms. Maybe it's not a printed piece, in fact, most people do not want printed technical documentation anymore, they want it online. Or even better, they want it right in context in your app when they're using it, they can just get the info they need, and then get on with it.

That's what technical documentation is. It's supposed to be there to help you do the thing that you really care about and then get out of the way so that you can do it.

Henri Seymour:

Do you have a description of why good technical documentation? Not just having it, but having it at a good quality in a way that really helps your users, is so important to product users.

Matt Reiner:

Well, I suppose we all find those points in our day or in our journey that we find ourselves in where we want to accomplish something, but we don't know how to do it. So a lot of us have really gotten very used to jumping on Google and saying, "Okay, here's this thing I want to do, how do I do it?" And good technical documentation is there with the answer you need, the explanation you need. Because really ultimately all of us are smart people who should be empowered to do the thing we're passionate about.

And technical writers and communicators who are really all members of our team. People who sit down to create good technical documentation uses few words as possible to get a person on the way they're going. And that's like, when it happens its just like, "Glorious," not to the user. They don't even know that it happened, they didn't even know that they read your writing. But to the writer, it's like, "Yeah, I did it, I did it. They don't even care what I did, but I did it." And now they're doing the thing that really matters.

Henri Seymour:

That's great understanding one of the major differences of like, I've written something and I don't want my user to be spending time on it. I want as little time spent reading this as possible.

Matt Reiner:

Yeah, yeah, yeah. You can have great pride in your work, but one of those metrics that a lot of people look at for websites is time spent on page. So sometimes you can fool yourself into thinking, "Oh wow, they spent 10 minutes on my page. That means my documentation's really good." But also that might mean that it's not very good and they're having to reread it over and over again. So the true metric is, did they get to the thing they really cared about? And unfortunately, it's hard to measure.

Henri Seymour:

You mentioned now that with the advent of the internet and giving you the opportunity to iterate on those docs in a way that you wouldn't be able to with printed documentation. That iterative thing brings the agile process of iterate on something that you already put out and improve it in the same way that as a developer I do for products. Can you tell us more about that iterative agile sort of process?

Matt Reiner:

Oh yeah. Yeah, it's so true. Documentation used to be back in the waterfall standard, more typical product project management days, documentation was a major part of it. You'd start this project by writing these massive documents of, "Here's what we're going to set out to do. And here's all the considerations, and here's how everything's going to connect up." And that did work really well for a lot of hardware. Which was the thing that we made for a long time. Just everything that humankind made was hardware often, as groups anyway.

And then all of a sudden this whole software thing comes along and we're trying to build that like it's a physical thing. And we get to the end of this two-year software project and people are like, "Yeah, that's not the thing that I wanted." But we're like, "Oh, but we go back to the beginning and look at that documentation, and that's what you said you wanted." But now with the internet and with just agile development, we really need to move away from this place where we start with a pile of documents. And then we develop another pile of documents as our, I don't know, development guidelines.

And then our test plans, and then finally we end up with user documentation. Instead, these days, documentation should really just grow from a very small piece of content throughout that whole agile development cycle into that final user documentation. Because it doesn't matter what we set out to make, it matters what we make. Nobody he wants to read about what we thought we would make, that's straight up fiction. And it's probably not an interesting read. It's really that final user guide that comes out of the agile process, but that's a big change, but it's a good one.

Henri Seymour:

I love that idea of just like, this is gradually growing. There is no specific start block and end block. It's a process. And you mentioned the opportunity to iterate on those documents. Do you have any advice for after you've published digitally your technical documentation from iterating on what you've already got there, improving that over time?

Matt Reiner:

Oh yeah. I know every agile framework is different, but they all have that feedback phase, where... And really that's throughout the whole process, but we do need to dedicate some time. So, there's a lot of different things we can look at. For example, I don't want to say basic, a standard one that we should be looking at is, you should have a help center, where you can implement something like Google Analytics so you can see just, what are people looking at? How long are they looking at it?

Another really good one is, you have to set it up separately in Google Analytics. What are people searching for on your site? You can also use Google... used to be Webmaster Tools. I think it's called Site Tools now, but you can see what were people searching for on Google before they came to your pages. That's all really, really valuable stuff. Then you can get more advanced. You can look at pointer tracking, apps that you can embed on there, which you get some pretty wild stuff.

But then you also, you want to consider having a forum at the bottom of each page like, "Was this helpful? Was it not helpful? Oh, it wasn't helpful? Tell me why. Oh, it was helpful? Tell me why." Just like a YouTube creator, they look for that feedback. That feedback is essential, the thumbs up. In fact, it's very controversial, YouTube just announced that they're going to hide the thumbs down numbers, but a lot of creators are like, "No, no, no don't do that because that communicates the value of this video that is out there."

So there's a lot of those signals. And then there's just really soft signals that, it's hard to know if people are using the content or not. Because you may never hear. Especially, if it is one of those things that they just get in and get out, you're not going to hear anything about that. But the feedback phase, it's really great to... Anytime you're getting feedback on your product that you're making, try to get your documentation out there as well. Because that's the time where people are open to exploring your product and giving feedback.

So why not explore that same documentation, the related documentation to see, "Okay, is this actually helping these people do the thing that they want to do? Or should we improve it just like we do with the product?"

Henri Seymour:

No, that's a really good, comparing the, we've just released a product. Give us feedback with doing the same thing with the documentation. Because that's when it's going to reach its peak use before everyone's got the hang of it. We've just done this feature release, let us know how you go using it, and the documentation is in a sense part of it, especially for more complex products.

Matt Reiner:

Exactly.

Henri Seymour:

Do you have any background in the customer support side of things? We do customer support in-house as well as their documentation. So we're trying to improve the documentation to lower the support load on our team. Do you have any background in that... Can you solve it?

Matt Reiner:

Yeah. Well, yes and no. It's interesting. I work at K15t now, I used to be a customer of K15t's, so that's actually how I met the team. And that was also how I met documentation in the first place. At my last job, they brought me in to administrate this system called Jira. And I was like, "I don't know what that is." I told them, "I thought I could do it." And I figured it out, it was this little thing called Jira On-Demand, which is now Jira Cloud. And I introduced Confluence On-Demand to the company as well. And wow, I broke Jira a lot of times.

Luckily it wasn't like mission critical at the time, we were still really figuring it out. But it was through Atlassian's documentation on Jira that I really learned like, "Wow, there is tremendous value to this content here." And then I discovered, "Okay, how is Atlassian creating their documentation? Oh, they're doing it in Confluence. They're writing it in Confluence. They're using these apps from K15t." And so I started using those apps, and then I talked a lot to K15t customer support, just questions and how do I get this started?

And we also do our support in-house, so it's really great. So maybe as a customer, I overused it, I don't know. I should ask some of my colleagues if they got sick of me. But the benefit was very clear because they would send me, "Oh, here's documentation on this. And here's the answer to this question or here are the considerations you should keep in mind." And actually several of our teams now, we're really looking at, especially, for those features that are very robust, people have questions.

So it's like, how can we enable them to help them help themselves? And putting those resources out there is one thing, making sure that Google can find them, well, is another. But that is a really important thing, especially, since as a product team, when your user base grows, so does your need for support. It's just... I don't want to say it's exponential, but it's in line with each other. And so, one of the ways you can mitigate that is, making sure you have good design so that your product is easy to use. And then another is you need to have good content all around that entire experience so that you don't have to keep hiring more and more support people.

Or your support people can specialize and really focus on those deep entrenched issues, and then the documentation should help with the rest. But the secret sauce there is tricky. It's hard to write the perfect content to deflect the cases. That's everybody's dream.

Henri Seymour:

Even if it is just not all of them, but some of the common use cases start to get deflected away from support because people can self service. It does make a difference. And I really understand the idea of Jira documentation as well. Easy Agile works on Jira and it's... Jira is an incredibly complicated product at this point, and I imagine it probably was also complicated when it was Jira On-Demand. Because it's so complicated and so detailed, there's no way to make that easy to understand for a user without that documentation. There's no getting around that one.

Matt Reiner:

Yeah. I think there should be a club for the people who have broken workflows too many times in Jira. But yeah, I mean the documentation saved me many times and I would have to put out a... Well, it was a HipChat message at the time. May it rest in peace and I'd have to say, "I broke Jira, give me a minute. I got to go read something." Not the way you want to learn Jira, but it's an option.

Henri Seymour:

It is. Sometimes you learn things by breaking things. That's-

Matt Reiner:

That's right.

Henri Seymour:

Really seems like my experience in software so far. You try to break the things that people aren't currently using and that's about all you can do.

Matt Reiner:

Exactly.

Henri Seymour:

So K15t has recently published Rock the Docs. Can you tell us a bit more about this project?

Matt Reiner:

Yeah. Rock the Docs, actually, it came out of a lot of that information that I got from K15t. Customer support, I got from K15t documentation, I got from Atlassian documentation. And then some of the stuff I figured out on my own, or some of my colleagues at K15t did. Essentially like, what are the best practices for creating really good content in Confluence? And it really started with a collection of guides on how to create technical documentation content. It's geared toward like making a public help center, but really it's for any kind of content that you want to be like evergreen, longstanding content to be able to help people.

So we initially talked about all sorts of things like structuring your content, content reuse, managing multiple languages, which can be tricky in Confluence. Collaboration, publishing your content outside of Confluence in one way or another, managing versions of that content. So, that's the start of it. And then we saw a lot of positive response with that and we had more general questions like, "Okay, but what are the best ways to get feedback in Confluence?" Or, "How do I make a template or a good template or how do I make a good diagram in Confluence?"

And so we've grown that content to focus on just all sorts of general Confluence things. Because we found that there's a lot of information out there on how to do something. Atlassian documentation really helpful, but there wasn't as much, I'm like, "Why would you do it? And why would you do it this specific way?" And we've been working with Confluence for over 10 years now. Like I said, I've been with Confluence since the crashy early cloud days. It's grown up so fast, it's beautiful.

But we just know we've done a lot of stuff with Confluence, so it's been a real privilege to share that both in like these written guides. And then actually recently we've started publishing a series to our YouTube channel as well, all about Confluence best practices.

Henri Seymour:

That's great. It's real interesting to hear how that started as a smaller project than it turned out to be, because you could see the value in it and the use in it. We've discussed Confluence a few times now and K15t builds apps that use Confluence as a documentation source. Can you tell us more about what makes Confluence useful for building technical documentation? What sort of tools and approaches that make it useful in this context?

Matt Reiner:

Yeah. Confluence is by nature open, which is not the way technical writing tools are built. In fact, I remember the first time I went to a technical writing conference and someone asked me, "Oh, what tool do you use?" Which is like, what technical communications people talk about, because we're all nerds in that way. And I was like, "Oh, I'm doing it in Confluence." And they didn't really want to talk to me after that because they didn't think I was a serious tech writer. And I was like, "Oh no, no, no, no, this is all happening."

At that point, Rock the Docs didn't exist. So I couldn't be like, "Go over there and see how it works." But the biggest difference is most tech writing tools are just totally locked down. You have two licenses for your two people who are trained professional tech graders, and then everybody else, there's no access. You don't touch it. Maybe your tech writers will send you a PDF and you have to go through the God awful process of marking up a PDF to tell them like what to correct. Or, I've heard of teams printing out the content and people penciling in what needs to be changed.

The review processes are just out of this world insane. And those tools don't fit terribly well with agile processes because it's like, you build the thing over here, and then here's the two tech writers over here in their separate tool. And at some point we'll be like, "Okay, this thing's done. Would you write about it?" So with Confluence, the benefit of using Confluence is, it's accessible to everyone on the team and even people outside the team. And that's incredibly by an official because we've seen with agile, but we're also seeing in this technical communication and in information design field, that teams are less and less looking for those specialized individuals who are trained tech writers.

Which that's an oxymoron because half of us, we don't have degrees in tech writing, we fell into it for one reason or another. But now teams are starting to see, "Hey, I can be a code developer and an information developer. I might not write the final piece of written content that is seen by our customers, but I might write the first draft." Confluence really opens that up for everyone. And especially with like at mentioning and inline comments, review processes are just so fast.

Actually, the reason that I switched to Confluence at my last job, was my product manager threatened me and said, "I will not mark up another PDF. Go and find a good tool that we all want to work in." And that's where we landed on Confluence. It's about bringing the whole team into the writing process instead of having it be this separate thing. Because when it's a separate thing, we lose track of it. And content, we forget how important it is to our product, to the customer life cycle, to... God bless customer support, who really, really need that content to be good and accurate.

And it needs to be seen by the real experts who validate, "Yeah, okay, this is correct. This will actually show people how our product works." And Confluence is like the heart of that.

Henri Seymour:

No, it's great to hear how that all comes together to build the documentation as a team. Can you speak more to the different roles in, specifically in software development and the different roles you're looking to get involved in your documentation process? We are working on building our specific app teams here at Easy Agile as we're growing at the moment.

Matt Reiner:

Yeah. That's such a good question. Well, what-

Henri Seymour:

And how do you incorporate... Sorry, this is more specific to my question. How do you incorporate that technical writing process as part of the work of an agile software development team?

Matt Reiner:

Well, first, it starts by rethinking priorities because most teams are like, "Documentation down here, testing and then everything else above." So generally, those two things should be moved up. And actually, the content around our product is... I don't want to sound over traumatic, but if we don't have information, we don't have a product. I don't care how much code you write. If we're not explaining it to people, if we don't have good UI text, if we don't have good in-app help, it doesn't exist. It's not a useful tool, it's just a set of mathematics that humans can't interact with.

So content is essential, so it's really important that we elevate it to the position where everyone on the team recognizes that the content experience that our users have is the product experience they have. So it needs to be part of the product development process. So then the next step, which I know you're talking about team structure, but the next step is really everyone on the team needs to know they're a writer, and they're a good writer. And that's important because a lot of people have never heard that. They've never heard that they're a good writer, and they probably have never heard that they're a writer.

I remember going through university, my writing classes were the things that I didn't pay attention to. I was doing mathematics, and Java programming, and statistics. Even that seemed more important to me, not the writing classes. And then sure enough, it turns out everyone has to write. We all write. So knowing that that is a role that everyone fills is really important. And then when it comes to actually team structure, you need to have individuals who are willing to cross the streams, so to speak. If you're bringing in someone who's focusing on test engineering, they need to realize that the test plans they're writing are very similar to a lot of user documentation that needs to be written.

They're writing task topics, or task instructions, do this, do this, do this over and over again. That's documentation. They could be contributing in that way. Engineers, as I mentioned, they could be drafting the first copy of a lot of what are called concept topics. So areas of documentation where you explain concepts, because they already know what those concepts are. In fact, if you look at the root of a lot of agile development teams, they're using epics and user stories and acceptance criteria. And all those map perfectly into the documentation you needed to create for that new feature you're working on or feature you're improving.

So really, it's essential to have everybody recognize, we are all already creating documentation, so we can contribute. And then of course, you really do want to have at least one probably native English speaker. Maybe not native, but someone who feels confident in their English or whatever language you're authoring in. English is typically the cheapest one to translate to other languages, so that's what people go for often. But that person's the person who takes everything everybody's written, gets it to the right style and tone. And then gets it out there. That's what we are seeing be successful.

Like our teams right now, we don't have any legit tech writers. We have product managers writing. We have product marketers writing. We have engineers writing. Some of the best documentation I've ever read was from one of our German-speaking engineers. I was like, "Peter, this is an amazing guide. You got to get out of this Java and get into English, man. It's great. It's great." So he's done a few, which I really love. But yeah, it's about jumping out of your typical roles and realizing, we're all documenting this stuff, anyway.

Henri Seymour:

I love the focus, especially with your German-speaking colleague. The focus on, it's not just that you must write the documentation because you know how the product works and we need that written down. It's, you are capable of writing the documentation, you can do this. You have that added barrier of safety with somebody who's got the language proficiency that they're going to massage it and edit it at the end.

So, before it gets anywhere, anything that you do is going to get filtered out if it's not working. But you don't need a specific tech-writing background to write the docs.

Matt Reiner:

No, absolutely not. In fact, there's an entire community of what... They call themselves documentarians called Write the Docs. And that whole community, that whole group is focused on, it doesn't matter what you do, it matters that you care about writing the docs, contributing to the content. And that's been a big shift, I think in the industry, where people thought we're separate. But now it's like, "No, no, no, we are all able to do this." And once we can respect the contributions that each of us can make.

And then also, I have that protection of somebody else is going to have their eyes on this, which even my writing, I'm like, "I don't like to send it out until someone else has seen it." Because I make spelling mistakes and typos all the time. I really want to have another colleague look at it. Even if they're not native English speakers, because they catch my typos pretty often. That feeling of togetherness, it's the same way that we feel when we ship out a project or a product.

Whether you did the testing for it, or you wrote the code for it, or you did the product marketing for it. It's like, "It's our baby. Let's send it out and see what happens." Content's the same way.

Henri Seymour:

Yeah, part of my daily role and [inaudible 00:28:03]... We don't have QA team separate from developers. Our developers also review our code and it's that sense of, "I wrote this thing, but I have one or two other people who've refined it, who've made sure that it's good enough quality. They've got that fresh eye, so they'll see the spelling mistakes, they'll see the minor little errors that I've just been looking at it too long to notice anymore."

I found the documentation writing process has some parallels in there like, "Here's my thing. I'd like some feedback on it before it goes out into the real world."

Matt Reiner:

Yeah.

Henri Seymour:

That's great.

Matt Reiner:

Yeah, absolutely. Yeah.

Henri Seymour:

All right. Can you talk a bit about the difference between the customer-facing documentation that we've mostly discussed so far and internal documentation?

Matt Reiner:

Yeah. There are some differences and there are some major similarities. So this very... It sounds very technical and ugly. The term information architecture, it's really important with any kind of content, internally and externally. And really that's like, if you're a developer you're familiar with XML, you're familiar with structuring things in that way. Our content needs to work the same way. And that goes for internal and external documentation. So, many of the things that they use, writers, when they write a page or an article in the newspaper, they'll use that Pyramid approach, where they put the broad bits of information at the top. And then they slowly focus in on the topic and give more and more information about it.

But you want to make sure that if somebody only reads the first paragraph, they're getting a rough idea of what the information is. And that's really important for successful Confluence pages and spaces. People should be able to start at the top level of the space, understand what the space is about, and then be able to navigate down into the thing that they really want to learn about into the page itself. Which should then be using headings and subheadings and bullet points to get, again, just disseminate that information and break it down. Because everybody skims.

We need our content to be skimmable, our spaces need to be skimmable. And that kind of content also makes Confluence search happy, especially the new Confluence Cloud search, which has been greatly improved. There's a whole new elastic search base to that that's being optimized. But it's happy, it's just like with Google when we structure our content like that. So when you have a page that is just a wall of text, no headings, you're not breaking it up into pages or even spaces, nobody's going to be happy with that.

The bots aren't going to be happy with it, the people reading aren't going to be happy with it. So it takes a bit of work to structure, break up the structure of our content. It's probably all good as long as it's up-to-date, but it's really essential that we think about, how do we structure that in Confluence so that people can find it and people can skim it? And that is what seems to plague a lot of internal Confluence instances, because a lot of... Maybe the team isn't so focused on that.

It's like, "Oh, our external help center that's come coming from this space over here, that's fine. Our team space, hot mess, total tire fire." And nobody cares because they think they know where everything is. But then you start to think about, "Okay, but what about the new team member? How do they find something?" Or, "What about the team member who's been away for Paternity leave for six weeks? Are they going to remember where everything is or know where all the new stuff is?

What about folks with disabilities? Is it going to be much harder for them to navigate to the information they need? Because they're working with a screen reader and they're trying to go through a wall of text. They need headings, a screen reader relies on those headings and titles." So there's just so many considerations that really leadership of companies needs to understand, just because you have a process to do something or the information is somewhere, doesn't mean you don't have a major information problem. And maintaining all of your content in Confluence and then maintaining it well.

That is what enables people to avoid the frustrations of searching for information, losing information, having to relearn or rewrite information. I have worked at too many companies that just information sieves everywhere. I don't even want to call them silos because nobody knows where stuff is anymore either. That's what Confluence brings to things, and that's what matters with internal content pretty much as well as external.

Henri Seymour:

That's a great perspective on it. And I can see the silos, it's a really more... Just a one big pile, you can't find anything. I've been-

Matt Reiner:

Exactly.

Henri Seymour:

... at Easy Agile for more than half of its life now and I've got that sense of like, "Oh, I know I wrote this down somewhere. I know I've seen this written down somewhere." And we are making a habit, especially as we're hiring more and more people. Every time somebody's going through onboarding, they're going to be looking at all of this documentation with no previous background on it. And we want to hear their feedback on it specifically. Because if it works for them, then that's the documentation that we need for them and for everyone after them, and for everyone who's already here.

Especially, I've been at Easy Agile for almost three years now, and I've seen it grow from eight people to now we're up to high 20s, I think. We're going to cross over into the 30s by the end of the year.

Matt Reiner:

Wow.

Henri Seymour:

The growth of information that we have in our internal documentation, and I'm sure it would parallel the growth of the product documentation for a product that's been expanding for three to five years. How do you manage the documentation and the Confluence spaces as the team and the company grow and you just develop more and more pages out of it?

Matt Reiner:

That is the question since the dawn of the universe or at least the dawn of Confluence, which, what's the difference? The biggest thing is team responsibility, so knowing this is our space, this is our content. And not like in a territorial way, but this is our responsibility. Much the way we should think about our planet, we should also think about our content, keeping it groomed and taken care of, and up-to-date and accurate. And then as things change.

For example, we have a product called Scroll Viewport, which is actually what enables you to publish content from Confluence to a public health center, which is really, really cool. So with that, we had a server and data center version. We've had that for quite some time. That's what I was a user of. And then we set off to develop a cloud version, and cloud requires a whole bunch of new infrastructure, which is a lot of fun and very challenging, but it's a totally different beast.

It's not like you can just lift the server code and just drop it into cloud, which is what as a user I asked them to do for years, "why isn't this on cloud?" Now I know why. So we created a new team that started off this Scroll Viewport on cloud effort. And it was just a very scrappy project at first. And I remember the first page we got up there, it's like, "Whoa, look at this page we published." And then it progressed from there. But then at some point, we needed to bring the two teams back together. And what we could have just said, "Oh, this old Viewport space, whatever. We're just going to leave it there and then just go on with the new one."

But instead the team took time and brought the two spaces together and really went through the old content in the Viewport Server and data center space to say, "Is this all still relevant? Do we still need this?" So it's been reordered in such an amazing way. Several of our teams have gotten really good at making these spaces so that I can come in. Because I work with all of our teams, just get in and find what I need, even though I'm not working their day-to-day. I'm just so glad, I'm so proud of the team for not just letting that space languish somewhere or being afraid to delete or archive content, which a lot of people are.

It's like, "No, what if we lose something?" It's like, "No, no, no, we've moved past this. We really do need to delete it." So that's the kind of attitude it takes is, our teams to split and expand and grow, and we need conscious of that content. Because again, think of the new person, think of the person who's learning something new. Think of the person who maybe does have disabilities and is trying to get the content they need. They just don't have the background that you do. Having been with the company for half its life, you know how to dig through the thought pile to pull out just the thing you want, but they don't.

Henri Seymour:

Yeah, and I don't want to be the person that they have to ask every time they need information, "Hey, can you find this for me?" No, no. I want to build a system that means that I don't have to answer the same questions all the time. That's one of the reasons I've been doing internal documentation so much since [inaudible 00:37:36]. I've answered this question once, that will do.

Matt Reiner:

Yes. That's a really good way to motivate any contributors to documentation. "Hey, you know how you wrote that piece of our app that one time and then everybody's asked you about how it works ever since? Just document it once and I promise you can never answer it again." That's good motivation right there.

Henri Seymour:

It is. As well, we've got a team on support models, so I'm working on the store maps and personas, product development team. And that's the same team that gets all of the support requests about story maps and personas. So yeah, the better we make the product, the better we make the documentation, the less of our time every morning we spend doing that. And the more we can get back to our regular jobs.

Matt Reiner:

Exactly.

Henri Seymour:

It's been great for helping us keep in contact with the customers and what they're doing and what information they need when they're using our product. You mentioned that like it's necessary, it's valuable to be deleting an archive-based stuff, pages in Confluence from time to time. When you're looking at a page and wondering whether or not it's time to go, what sort of questions are you asking yourself?

Matt Reiner:

Well, a great one is like, look at the last modified date on that page. That's general a pretty good sign of like, "Are people even looking at it?" In fact, if you're on cloud premium and above, you can look at some great metrics on every page to see like who's looking at this thing? Is this valuable? What are the views like? Just the same way that you would look at your external website to see if your content is valuable or effective. But typically, we have a lot of debris left over from product development or team activities.

Like if you're in marketing and you have a campaign from three years ago, do you really need all of those detailed pages? Maybe keep the overall campaign page, maybe that's useful, but do you really need everything? If you're into testing, do you really need every test plan you ever created? If you're in the legal team, do you really want your legal terms from 10 years ago? Maybe, maybe, I'm not in legal. But often we have this fear of, it's like fear of missing content.

It's like, "Oh no, if I get rid of that, then I won't have it." But information, just like language, just like the way we think, just like the way our teams grow, it changes. And so we need to be aware of that. As we are changing as a team, you should expect our content to change. And part of that is shedding that old stuff. So it's always worth it, like if you're questioning it, ask another subject matter expert and be like, "Hey, I'm pretty sure we don't need this anymore, or we should revise this. What do you think?" But if nobody has any qualms, you should probably delete it.

Henri Seymour:

No, that's great. I am a big fan of decluttering, even digital decluttering. It's, I want people to find stuff and the less pile there is, the easier it's going to be.

Matt Reiner:

Yes. Because somehow bad information is less helpful than no information.

Henri Seymour:

Yes. It's like coming across a question and they're like, "Oh, I tried doing it this way." I'm like, "Oh, that way doesn't work anymore. You're going to have to do... Where did you find that written down? I'll go update out." It's-

Matt Reiner:

Yeah.

Henri Seymour:

... new people doing stuff. The best way to understand where your documentation is falling over. It's the same as you're never going to understand how your product documentation and that your product itself is failing your users until they come to you and tell you, "Why can't I do this thing?"

Matt Reiner:

Yeah. Yeah. In fact that that power of bringing in someone new on your team is so amazing. And it's almost hard to impart like first day of onboarding like, "You have fresh eyes, please use them. This is called an inline comment, please put it everywhere." I remember going through our human resources employee handbook, which we had just created not too long before I joined. And I remember them telling me, "If there's any questions, at mentioned us." And I was really afraid to do that. But we corrected a lot of things.

For example, we mentioned do these things on... What was it called after HipChat? The product that lived and died so quickly.

Henri Seymour:

I think I missed that one.

Matt Reiner:

Oh, the one that Atlassian made and then they sold it to Slack.

Henri Seymour:

Now, where do I even start on that?

Matt Reiner:

How am I... It was a great app, I really liked it. But we mentioned in the employee handbook to use that. And I'm like, "Oh, I think we're using Slack now, we should update this content." That's stuff that HR is never going to go through and catch, but your new employees can do that. New people are the best way to tell you if your processes are bad, if your content is better. Maybe not bad, but they're bringing in something new. That's why we added them to the team. And they should not be afraid from day one to ask questions, or poke holes in our already messed up or failing process.

Henri Seymour:

Yeah. And I can really see the benefit of the tools in Confluence, like that inline comment. Even if you don't know how you need that page updated or what the new version's supposed to be. It's just coming in fresh, you can go, "Oh, this is weird, or incomplete, or it might be wrong." It's just a little comment. You don't have to change it yourself, just say something. Here's a way to speak up without changing it yourself. And somebody who does know is going to be able to change it for you.

I was excited to hear you talk about information architecture. That's something I only got introduced to last year also. Do you have a general explanation of what information architecture is and why it's relevant to documentation?

Matt Reiner:

Oh, information architecture is, there are whole, people, professionals whose entire career is coming in and helping you. So I'm not one of those professionals, I just play one on TV. Really in essence, information architecture is breaking down what would be a wall of text into a pattern of information that anyone's mind can connect to. That's the real and ultimate goal, and that starts by just breaking up logical chunks. In fact, in a lot of pure technical writing, you break the content into tiny, tiny pieces, chunks or some technical communicators talk about atoms of information, really tiny pieces.

And then once you've broken that down and said, "These are separate pieces," then you assemble them together in an order that makes sense. In fact, you can also do really cool stuff with content reuse in Confluence, using include macros and the new Excerpt Include Macro is very cool in cloud, because you can do new stuff with that. But it's really about breaking apart all your content, figuring out what's the order of all of this? What's most important? What's more specific? What is important for everyone? What's important for just a few people?

And then just going down like you would with an XML structure or any other sort of hierarchy and tier that information using your spaces, your pages, your headings. And then finally bullets and paragraphs and that kind of thing.

Henri Seymour:

Thanks for getting that generally explained. Is there anything you want to mention in your work at the moment that you would be interested in getting readers onto?

Matt Reiner:

Yeah, totally. A major new effort for me, because I'm just this content explorer, I guess. I've done like technical content, I've written some marketing content. I started speaking, which I enjoy speaking. I got to speak in front of one live audience before... No, I guess a few, and then, the world's shut down for good reason. Because when you're breathing out on a bunch of people, you want to make sure that you're not potentially putting them at risk. So been doing a lot of virtual speaking.

But recently, I mentioned, we've worked on all these best practices on Rock the Docs. And so we've started this video series about Confluence best practices and it's been very exciting to figure out, "Okay, so I know how to create fairly good in Confluence, how to structure that content. Now, can we make a good video?" And it turns out, no, not at first. Made some pretty poor ones or ones that just took way too much time to make. And finally, as you do with any kind of content, we finally got a good structure, a good rhythm. And we also found what are those things people really want to hear about?

And so we've developed 16 of these now on our YouTube channel that are just out there for administrators to share with your users who are asking these questions. Or maybe these are for users directly who just want to subscribe and get these things. But it's like eight minutes of just as much information as we can pack and still speak fairly legible English. And then show just like how do you do this in Confluence? Why would you do this in Confluence? What are the things you should consider in Confluence? What are the best ways to do things in Confluence?

We've actually just started a series of live streams as well, where we're trying to look at those more in depth and then have people live listening in, asking questions and directing the whole thing. So far those have been really great and we're looking to do more of that. So the more people who pile into those, the more direction y'all get to give that content. But it's been new types of content that it's exciting to see, okay, our good written content in Confluence is coming to the real world in a new format. Which has been cool and challenging and fun and scary all at the same time.

Henri Seymour:

Yeah. That's sounds like a really exciting project. Rock the Docs is going audio-visual. And I can-

Matt Reiner:

That's right.

Henri Seymour:

... figure what... Get users on there to give you that iterative feedback that we talked about at the beginning. And so is this worth the thumbs up? Do you have comments? What else can we do? And especially in that sort of live stream webinar format, you get that direct contact with your users so you can find out what they're needing. That's that's fantastic. Probably see if I can come along with those. Easy Agile started using Scroll Viewport for cloud specifically earlier this year.

Matt Reiner:

Oh, cool. Oh, cool.

Henri Seymour:

So that's been a major improvement for us actually.

Matt Reiner:

Oh, good. Yeah. I'm just loving what the cloud team is putting out. It's so exciting and so polished and it's just like every team has that documentation space, and Viewport, it lets you put it out there and you're like, "Ah, looks so great. We're so proud of it." You can read it on any device. It's just like it's the magic that everybody wants, but no team has time. Our very few teams have time to make it look that good, so it's nice to have Viewport just do the heavy lifting.

Henri Seymour:

We've got the Confluence space, we've got the documentation. We don't have to make a website about it. It's just, "Go ahead, please make this website happen. Here's what we need on it. Here's the structure." And golly, it looks a lot better now, even just aesthetically, it looks a lot nice in the house.

Matt Reiner:

Yes. And it's nice to know that like some designer peered over the spacing between navigation items to decide how spaced out they should be. And as a writer, I can just like, I don't have to care. I don't have to care. I can throw in Confluence macros and stuff, and they just look really great when they're published. And I don't know how or why, but I'm happy. I can just keep writing. Yeah.

Henri Seymour:

Yeah.

Matt Reiner:

It would be great to have someone from Easy Agile join us for one of those live streams. Because what we're really focusing on is just like great way to do things in Confluence. We haven't jumped into Jira yet. I'm not as much of an expert in Jira, but I have thought about it because that content doesn't really exist yet. But it's not necessarily app-focused or K15t app-focused. It's just like one of the best ways you've found to do certain things in Confluence, and we're just sharing those with people alive, and it's a lot of fun.

Henri Seymour:

Yeah, that sounds great. I've got the parallel of get really into Jira and making Jira apps and Confluence is, "Yeah, we've got a Wiki. This is where we write stuff down." And it is great to have stuff like "There's the visuals on our docs page." But I don't do those. I'm busy making visuals in a Jira app. I don't want to think about that spacing. I've got my own spacing to do.

Matt Reiner:

Yeah. Yeah.

Henri Seymour:

And it really is that, I can just do the writing, I can just do product. I can do my job more because this other stuff taken care of because the experts at K15t have made that happen. And I hope that our apps can do a similar thing for their users of, this is the thing we need, we don't have to think about this. Bring in this app and it will solve a problem for us. It'll help us see what we need to and organize our information in Jira. Which is a different type of information again, but.

Matt Reiner:

Yeah, yeah. It's funny. I've talked with some people who have actually described that whole app part of Confluence in Jira as App Hell. That's a term that I've seen and I can't help but love the community because we all come up with this stuff. But app hell is, it really comes out of not understanding what a platform is partially. For example, if you're using the Salesforce platform, yeah, that's going to be app hell if you really want Salesforce to be a marketing platform. Because Salesforce is a sales platform. But then there's apps, and Salesforce happens to a sell big one. And then all of a sudden it's a marketing platform.

So that is a really interesting perspective shift for people who are used to a tool that just does one thing. Everybody thinks Excel does everything. It doesn't, we really should just use it for spreadsheets, everybody. It's not a platform for other things. Confluence is really good at these core things, Jira is really good at these core things. And then these apps, they come in to answer the questions that don't have answers and do the things that can't be done. And that's why. So is it App Hell or is it App Heaven? That's the real question. Or maybe it's maybe it's App Purgatory, I don't know. I guess the listeners gets to decide.

Henri Seymour:

The constant stream of, and yet another app needs to update. Which to be fair, I think is not a problem on cloud at this point. That's an exclusively an on-premise problem, the constant app update cycle. But we are hopefully moving towards the end of the purgatory perhaps.

Matt Reiner:

Yes. Yes. I think we're all ascending together. We're just reaching new heights all at the same time.

Henri Seymour:

Is there anything else you'd like to bring up while we talking tech docs?

Matt Reiner:

I guess, I typically go back to when I was in university, I had a manager there who told us in this on campus job that I had, "Our job is to connect people with the resources that are already around them. You're not a teacher, you're just here to connect people." And that has really stuck with me. And that is essentially what we all do. Whether we're building a product that connects people with resources or that is the resource or we're contributing to documentation or some kind of content.

We're really trying to enable people to do that greater thing, that higher level thing that is above our content, it's above our product. It's that thing that they truly care about and any part we get to play and that greater thing, that better thing. That's what it's all about.

Henri Seymour:

Yeah, that's really great perspective. That's probably also a really great thing to round off the end of the podcast with.

Matt Reiner:

I guess so.

Henri Seymour:

Yeah. Thank you very much for joining us, Matt, and for talking all things technical documentation with us on the Easy Agile Podcast.

‍

‍