Easy Agile Podcast Ep.25 The Agile Manifesto with Jon Kern

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

"Great convo with Dave & Eric! Key takeaway: revamp Easy Agile's org structure representation. Exciting stuff!"

Nick Muldoon, Co-Founder and Co-CEO of Easy Agile, is joined by Dave West, CEO, and Eric Naiburg, COO, from Scrum.org.

In this episode, Nick, Dave, and Eric unpack the current agile landscape, discussing the role of the agile native and emphasizing the importance of building connected teams by flipping the hierarchy and putting leaders in supporting roles.

They emphasise the importance of empowering the people closest to the problem to make the call, and ultimately creating an environment for success to happen.

We hope you enjoy the episode!

Share your thoughts and questions on Twitter using the #easyagilepodcast and make sure to tag @EasyAgile.

Transcript:

Nick Muldoon:

Hi folks. Welcome to the Easy Agile Podcast. My name's Nick Muldoon. I'm the co-founder and co CEO at Easy Agile, and today I'm joined with two wonderful guests, Eric Naiburg, the Chief operating officer at scrum.org, and Dave West, the chief executive officer at scrum.org. Before we begin, I'd just like to acknowledge the traditional custodians of the land from which we broadcast today, the people of the Dharawal speaking country. We pay our respects to elders past, present, and emerging, and extend the same respect to all Aboriginal, Torres Strait Islander and First Nations people that are joining us today. So gentlemen, thank you so much for making some time. We really appreciate it.

Eric Naiburg:

Thank you.

Nick Muldoon:

I guess I'd love to just jump in and, Dave, I've got a question for you first and a follow on for you, Eric. I'd love to just get a quick assessment, Dave, of the Agile landscape today and I guess the shifts that you may have seen now that we're out of these COVID lockdowns, these back and forth, COVID lockdowns.

Dave West:

Yeah, it's interesting. So I've been the CEO almost eight years here at scrum.org, and it has changed a bit during those eight years. I think what we're seeing and is a, dare I say, the deployment phase, mass deployment of these Agile ways of working and this Agile mindset throughout industries and throughout all organizations. It's more than an IT software development thing. And I think that that was accelerated during COVID. What's interesting though is many of the characteristics of Agile that became so important during COVID, particularly around empowered teams, particularly around trust, particularly around the hierarchy and the reduction of hierarchy, some of those things are being challenged as we return to the new normal, which some people would rather was just the normal. So I am seeing some of that. However, generally Agile is here, it's here to stay. I think the reality is that most knowledge workers, particularly those knowledge workers dealing in complex work are going to be using some kind of Agile approach for the foreseeable future.

Nick Muldoon:

And last week you... Was it last week? I believe you were in Paris for the first face to face?

Dave West:

[foreign language 00:02:37] I was and it rained the entire time actually, Nick. So yeah, I spent a lot of time inside in Paris.

Nick Muldoon:

Well, what was the sentiment from the Scrum trainers there, from the conversations they're having?

Dave West:

Yeah, it was interesting. We talked a lot about at scale, enterprise adoption, the challenges. It is funny that the challenges are challenges that you expect, and most of them are about people, legacy systems, people status, power position. We talked a lot about the challenges that teams are getting in these large complicated organizations. That continues to be the conversation. There is, obviously, this is Europe, they're very close to Ukraine and the conflict there. So there's definitely some conversations about that. We have six Ukrainian trainers and also about the same number of Russian trainers as well. So that's always a conversation. And then there's a general downturn of the economy that was also being talked about.

Layoffs are happening throughout Europe, and particularly in the technology sector, but I think that's growing to some extent. Vodafone just announced today that they were laying off, it's about 6,000 employees, and they're one of the biggest telecommunication companies in Germany, for instance. So there was definitely some of that, but so if you add enterprise, you add conflict uncertainty, you add economic uncertainty, those three things will come together. But what was funny in it is that throughout all of this, they were incredibly upbeat and excited. And I think because they're talking to people that they've never spoken to before, they're talking to people about how Scrum is a natural way of working, talking about the challenges of empowered teams, empiricism, continuous improvement.

And I had some really exciting conversations with trainers who were like, Yeah, well we're doing this in this aerospace company or this electric car supplier in Germany or whatever, or this financial services startup that's using blockchain for the first time. And of course they're using Agile. And so it was funny. It was almost as though all of those things, though there were the backdrop, it was still incredibly positive.

Nick Muldoon:

So this is interesting, and I guess if I reflect on the background for both of you, Eric, I'm looking at, you two have worked together from rational days-

Eric Naiburg:

A few times.

Nick Muldoon:

... a few times, but the prevalence of the Agile... I would describe you two as Agile natives and it sounds like, Dave, you've got your tribe there in Paris last week that are Agile natives. And I guess Eric, for you, what's the sense around the people that you are interacting with from a leadership perspective in these companies? Can you identify the Agile natives? Yeah, I guess is it an easier conversation if you've got Agile natives in leadership levels?

Eric Naiburg:

It's definitely an easier conversation if they're there. Sometimes they're in hiding, sometimes they're not Agile natives masquerading as Agile natives as well, which always makes it a little bit difficult because you have to peel back that onion and peel through who are they and what's their real agenda. I was talking to a CIO last week, and he was talking about the typical CIO lasts two to three years. So what is their real agenda? What are they trying to achieve? And Dave mentioned the people part of this, and people often become the hardest part of any Agile transformation or working in an Agile way. People want to protect themselves, they want to protect their turf, they want to do the things that they need to do to be successful as well. So you see that as talking to leaders within organizations, and they want to do better, they want to improve, they want to deliver faster, but they've still got that pressure. Organizations, at least large organizations, haven't changed. They still have boards, and they still report to those boards, and those boards still have their agendas as well.

Nick Muldoon:

You're making me recall a conversation that I had, this is several years ago, but on a trip through Europe, and it was with the Agile native, that was the Agile practice lead and probably wasn't masking, probably was legitimately an Agile native, yet they were talking about the mixed incentives for their, maybe not their direct leader, but the VP further up. And it was actually a, I don't want to say a zero-sum game, but there was some kind of fiefdom thing going where the various VPs would fight for resources, people, whatever, because that would unlock further bonus. But at the end of the day, it was not optimizing the entire financial services company. Are we still seeing that today?

Dave West:

Oh, very much so. In fact, a colleague of ours says, "Science used to have a saying, science progresses one funeral at a time." And I think Agile definitely has some of that, not funerals hopefully, but retirements.

Nick Muldoon:

Retirements

Dave West:

Retirement.

Nick Muldoon:

Yeah.

Dave West:

Yeah. The reality is that when you don't have incentives aligned, where you don't have teams aligned to those incentives and leadership aligned to those consistent incentives, then you're going to always be dealing with some challenges. What's so frustrating is we all know the industrial revolution, and particularly the recent revolution of mass production and oil, which just happened in the deployment phase just after the second World War, was enabled by changing working practices created by people like Ford and Deming and all of these people. We all know that. The digital revolution is happening around us. It may even pass us if you believe the AI buzz that's happening. We may be put to the side and computers may just take over, but this digital is happening, and you are in with leaders and they're like, "Yeah, totally respect that. We are going to be a hundred percent digital. We are an airline, but really we are a digital company with wings."

They describe themselves in this way, and then they don't want to challenge the fundamentals of how authority, how value is managed, how risk is made transparent, how governance is, it happens, how funding is made and planning, et cetera. They don't want to challenge any of those assumptions. They like that the way it is. But we are going digital. It is ironic that it still is happening. However, that isn't totally hundred percent. The organizations that get it, the organizations that have leaders that are either insightful, either motivated, or maybe they want to write a book or something. Maybe their reasons aren't always as clear, but those leaders are dragging these organizations into the 21st century.

Great example. Proctor and Gamble, Gillette. Gillette, the latest exfoliating razor. I can see you haven't used it, unfortunately, Nick, with your rather handsome beard. So yeah. Anyway, I use it a lot, as you can tell. The exfo... Was built using Scrum and Agile. This is Proctor and Gamble, an ancient, okay not ancient, an older organization, but really has got it. They realize that if they want to keep up with their customers, their partners, their suppliers, they need to work in quite different ways. And so it isn't roses, but there are roses in the garden as it were.

Eric Naiburg:

And it goes beyond, when you think of that organization, you think of what Gillette has done, is it goes beyond traditional Agile thinking. Traditional Agile thinking, we think software, and this is engineering, this is manufacturing, this is bringing together marketing because in those types of organizations, marketing drives what the product's going to be, and then engineering figures out how to deliver that product and so on. So it's really bringing together the whole organization into how do we deliver something, and deliver it together. I think that's one of the big things that we're seeing. And one of the big changes that Agile helps to drive is that team. So you talked about incentives and team incentives, that's a piece of it, but it's team ownership. It's team togetherness.

It is that ultimately they all feel accountable, and bringing that accountability together as a team versus, and I think even... So my wife's in manufacturing and it's always... She's on the R and D side of it, and complaining about the marketing people. You have those conversations of, "Well, they don't realize what it takes to actually build this thing. They just have the dream." And by bringing them together in that team, and really they're having their daily scrums, they're planning together and they're having those hard conversations respectfully, that starts to build that team and build them in a way that they're able to actually deliver faster and more what the customer wants.

Dave West:

Can I just lean in, I'm sorry, we just taken over here a little Nick, but I just want to lean into something that Eric said around it is all about the teams. One of the fundamental problems we see in many organizations is hierarchy. Because if you get these massive hierarchies, obviously there's, "I've got to be in control of something. I need to take ownership of things. I need to be off irresponsible for certain things." That's how hierarchies work. And so that often undermines the ability of a team to effectively function. We need to flip that so that these hierarchies become, instead of being on top of the teams, they need to be underneath the teams supporting them. Think of them as those support trusses on bridges or whatever. You have some fabulous bridges in Australia and in Melbourne and in places like that and in Sydney.

So think of it upside down, holding up the teams. But that means, going back all again to incentives again, that those leaders need to understand what they're responsible for in this new world. And they're doing it for very good reason. They're doing it because the teams need to be, they're closer to the problem, they need to be empowered to make the decisions in real time based on the data, the information they have, they need to have clean line of sight to the customer. All of those things are the reason why a hierarchy is just too slow to respond and too bureaucratic. So we need to flip it and enable those teams. And that's a huge challenge.

Nick Muldoon:

I Love this. You two have given me something to ponder. So for the first six years of the company's life, of Easy Agile's life, we did have a very simple team page, and Dave and I as co-CEOs were at the bottom of the page. And then you had the leaders of the pillars. So you had, at the time, Tegan was the head of product, the leader, and they sat on top of Dave and I, and then the team sat on top of that. And it's interesting, I'm actually trying to reflect now, it's probably only in the last 12 or 18 months as we went through 40 people, that that page or that visualization has flipped. I've got an action item obviously to come out of this, thank you gentlemen, to actually go and flip it back because it's a communications mechanism, but if we actually put ourselves at the foundation in this supporting role for supporting the folks, that sets the tone, I imagine, for the team members in how they think of themselves and maybe that accountability piece as well, Eric.

Eric Naiburg:

Yeah. Yeah. That's interesting because sometimes it's those little things that change how people think and feel. I use a lot of sports analogies when I talk and meet with people, and especially with where Dave was talking of empowering the people closest to the problem. We have to do the same in sport. If we have to wait for the manager to tell us to pass the ball, it's never going to happen. We've got to allow the people to make decisions and make those decisions on the field. We need to apply that to business as well. Allow the people who are closest to the problem, closest to what's happening, make those decisions within the business as well.

Nick Muldoon:

So if we come back to Proctor and Gamble, and we don't have to rabbit hole on it, but they're one of the large, long-lived companies, and I don't know about their approach, in particular, but I think about GE, and GE had their internal training university program, and they were training their leaders, training their managers how to manage, training their leaders how to lead. How does a Proctor and Gamble go about shifting that conversation internally, and what's that timeframe? Because presumably you've start with someone that's on a team. Do you have to elevate them over time through the hierarchy of the company?

Dave West:

It is interesting. I'm fortunate to spend maybe because we're both British people living in Boston, I'm fortunate to spend quite a lot of time with, and there's videos on our site with this, by the way, interviews with Dave Ingram who runs R and D for male grooming, it's called, in the Gillette part of P and G. And the case study is out there. So I talked to him a lot about how you drive it in a huge organization where they've got everything to lose. They've got products that are amazing, they've innovated, those products are the products that you put into your shopping cart as you walk down the aisle. They don't want to muck that up. Let's be frank. If suddenly, because of some innovation, there's no razors on the shelves, then I, as a board man need a razor. So I will buy an alternate product, and it's possible that then I'll always buy that product.

So they've got to be very, very careful. They've got more to lose. So we talk a lot about how you manage change and it's all of the above. What he's done very smartly is he's empowered the product owner role or the person, the glue role, whether it's using Scrum or something else, and he's really invested in these change agents in his organization, and he's definitely led by doing, he's been very honest and open about that, and very clear that he doesn't have all the answers and he's looking for them to help him during this, which isn't perhaps what you'd expect from a traditional organization where-

Nick Muldoon:

The leader might need to feel that they have the answer to all of these questions.

Dave West:

Exactly. And he's done a really, really good job of doing that. And primarily because he says, "Well, my success is ultimately their success, so if I can make them be a little bit more successful, there's more of them than me, so let's make it work." Which I think is an unusually honest and very insightful view of it. So he's driven it predominantly through product management ownership areas. He's then provided a support environment around that. He's then definitely advertised the successes. He's spent a lot of time building cross-functional teams. The thing that Eric was talking about. And really been very careful working with their leadership. If you're material science, there's a whole department, if there's marketing, there's this whole channel thing that they have. Basically working with their leaders to create the environment for success to happen. And I don't think it's easy. I think there's many surprising roadblocks along the way, and I can't speak for him on this, but he's taken that divide and conquer approach, focusing on that catalyst role.

Nick Muldoon:

Because you, obviously, you're providing a lot of training for various, well, I guess people at various levels in these companies. And obviously it's a far cry from having a CST and a CSM and a CSPO certification going back a decade, decade and a half. What's the uptake around the leadership training? And what does that look like, Eric? Is there renewed interest in that at the moment or are people demanding more of that leadership training? Is it fit for purpose for today's leader?

Eric Naiburg:

So I think to a point it is. We're certainly seeing growth in the leadership training. Matter of fact, Dave and I were just looking at those numbers earlier this week or yesterday, I guess. Today's [inaudible 00:21:29]

Nick Muldoon:

Are there are any numbers you can share with us?

Eric Naiburg:

It's hard to share the exact numbers, but we're seeing double-digit growth in number of students taking our leadership classes. Both how do you measure, so our evidence-based management classes, as well as our leadership training, but that also only goes so far because a lot of those folks, depending on how high up, especially in the organization you go, aren't willing to take lots of time out to take such training. So a lot of it happens in that coaching. They're hiring the executive coaches or the Agile coaches that are in there. The scrum masters that are in there are actually working to help coach those folks. And a lot of it's less about the training and more about the mindset shifts. So if you look at our Agile leadership course, a large part of it is spent on getting people to think differently. And really some of it's hit you over the head type of activities, where it really helps to drive those points across of, "Wow, I need to think differently. I need to work differently. I need to treat people differently."

Nick Muldoon:

Differently.

Eric Naiburg:

It's that, and we're seeing good success with that because especially when that light bulb goes off for folks, and that light bulb that goes off saying, "Wow, this is different." We have some exercises in our classes that really get you thinking and get you... There's one, for example, where you're thinking you're doing the right thing for the customer, and you're thinking you're doing exactly right until it kills the customer, because you didn't necessarily think through the whole. It's, "Well, this is what the customer wanted, so we need to do it, but maybe I should have got together with the team and let the team make decisions." I'm going a little extreme, but-

Nick Muldoon:

No, I appreciate it.

Eric Naiburg:

... it's those sorts of things that we have to change. And a lot of what we do in the course is educate leaders on what those teams are going through, and what the individuals on those teams need, and the type of support that they need, not how do you manage those teams, not how do you manage those people. But how do you empower and enable those people to be successful?

Nick Muldoon:

I want to just rewind for a second, sorry.

Eric Naiburg:

Killing people.

Nick Muldoon:

It sounded like there's a friction point in actually getting these leaders to take the time out of the office to go and get some education.

Eric Naiburg:

There is, yes.

Nick Muldoon:

Is that correct?

Eric Naiburg:

Yeah.

Dave West:

It's incredibly hard if you're at a large organization, in particular, when your schedule is overlapping meetings continuously eight to nine hours a day for them to take that moment to step back. Everybody, I believe very strongly, Nick, that everybody needs to take time to invest in their own personal and professional development. And that time is not a waste. Ultimately it is an incredibly good investment.

Nick Muldoon:

Yes.

Dave West:

We know-

Nick Muldoon:

It's great ROI.

Dave West:

Totally. Even if it just resets you, even if you have that moment of clarity because of it. it's not a surprise that people like Bill Gates go on retreat every three to six months and he takes his big bag of books-

Nick Muldoon:

Books.

Dave West:

And he goes off grid for a few days just to reset. I think that that time is incredibly effective. But what's interesting is, we are under, in America in particular, and I'm sure it's true in Australia, it's certainly true in England, where I'm from, motion is more important than outcomes. It's all about the motions. If you look busy, you're not going to get fired. And I think to some extent we learned that in school. I don't know if your parents said to you or maybe you got your first job. I was working on a delicatessen counter at the co-op supermarket, and I remember there was an old worker there, turned to me, he goes, "Whatever you do, when the manager walks by," Mr. Short-

Nick Muldoon:

Look busy.

Dave West:

... was his name. And he was everything that name implies. "Mr. Short walks by, look like you're doing something, start cleaning something, otherwise he'll take you off and make you do provisions, and you don't want to dealing with that milk, it's rancid." And I remember that. Look busy. And I think we've got a lot in our culture. I try to take time every week. I book, for instance, my lunch hour, I book it and I always try to do something in it. I try to watch a TED talk, read something, just to clear your mind to think about something different. I think that time is incredibly important. However-

Nick Muldoon:

Get exposed to some new perspective, right?

Dave West:

Exactly. Even if it means, even if the stuff you're watching or whatever isn't that relevant necessarily. Sometimes that lack of relevance is exactly what you need because your mind does something.

Nick Muldoon:

A mental break.

Dave West:

Exactly. And however in corporate America, and I think that's corporate in general, that doesn't happen. People are overly leveraged, they're incredibly busy. They have to attend these meetings, otherwise their profile is diminished. And I think that's at the detriment of the organization and the company. Here's a question, Nick.

Nick Muldoon:

Yeah.

Dave West:

Who have you helped recently?

Nick Muldoon:

Who have I helped recently? I spend most of my time, and I get most of my energy out of coaching conversations with individuals. So on my [inaudible 00:27:35] profile, I've got futurist very high up, and so I love exploring what is your life and your career going to look like in five years time? They're the conversations that I really get jazzed by.

Dave West:

And that's what everybody... Who have you helped is more important than what have you done.

Nick Muldoon:

Yeah.

Dave West:

And I think you need to balance that.

Nick Muldoon:

I pulled up these stats because I thought you might find them interesting. We did a survey last year of a subset of our customers. And we had 423 teams. So it's not a huge sample size, but 423 teams. And the reason I think about it is because there's a lot of, what was the statistic here? So just to give you a sense, most common sprint duration is 14 or two week sprints. Most teams have six people that are involved. Fibonacci for story pointing, an estimation. 10% of these teams achieved what they set out to achieve at the start of the sprint. And so the teams, this 10% of teams, the subset, they did add work into their sprints, but teams that were unsuccessful, rolled work from sprint to sprint.

And so perhaps what it indicated to us is that there are teams that over commit and under deliver, and in fact 90% of them, 90% of the survey teams, it would appear that they over commit and under deliver. And then there are teams that are, maybe, leaving time, Dave, maybe for some education or some spare time in their two-week sprint. And they actually happen to pull on more work and they achieve that. And I'm just thinking about that from a sense of, are 90% of these teams trying to be busy or are they trying to be perceived to be busy? Even if it's at the expense of actually delivering?

Eric Naiburg:

Or are they even pushed into it? It's interesting, there's a question on our professional scrum master one, our PSM one test that often people get wrong. And I think it's a great question, which is, I'm paraphrasing because I don't remember it exactly, but it's essentially how much of the sprint backlog needs to be filled coming out of sprint planning. And a significant number of people say it needs to be complete coming out of sprint planning. Which goes in the face of Agile and Scrum.

Dave West:

Exactly.

Eric Naiburg:

Because we don't know there. There's that uncertainty. All we need is enough to get started, and once we get started, but I think people are fearful of, "Well, we've got two weeks, we need to be able to plan those two weeks and we better be able," and this is some of that top-down pressure that we talked about. "Well, we need to show that we've got two weeks worth of work here and that we're not sitting around, so let's fill it up." And those are some of the misnomers about Agile and Scrum. "Well, it's a two-week sprint, we need to plan two weeks." Well, no, we don't. We need to have a goal. Where are we going to get to? How we achieve it is going to take time because we're going to learn as we go. As a matter of fact, the scrum team that I'm on right now, we were running a three-week sprint, and two weeks in we've actually achieved our goal. And now we're able to build upon that goal. And we already delivered on that goal a week early, which is great.

Nick Muldoon:

Do you think, Eric, that there's a fear from leadership that if people haven't got two weeks worth of work teed up, that they're just going to be twiddling their thumbs?

Eric Naiburg:

I don't know that it's a fear from leadership. I think it's a perception that the workers have of what leadership is thinking. I think it's more that. And I think it's the, "Well, we said we've got two weeks," and they are going to ask us, management's going to say, "When will you deliver?" I don't know that we'll ever get away from that when will we deliver question, even though we continually try to get away from that answer. But they're going to ask it. So if they're going to ask it, I better be prepared, which means I better have a whole bunch of work laid out. And that just breaks everything that we teach. It breaks everything that we think in Agile.

And all I need in planning is I need a goal, and some idea of how I'm going to get there. And over time let's revisit it and let's continue to revisit it and go to it. But it amazes me how often that some of the answers to that question are, you have a full sprint backlog go coming out of sprint planning, you have enough to get started. I forget what some of the others are. But it amazes me how many times when I review tests people put the full back sprint backlog where it even says, right in the scrum guide, "You're going to inspect and adapt throughout the sprint." Well, how do I inspect and adapt if I've already decided what I'm going to do?

Nick Muldoon:

Who's the onus on? If it's not actually the leadership's wish that you fill up all your time and you operate at a hundred percent capacity, then is the onus on the leader to make it known or is the onus on the team to engage in the conversation?

Dave West:

It's the leader.

Eric Naiburg:

Yes.

Nick Muldoon:

Yeah. Yes, both. Yeah.

Dave West:

I think it's more the leader because I think they have to create the environment where the team actually can challenge it, and actually have that very clear conversation. What worries me about your stan is the fact that I don't... The first few sprints. Yes, maybe you get overly excited, maybe you fill the sprint, which you don't need to. Maybe you're just keen. That's okay. The thing is, what happens on sprint three or four or five, when the same pattern is manifesting itself over and over again. That's worrying. And I think that speaks really clearly to the lack of help the team's having. Whether you call it an Agile coach, and in Australia, I think the Agile manager is a phrase that's used, or whether it's an Agile, or whether it's a scrum master, whatever. Scrum.org has a scrum master.

And the reason why we have a scrum master isn't because we don't know scrum, though there's some days it might be questionable. But cobbler's children, all that stuff. But the reality is, we do know Scrum, we talk it, we breathe it, we love it. But having somebody that steps back and says, "Hang on, Westy, what have you done there? Have you forced encouraged the team to fill the sprint? Have you set them an unrealistic goal? Have you listened to them and asked them the questions? Or have you told them what you want? And what do you think that's going to do?" I know that I have, because Eric and I fund the sprints, as it were. When we go to a sprint review and we say stuff, because a sprint review is ultimately there to provide feedback to the team, to allow them to inspect and adapt for the next sprint.

You can't change the past, but you can change the future based on feedback. If I go in with, "Oh, well that's rubbish and you should do this, and what about that?" Yeah, it's going to have an impact. So ultimately we have to think about, as leaders, what we bring, and also have somebody often helping us to be the leader that we need to be because we get excited and we get enthusiastic and we get, "Oh, you can do this and that? Let's do it. That sounds awesome." And sometimes that can...

Eric Naiburg:

And that's part of why I say it's both. That's why I said the yes. It's on the leader, but the leader needs to be reminded of that. The leader needs to be supported by that, especially by the product owner and the scrum master. The product owner has to be able to say no. The product owner has to... I talk about happy ears and most CEOs and senior leaders are-

Nick Muldoon:

Happy ears?

Eric Naiburg:

Yeas. Most CEOs and senior leaders I've worked with have what I call happy ears. They come from one customer or they talk to one person and heard something that-

Dave West:

Do this.

Eric Naiburg:

... that one person might have thought was great. And next thing you know, they're putting all these new requirements on the team. And I've worked in many startups and big companies where, even at IBM, that happened. And the product owner needs to be able to say, "Whoa, hold on. That's a great idea. Let's think about it. And we'll put it on the backlog, we'll think about it later. But let's not distract the team right now from what we're trying to do and what we're trying to achieve." And that's why I say it's both. It's not just on the leader. You're not going to fully change the leader. You're not going to fully change them to not have those exciting moments. And that's what makes them entrepreneurs. That's what makes them who they are.

But the team needs to be able to push back. The leader needs to be accepting of that pushback and the scrum master and the product owner, as well as others on the team, need to be able to have that pushback. I remember very, very early in my career, I worked for a company called Logicworks. We had a data model, a little data modeling tool called Irwin. And I remember sitting in my cube, and the CEO had just come back from a meeting with one client, and comes over, and I was a product manager-

Nick Muldoon:

Eric, do this.

Eric Naiburg:

And starts talking about, we need to go do this now, and blah, blah, blah, blah, blah. It's like, well, hold on. It's like, but blah, blah, blah said they'd buy it. Well one, did you actually talk to the people using it? Or did you talk to somebody way up here who has no idea how they're actually using the tool? Which the answer was talking to CEO to CEO conversation. And just because they'll buy it, will anybody? But you have to be able to have those conversations. You have to build that trust with the leader from the team, and from the team to the leader, to be able to have those pushbacks and be able to say, "That's an interesting idea. We'll take it under consideration for the future, but right now we have a focus. We've got a sprint goal and we're not going to destroy our sprint goal because you got excited about something."

Dave West:

As you can see, Nick, I have a really hard time getting any of my ideas into our organization because they ask things like this. So annoying, Nick. They say, "Okay, that's great. Is that more important than these five things that are currently driving our product goal?" I'm like, "Ugh, what do you mean? I can't have dessert and main course and an appetizer? I have to pick one that's just so not fair." And they said, "Well, we could spin up another team and then that requires investment. It's going to take time." And I'm like, "Oh gosh, don't you hate it when you have intelligent, smart teammates?" It's just hard.

Nick Muldoon:

Dave and I have definitely, so Dave Elkin, my co-founder, he comes from an engineering background and I come from a product background. And we've definitely noticed in the last, again, probably in this timeframe, in the last 18 months, as the team's grown or through a certain inflection point, in the past, we would quite come comfortably have conversations about what about this idea and how about that? And we'd try and tease things out, and we'd tease them out with the team, but there was no expectation that that stuff would get picked up. And then we had few examples where teams would go and take on and think that they needed to look at this stuff and we're like, "Oh, no, no, no, sorry, we should clarify that we just wanted to get a brainstorm or we wanted to get a thought out of our head, and we wanted some perspective on it, but this should absolutely not mean that you should chase it down." And so the language and how we've had to approach things like that, or activities like that, has certainly changed.

Eric Naiburg:

I've seen that a lot lately-

Nick Muldoon:

[inaudible 00:39:50] Inflection point.

Eric Naiburg:

... probably in the last two or so years. And I think maybe because of remote, it's made it even worse, because you don't get all the emotion and things. But I've definitely seen a lot more of that, of, "Well, I'm just," I've been told this doesn't translate, "but I'm just spit balling and I'm just throwing an idea out there just to have a conversation." And because the leader said it, people think it's fact and that they want to do it. And all they were doing is, "Hey, I heard this thing. What do you think?"

Nick Muldoon:

What's your perspective?

Eric Naiburg:

Yeah, exactly. And I think as leaders, we have to be very careful to understand the impact of what we're saying, because we may be thinking of it as, "I'm just throwing it out there for some conversation." Somebody sitting at the desk just heard, "Oh, they want us to go do that." And I've seen that a lot in companies recently, including in ours, where the way something's said or what is said is taken on as we must do this versus, "Hey, here's an idea, something to noodle on it." So you're not alone, Nick.

Nick Muldoon:

I love it. Hey, Eric, Oregon, that's a great place to call it. That is, and you have given me, you've both given me a lot to noodle on, so I'd like to say thank you so much from our listeners and from the crew at Easy Agile for joining us today. I really appreciate it. It's been wonderful having you on the podcast.

Dave West:

Well, thank you for inviting us. We're really grateful to be here, and hopefully some of this has made sense, and yeah, let's continue to grow as a community and as a world working in this way, because I think we've got a lot of problems to solve. I think the way we do that is people working effectively in empowered ways. So let's change the world, man.

Nick Muldoon:

I love it. Okay, that's great. 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.

‍

‍