Easy Agile Podcast Ep.3 Melissa Reeve, VP Marketing at Scaled Agile

Transcript:

Sean Blake:

Hello, everybody. I'm Sean Blake, the host of this episode of the Easy Agile podcast. I'm also Head of Marketing at Easy Agile, where our mission is to help teams around the world work better together. We have a fascinating guest with us today. It's John Turley from Adaptavist. John is a pragmatic Agile leader with 25 years experience working in companies at all levels, from teams to C suite, always bringing real value, adding change to the way organizations work. Dissatisfied with the standard discourse around transformation and agility, he is passionate about applying cutting edge knowledge from fields as diverse as sociology and psychology. We're really excited to have John on the podcast today. So John, thanks so much for being on the Easy Agile podcast.

John Turley:

You're welcome, Sean. Pleasure to be here.

Sean Blake:

Thank you so much. So John, you've got a lot of experience in the Agile space, in the tech space. And I'm not trying to call you old. But I'd love to get a sense of what's changed over 25 years. It must just be night and day from where you started to what you see now.

John Turley:

There's a lot of change. And I'm pretty comfortable with old. I'm 48 now, and it's closest to 30 years now. That tells you when I first wrote that bit in the bio. So the technology has changed. That's mind blowing. I started off in ops, and then infrastructure and project management and stuff and 1999, 2000, it would take us three months and 50,000 quid to build a couple of web servers with a pair of load balancers and firewalls and a database at the back. And now we spin them up in seconds.

John Turley:

This is profound. Platform technology is profound slack or I mean platform technologies, that makes a massive difference to the way we interact. Scale is a massive issue. I would say that the world is sort of dichotomized into very large and quite small organizations. There seem to be less in the middle. It's just a gut feeling. We see, I think trust is collapsed. We see that in Edelman Trust Barometer. We see the complexity has increased. That's deeply problematic for us. [inaudible 00:02:23] has been measuring that one.

John Turley:

And we see that workforce engagement is at all time lows through the Gallup World Poll. Those things are big, big changes. What's the same though is the people, the way the people think, the way we construct our reality, our mindset, if you like, the way we make sense of the world around us is very, very similar. So although we now talk a lot more about Agile, the waterfall and waterfall for many is a bit of a dirty word, not for me and same with command and control. People are taking the same mindsets. This is measurable and provable. People are taking the same mindset that they had around waterfall and command and control using different language of Agile and behaving in the same way. That hasn't changed.

Sean Blake:

Very interesting. So you touched on trust, and how basically we've seen this breakdown of trust across the board. And I've just watched a documentary that's come out on Netflix around the Social Dilemma, and how the trust that we have in these big social media platforms is eroding. And we're getting a little bit skeptical around what these big companies are doing to us as the customer. Do you find that that's a hard balance with the people that you work with around being customer focused, but still building a profitable and growing business?

John Turley:

Yeah, I do. Yes, and the way I think it manifests itself, which again maybe we'll get into the sort of the psychology and the sociology as well as the complexity science, I'm into it later. But there's a very clear way that that lack of trust manifests itself. I'm not sure it's the lack of trust that manifests itself. But there's a very clear thing that's happening is people, there's repeated patterns of behavior I see all over the place in a lot of the work I do, which is one on one and with groups, that people hold on to this idea that their view is right and anything that doesn't comply with that is wrong.

John Turley:

This is a view that comes from the predominant mindset from what [inaudible 00:04:33] call the sort of expert or the achiever mindset, and it becomes a barrier to us collaborating and learning together and innovating. If somebody with a different point of view is dismissed as wrong, then there's no common ground to start to build trust. Trust is eroded from the outset, and that means that we can't collaborate, and in a complex world where we need to collaborate ever more closely and learn together and innovate, that's a deep, deep problem.

John Turley:

And the response seems to be that people actually withdraw, they withdraw into groups, we might call them cliques or echo chambers. The sociologists call this process homophily. This is a function like many say of platforms like Twitter, we retreat into groups that echo the opinions that we already hold that then reinforce those opinions, and separate us from the opinions of others and reinforce the opinions we have. So the gaps between the cliques grow wider, and particularly in times of COVID and the lockdown that we've had here, and that we seem to be maybe heading back into the isolation perhaps adds to that, and we see it more and more. So at a time where we need to be getting our act cliques and talking with understanding with others with different views, we're actually psychologically in a difficult position to be able to do that. And so that's what we might generically call the lack of trust manifests itself in the work that I'm doing. And that's how I see it with almost everybody that I work with, including myself, by the way. It's not an easy thing to conquer.

Sean Blake:

So what does your day to day look like, John? I think your official job title is Digital Transformation Consultant. You work for Adaptivist as one of the most well known Agile consulting practices in the world, I would say. What does that mean for you day to day? What does your nine to five look like?

John Turley:

So we're really involved in three things. I'm really involved in three things. And it's all about learning, collective learning, organization learning. So we're involved in a lot of original research. We do that original research with a number of academic partners in a program that we're putting together. We've been doing a lot of the research on our own. But as it gets bigger and more credible, other partners are coming to join us and they're very credible partners.

John Turley:

And the research is uncovering new learning. And that new learning points us to new consulting practices where we can take that learning and embed it into a workshop, say or how we might use the research instruments that we've borrowed from academia in the real world to measure social networks or psychological complexity or the amount of autonomy in the environment. So we can then use that to work with teams to help them shift from a sort of functionally oriented way of working to a cross functional way of working, which whether we're talking about safe and Agile release chains, or whether we're talking about Lean software management and value streams, whether we're talking at a team level or an organizational level, the challenge is essentially the same. We need to orientate ourselves around the creation of customer value in cross functional teams that are focused on delivering that value, not just delivering on their function. And that switch brings with it some deep, complex, deep psychological challenges that we're just not really equipped to meet. So we bring sort of the people and culture element, the tools and the Agile methodology simultaneously to bear in teams to help them make that shift. So that's really what my day to day work looks like, so the research and the practice.

Sean Blake:

Okay, research and practice. And when it comes to the practice side and encouraging that cross functional collaboration, how hard is it for people to get on board with that recommendation or get on board with what the company is trying to do?

John Turley:

For most people, it's really hard. So my experience before doing the research that I guess we started a couple of years ago I was just referring to, was something like this recently. We'd often get, so I've worked in the Agile space for a long time, I don't quite know when I started working in that space, in other words, full space, but a decade or two, let's say, and now bumped into a repeated problem, we get our, let's say, thinking of a specific example with a specific client about three years ago, very functionally orientated, trying to make that shift into cross functional teams. So we got a group of five people together from different functions, so designers, testers, developers, a couple of ops people, and between them, they should be able to obviously, launch some working code within 10 days or whatever. We were probably trying to spring into the real world.

John Turley:

And they were all great people. I knew them all personally. I spent time working with them all. They were very sort of Agile in the way they approached the development of the software that they did, and we put them in a room virtually to begin with and we asked them to produce a piece of code that works across functions, produce a piece of code and release it at the end of the week. And they didn't. And we thought what on earth happened there? We didn't really understand this, so we tried it again. But we assumed that the problem is because we'd done it virtually.

John Turley:

So this time, we got everybody together in Poland, as it happened in a room, we set it all up, we talked to them at the beginning, then people like me sort of left the room and let them get on with it, got to the end of the week, same outcome, nothing has happened. And if you talk to them, while they say, "Yeah, my phone pinged and there was a support incident, and you just couldn't.", and they had lots of very plausible reasons why they couldn't come together as a cross functional team. But the fact remains twice in a row, the most capable people haven't done it.

John Turley:

So we had a really long think about it, one of the senior leader in the business and myself. And we realized that the only thing that could be happening, the only thing that could be going wrong here is that there must be some sort of breakdown in the dialogue between the group in the room. So we ran it, we ran the workshop, let's call it for a third time. And this time, we had somebody else in the room just watching what was going on.

John Turley:

And they spotted something happened really early on. One of the people from the UK said to one of the Polish developers, they said, "Look, think of us like consultants. We're here to help you, to transfer knowledge to you so that you develop a capability so that you can do this on your own." And at that moment, the person who was in the room said that the dynamic in the room seemed to change. People glazed over. And I think what it was is that that word consultant that the English person had used had a different meaning for a colleague in Krakow. I think that meaning, the meaning of consultant meant, we're just here to tell you what to do and not actually do anything and put ourselves on the hook for any work, just kind of watch you do it.

John Turley:

And I think at that point, they kind of went, "Okay, well, all right, I get it, same old, same old. We'll do the work you English guys talk about it, because it's an English company.", and that breakdown started to occur. So the question we started is, I've seen that all over the place. So the question we started to wrestle with in our research is what's happening in those moments when that dialogue breaks down what's happening?

John Turley:

And what we've discovered is that there is a number of research studies, the biggest is about 10,000 people, that shows that around about 50% of people are at a level, and this is 50% of leaders in a study of 10,000, so for middle management, senior management, so it's a skewed number. So in reality, in software teams, it's probably more than 50% of people have reached a level of psychological complexity that suits the environment as it was, but has some limitations in cross functional working.

John Turley:

So they have a mindset, a way of making their reality that works well in a functional environment, but it's challenged in a cross functional environment. And that mindset, this way of thinking, which is very prevalent, is a way of thinking where individuals draw their self esteem from their expertise, just to put it very short, simple as an oversimplification. And the thing is, if you're drawing your self esteem from your expertise, when your expertise is challenged, it feels personal.

John Turley:

If it feels personal, people are likely to get defensive. And it's not because they're stupid, or they're not interested or they don't want to, the psychologists can show it's a level of psychological complexity, where that's just how our minds work. That's just how our meaning making works. Now, if that's the stage you're at, if we imagine me as a developer sitting down with a tester, and the tester's saying to me, "Look, the way you've written the code isn't the best way to do it for me, because I can't test it."

John Turley:

If I'm drawing my self esteem from my expertise as a developer, I'm likely to reject that, and might even start to think thoughts like, "Well, I think what really needs to happen here is that you need to be a better tester." I think that's the problem. And then we get this separation. Now at the next stage is psychological complexity. And these stages are in a framework that we do move through these stages. Again, it's an oversimplification, but it's observable and measurable. At slightly later stage of psychological complexity, things start to change. People start to recognize that the world is much more complex, that it's not black and white. And actually, there are multiple ways of doing things.

John Turley:

So to go back to my example as a developer, the tester might say to me, "This isn't the best way to write the code as far as I'm concerned." And what I'll hear is the, "Oh, as far as I'm concerned." It might be as far as I'm concerned, it's not fair enough. How can we change the way I'm writing the code to make it easier to test? But I can't do that if I respond like it's a personal criticism, you know what I mean? So what we started to uncover in the research is a correlation between how successful cross functional teams can be, and the level of psychological complexity in the leaders and the individuals in that team.

Sean Blake:

Interesting. So there's a book that we've been reading at Easy Agile recently called Radical Candor. And really, it comes down to giving constructive feedback to each other, not in a way where you're attacking them personally but you're trying to be honest around how we can work more collaboratively. And like you said with that example, how can a developer write code in a way that the QA tester can actually perform the tests on it? For someone who's new to cross functional ways of working, what advice does the research have around preparing that mindset to receive some of that radical candor, to receive that feedback in a way that you don't take it personally?

John Turley:

Well, so it's a great question, you put it really well, because radical candor is fine. We have, I work in a team that is very candid. We have some difficult conversations, and we don't even really dress our words up. And nobody gets offended. We just know that it's a shortcut. We might get our words wrong, but it's a shortcut to unlocking value to finding out how to work together. But it's not about the words that each of us picks to express. It's about how the other chooses to react to the words landing, as much as now that's a dialogue, it's a two way thing, it takes two to tango.

John Turley:

And the way we can develop a mindset that's more suitable to cross functional work is interesting. First of all, we've got to get out of comfort zone. We've got to be prepared to get out of our comfort zone, not far necessarily, and not for very long necessarily, and not without support and understanding from the colleagues around us. But we do need to get out our comfort zone. Otherwise, psychological growth can't occur. This is what I'm talking to about now is the work really of Robert Kegan and Lisa Lahey, who do a lot of work in dialogue on radical candor.

John Turley:

So we've got to get out of our comfort zone. But we've also got to be addressing a complex problem with a group of people when we're outside of our comfort zone. And that complex problem has to be meaningful, and it has to be salient, it has to be something that we care about, it has to be something relevant to our day to day work. And if we've got those characteristics in the environment that we working in, then there is an opportunity for individuals to choose to develop their own psychological complexity.

John Turley:

So that environment that has those characteristics, we would call in Kegan's word a deliberately developmental environment, because we can't separate the development of individual mindsets from the environment that that mindset functions in. The reason most of us have got the mindset that draws self esteem from expertise is because that's actually what most environments that we work in or not. That works in a functional environment. It's where you get promoted, it's where you get hired. It's where you get your Scrum Master badge and all that other stuff that gives you status and makes you feel good.

John Turley:

The world that we work in for many of us honors that expert way of making meaning. It doesn't honor learning and admission that yours might not be the best way to do things in the same way. So we have to shift the environment to support the individual to choose to take that developmental step because it can't be something that's done to them. You can't make people develop a more complex psychology. You can't train them to do it. You can only give them an environment that supports that step if they want to take it and if they don't, fair enough, that's okay. But maybe cross functional teams for them, if they don't want to because the hard place is to work.

Sean Blake:

Is it a problem that people find their expertise or find their self esteem from expertise? Is part of it encouraging men to find their confidence in things outside of their work or is expertise an honorable pursuit?

John Turley:

I wouldn't say it's a problem at all. Expertise, and the development of expertise is an honorable pursuit. Drawing your self esteem from your expertise is a very necessary part of our psychological development is a stage that can't be skipped really. I said to you before that I don't like to say things like that without the research base, but the psychology certainly imply that it's a stage that can't be skipped. So we've got to do it. We've got to go through this stage. The stage before we're drawing our self esteem from our expertise is where we draw our self esteem from our membership of the group.

John Turley:

And that's very important too, if you think of us as children or being part of a group is essential for our survival, so ingratiating yourself into that group, not rocking the boat, so we don't jeopardize our group membership is critical. But at some point, people start to realize, well, actually, I have to rock the boat a little bit if we want some direction. So separating your meaning making from drawing your self esteem from the group to drawing your self esteem from your expertise is a development in that sense. Drawing your self esteem from your expertise means the best way to write this code is let me train somebody to do it.

John Turley:

It's critical. But like all developmental stages, it has its limitations. So it's not problematic in any way, unless the individual is in a complex environment in which that expert way of making meaning isn't well suited. And then you got a mismatch between psychological complexity and environmental complexity. And when you've got a mismatch like that, the individual's anxiety will go up probably, employee engagement goes down, certainly wellbeing goes down, people revert to an earlier way of making their meaning that's more embedded in their expertise or the group, just to the point, they need to get more sophisticated.

John Turley:

So the problem is the mismatch between psychological complexity and environmental complexity. That's why we need to support, as the world gets more complex, that's why we need to get all get better at supporting the development of individuals into a level of psychological complexity that suits the more complex environment. That's kind of the nub of the problem. Nothing wrong with being an expert in drawing your self esteem from your expertise. People have done it forever, and will continue to do so. Every time you get in a flash car and you feel good, because you're in a car, you're drawing your self esteem from the status symbol, which is very similar to your expertise. As a young man, I put on my sharp suit and I feel a million dollars. Nothing wrong with that at all, but it's limited. That's the problem.

Sean Blake:

Understood, understood. So you've spoken about research and measurement and having an evidence based way of making decisions. When it comes to this cross functional way of working or digital transformation or teams moving from the old way of working to an Agile way of working, do we have evidence to say one way of working is superior to another way of working? And when you're talking to these clients or these customers, can you guarantee that if they work in this way, it's going to lead to better outcomes for the business? How do you approach that conversation?

John Turley:

No, I can't do either of those things. So I would never go anywhere near nor would I research saying that one way of working is better than another way of working or we can say like the mindset and the environment that there are ways of working that will work better depending on the problem that you're trying to solve. But it's very unlikely that one could be considered right and the other wrong in all sorts of circumstances, but more than that, I would say that doesn't matter what your way of working is or a team's way of working is. If the mindset is the way of making sense, if the reality doesn't also shift, then you're just following a new process, a new way of working with the old way of thinking, and you're going to get the same results just with different words.

John Turley:

So for me, that isn't entirely true, I'm quite biased. I guess in the work I do, I've got quite a perspective. If you shift mindset, then everything else will drop into place. If you change everything else, but don't shift mindset, nothing else will drop into place. What we can say however, is that there are three things, let's call them the three elements of a cross functional team that are hidden to people in organizations at the moment.

John Turley:

So generally, we think if we've got people with the right experience and skills working suitably hard, then they're going to work as a successful cross functional team. And if they're not, they're either not working hard, they're not the right type of person, or they haven't got the right set of skills, so fire them and hire somebody else or give them or put them on a training course, and that solves the problem, which of course it doesn't.

John Turley:

We would say that there are three other elements that remain hidden parts of the cross functional team that are more critical than that, and we're beginning to be able to demonstrate that there is a correlation between these three things that I'm going to tell you about on both employee engagement and team performance.

John Turley:

And these three hidden elements are the structure of the social networks that underpin the way people work. So if we think about how we as groups of human beings organize ourselves, we might think about hierarchies and hierarchy diagrams and old charts and bosses and stuff. That's not really very important for a cross functional team. What's much more important is the social network that develops across that team, who works with whom and when and how, right? Do the developers and the testers and the testers and the ops guys and the designers and the technical architects, do they all work together in a cross functional team?

John Turley:

Now that's a social network. That's a network that's formed through individual autonomy because they want to get the job done not because the boss says you've got to go and do it. In fact, it can't be done because the boss says go and do it. So we have worked with some friends in academia with actually an Australian company called Polinode to measure their various ways we can get the data, what those social networks look like. And the structure of those social networks is key.

John Turley:

As we look at the structure of social networks, we can see whether those teams look like their function, sorry, organized hierarchically, or were they organized for cross functional working because of the network structure. So network structure is one element. The other is psychological complexity. So we've worked with a gentleman called David Rook, who did the original research and developed a psychometric instrument that can measure an individual's stage of psychological complexity, both the structure and the substructure. And that mindset complexity is also linked along with network structure to where the teams can function cross functionally.

John Turley:

The third thing that was the hardest bit, the last bit of the jigsaw that we sort of put into our hypothesis is we need to have adequate degrees of autonomy. We needed to develop a much better understanding of what it means for teams to be autonomous than we had, and how that autonomy relates to control and how control undermines autonomy and how we all tend to be orientated, to taking the cues in the environment either as instructions, which we must comply with or invitations to be autonomous. And we now have another psychometric instrument. So the third instrument that we use, we call the motivation orientation scale, excuse me, that can measure an individual's likelihood to interpret inbound information as an instruction or an invitation to be autonomous.

John Turley:

And once we know that, we can start to challenge this common perception within product teams, software teams that the team is autonomous, because everybody thinks they are autonomous. And in fact, everybody is, research shows mostly autonomous, but we might be almost entirely autonomous, or we might be 60% autonomous. We can measure this. And then we can say to teams, "Look, you are autonomous as a bunch of individuals. But you also have this control thing going on where you're responding to inbound requests."

John Turley:

And we need to be more autonomous. So once we can start to measure it, we can start to challenge their ideas of how autonomous they are. And we can start to examine where the teams are choosing to respond from that control orientation or their autonomy. So they're the three things, autonomy and control, complexity of mindset and network structure, equal employee engagement and team performance. That's what our research says. So what we can say is, to your question in the beginning, there is a network structure, a level of psychological complexity and the amount of autonomy that correlates to successfully working as a cross functional team. And in that sense, we might think that those levels are right, in some sense.

Sean Blake:

Okay. So what does a 100% autonomous team look like? And do they still have interaction with, say the executive team on a day to day basis? Or are they at odds, those two concepts?

John Turley:

No, they're not at odds. They do have, they might have day to day, I suppose they would, they will have either directly or indirectly interactions with the executive team. So the first thing we need to bear in mind here is that the research that we're leaning on is something called self determination theory, which is a theory of motivation. And it has quite a specific definition of autonomy, which is not what we might normally think. Often autonomy is taken to mean as sort of the general use of independence. So if we buy a company, we might leave it to run autonomously, which would mean we just left it alone for a while. And autonomy in this context doesn't mean that. It means individuals acting of their own volition, individuals deciding how to act towards a common purpose. So the team has to have the vision which they can self organize around. You can't self organize without autonomy. If you don't got autonomy, you have to wait to be told what to do. And then it's not self organization.

John Turley:

So autonomy leads to self organization, and self organization can be around a common vision or a set of goals or an OKR is quite a sophisticated way to do instead of management by objective, then we can self organize in a way that sort of honors the need to be part of an organization, doing some coordinated work, but that doesn't rely on a manager telling the individual what to do.

John Turley:

That's what an autonomous team looks like. An autonomous team, you need the autonomy is really a self organizing team. And the self organizing team is deciding what the team ought to do in order to achieve a wider objective, which could be integrating with other self organizing teams. And obviously, the direction is set often by the executive. So all these things sort of come into play. It's not a question of control on the one hand or autonomy on the other or Agile on one hand or waterfall on the other.

John Turley:

So we're going to blend the two. We're going to balance them. And that balance needs to shift not only across teams, but also depending on the level that the organization is, that the team is working in the organization. And what I mean by that is the need for control and measurement increases in many ways as you go higher up the organization. So we want high degrees of autonomy at a team level where we're creating customer value. But we need to recognize that that self organizing team has a legitimate requirement to integrate with some elements of controlling the organization, because if we have some elements of control, then we can't do the accounting and be accountable for where we spend investors' or shareholders' money, you know what I mean? So it's much more complex in the sort of the dichotomized world that people tend to look at, which is very black and white. Is it Agile or is it waterfall? Are we autonomous or are we control orientated where you're both and the blend of which needs to shift depending on the environment here.

Sean Blake:

Okay, okay. So there's always a need for a bit of control on top of the autonomy.

John Turley:

It's a balance, right? We're all comfortable with control, aren't we? We all comply with speed limits, for example. We're perfectly okay with that. Control is not a dirty word. Some will do things that we're told to do sometimes, and we're happy to do it. Sometimes we do it begrudgingly. We're not happy to do it. Sometimes we reject it. There's nothing wrong with control in itself. It's the overuse of control to coerce people to do things that they don't want to do. That's when it becomes problematic because it undermines an individual's autonomy, which is a basic, universal psychological need. We all need to have a sufficient degree of autonomy to feel well.

Sean Blake:

Okay. Okay. So we know that Agile's had a good run, it's been decades now. So do you still find that you come across the same objections when you're speaking to these executive teams or these companies perhaps from more traditional industries? Do they still have the same objections to change as they did in the past? And how do you try and overcome them?

John Turley:

Yes, they do. So one of my strange experiences as a young project or program manager, whatever I was, is that when I would end up in a room full of software developers who were Agile, probably the language they would have used at the time and a bunch of infrastructure engineers who followed waterfall, and the distaste for one group for the other, it was almost visceral, and you could see it in them. There would be a bunch in, I don't know, Linux t-shirts and jeans, and then the infrastructure waterfall people would probably be wearing suits.

John Turley:

I mean, it was really obvious, and it was hard to bring these groups together. That was my experience in let's say, around about 2000, I sat with a client yesterday, who said exactly the same thing. They said that in their organization, which is going through a very large, Agile transformation at the moment, they said, "These are their ways. We kind of got people at the two extremes. We can sort of bookend it. We've got the waterfall people who think their way is best and we got the Agile people who are totally on board with Agile transformation."

John Turley:

And what I heard when the individual said that is quite senior leaders, the Agile people are on board with the Agile transformation brackets because they think their way of working is best. And what I tried to point out to that senior manager was that that was one group, there were perceptions anyway, that one group was into Agile and got cross functional working, all that got cross functional working and the other group didn't, actually the two groups were operating in the same way.

John Turley:

They both thought their way of working was right, and one was espousing the virtues of waterfall and the other Agile, but the fact was they both thought that they were right, and the other was wrong. And they were both wrong in that. Waterfall works really, really well in a lot of scenarios. And full on Agile works really, really well in some environments. In some environments, it's quite limited by the way, in my opinion.

John Turley:

My friend and colleague, John Kern, who was a co author of the Agile Manifesto in 2001 or 2004, whatever it was, I can't remember. He says, "I love waterfall. I do loads of waterfall, I just do it in very small chunks." And because the fact is we've got to do work sequentially in some manner. I can't work on an infinite number of things in parallel. There has to be a sequence.

John Turley:

And that really, when I heard him say that, it sort of filled my heart with joy in a way because for somebody with a waterfall background, I used to say, "Look, I don't get this. In waterfall project management, we're talking about stages. And in Agile, we're talking about sprints." And they've both got an end. One's got a definition of done. And one's got some acceptance criteria, and they both got a beginning. The only difference is the language and the duration.

John Turley:

So what if we make sprints, sorry, stages 10 days long? What's the difference now? And yet people would say, "Well, we're Agile, and we do sprints, and that would still be a stage." Come on, we've got to find some common ground right to build a common meaning making between large groups of people. Otherwise, only the Agile listeners amongst us can work for Agile organizations, and everybody else is doomed. And that's not true, is it? That's nonsense, right? So we've got to come together and find these ways of working as my friend John Kern points out so eloquently.

Sean Blake:

Okay, that's good advice. So for these, some people that you meet, there's still this resistance that has been around for many years. How do you go about encouraging people to get out of their comfort zone to try this cross functional way of working and be more transparent, I guess with contributing to the team and not necessarily pushing towards being just an individual contributor?

John Turley:

Another great question, Sean. So there are a couple of ways we can do it. The psychometric instrument that I mentioned earlier, that can sort of measure I kind of always put that in inverted commas, because it doesn't really measure anything, it assesses, I suppose, is a really, really powerful tool. Off the back of that measurement, the psychologists that we work with can create a report that explains lots of this sort of meaning making stuff, adult developmental psychology to the individual. And it tends to be mind blowing. It really shifts people's perspective about what they are and how they're operating in the world.

John Turley:

Once people start to understand that there are these developmental stages, and we all move through them potentially to the last days of our life, we can start to see the disagreements. They just start to fall away. Disagreements start to fall away, because they cease to be seen as opposing views that can't be reconciled, because I'm this type of person and they're that type of person.

John Turley:

And they start to be seen as incompatibilities in meaning making. So people start to go, "Okay, well, I think this and you think that. How are we both making our meaning around this, that means we can see other's perspective?" And immediately, then you've started to find a mechanism to find some common ground.

John Turley:

So the leadership development profile report, which is the report that comes from the psychometric instrument really sheds a lot of light on for the individual, both on how they're working and what development looks like, what psychological development looks like for them. So that's a powerful tool. We have another service that we call dialogue partnering, which we're piloting, which is sort of what over an eight or 10 week program, it's a one on one collaborative inquiry into how an individual is making their meaning, and what the strengths of their meaning making and the limitations of their meaning making are.

John Turley:

And once people start to realize that the way, the reason they feel defensive because the way they code has just been criticized is because they're drawing their meaning from being the best coder on the planet. But there is a development path that leaves that behind, which is where many, many people get to. It's kind of like an a-ha moment, people just realize that reality is different to what they thought and it can be adjusted.

John Turley:

So the LDP, the Leadership Development Profile reports, dialogue partnering, and working with senior management to create a deliberately developmental environment, which does those things I mentioned before, they're the critical tools that we use to help individuals unlock their own psychological development. And the question is, of course, why would they be motivated to do this? Why would they care? And they care, because 80% of people have got a very low level of engagement in their work. Most people are treading water, killing time. It's not a joyous place to be. Once people start to work in cross functional teams and get involved in joyous work with their colleagues to create things they couldn't, which is a basic human instinct, that's a buzz, then you come into work and enjoying yourself.

John Turley:

That's what I said to you at the beginning of that call, right? I'm having a great time, I'm working with some brilliant people unlocking new knowledge that we believe humankind doesn't have. That's a buzz. I'm not treading water in my role, you know what I mean? And this isn't unique to me. In my view, the whole world could be like that. We could all work in roles like that, maybe that's got a bit far. But certainly, many more of this could then currently do to get on board with the psychological development and enjoy your role more, enjoy your work. There's a lot of time.

Sean Blake:

Yeah, I really resonate with what you said about the buzz. And I've seen that happen when the light bulb comes on in people, and it's no longer this factory line of work getting passed down to you. But you realize you're now part of a team, everyone's there to support you, you're working towards a common goal. And it's transparent, you can see what other people are working on, and you're helping each other build something together. It's actually fun. For the first time in a lot of people's careers, it's a fun and enjoyable experience to come to work. So that must make you feel really good about doing what you do.

John Turley:

Yeah, it does. It's why I get out of bed, and it's what I've been about for 20 years trying to unlock this, really help other people unlock this. I got a phone call from a colleague the other day who said they were doing some exercise, and they were thinking about their new role. And they thought to themselves, this is what it feels like to do joyous work.

John Turley:

I mean, that [inaudible 00:42:51] job done, because this is a very capable individual. Once they're feeling like that, you know that they're going to do great things. When they're feeling like they're other people feeling, that people are clot watching, or there's this culture of busyness, where we can't admit that we don't know things. And then we've got to be in a meeting doing something, in the transparent world that you're just talking about, if I've got any work to do, I can just sit and say, "I'm going to work today, I'm waiting for more stuff to write." And it's not a bad thing. It's like, great, you're working at a sustainable pace. That's a good thing. I worked for a Swiss bank for years and years, working at a sustainable pace but nobody was interested, you need to work at a full on flat out unsustainable pace. And when you're burned out, you can go and we'll get somebody else to come in and do it. That's how it works. That's miserable.

Sean Blake:

It's not what we want, Sean, is it? It's not what we want. And unfortunately, a lot of people have been there before and they've experienced it. And once they see the light, they never want to go back to it, which I guess is a good thing once you recognize that there's a better way.

John Turley:

Yeah, agreed.

Sean Blake:

Yeah. Okay, well, I think we're going to wrap up shortly. I do have two more questions for you before we call an end.

John Turley:

I'll try and keep the answers brief.

Sean Blake:

No, that's fine. I'm really enjoying it. I could probably go for another hour but I know we've got other things to do. So in the research, I've read some of your blog posts, and I watched some of the talks that you've done and events in the past, and you speak about this concept of hidden commitments. And I just like to learn a bit more, what is a hidden commitment? And what's the implication?

John Turley:

Great question. So Robert Kegan and Lisa Lahey, developmental psychologists, wrote a book called Immunity to Change. This is a book that I read here a few years ago. And in there, Bob and Lisa talk about hidden commitments. And so they start by pointing out that we all make New Year's resolutions and they all fail. We really mean them when we make them. And when I was in my late teens, maybe I really did mean them when I made them. But I could never keep them.

John Turley:

In another book, Kegan points out, I think it's in the book called The Evolving Self. He points out that a large majority of men, after they've had heart attacks, I think it's a study in America. But it's been a while since I read it, I think it's six out of seven, don't change either their diet or their exercise regime after they've had a heart attack. And the reason he uses that as a case study in the book, because he's pointing out that it's not that these people don't know what to do, you need less calories in, more out. And it's not that they're not motivated to do it. They've had a near death experience. They'd like to stay alive, we presume.

John Turley:

Yet still, they don't make any meaningful change to their diet, their exercise regime, why not? And what Bob and Lisa say in the book from their research is that it's down to hidden commitments. We all have our way of making meaning. We have our values and our assumptions that we absorb from society as if by osmosis. And we don't question them. We can't question all of the assumptions that we absorb as we grow up. It's just not possible. So we have these hidden assumptions that we're committed to hidden commitments. And sometimes, these hidden commitments conflict with our stated objectives. And when the hidden commitment conflicts with our stated objective, the result is that we get very confused about the fact that the stated objective sort of falls by the wayside, and we don't really understand why. We might think, I would think a common out, because I just need to try harder, I just need more willpower. I just need to stay the course. And it's not true very often. There is something else in your meaning making this conflicted with our stated objective. And once you can surface it, then you can start to examine that hidden commitment, and you can play around with it.

John Turley:

And when you can play around with it, then you're adjusting your meaning making. And the technique that we use in dialogue partnering comes from Bob and Lisa's book, where we're essentially uncovering those hidden commitments and seeing how they conflict with commitment. So that's sort of, and then once you can see it, and you can experiment with it, you can start to unlock change in yourself. Peter Senge, I think he's director of innovation. He's very famous, director of innovation for MIT. And he has a beautiful little quote, something like, "What folly it is to think of transforming our organizations without transforming ourselves?"

John Turley:

We need to change our relationship with power in order to change the way power is distributed across our organizations. And that's an example of a hidden commitment that we don't normally think about. We just think we can empower people magically, whilst retaining all the power for the senior manager. And that just doesn't work. There's a hidden commitment, conflicting with the idea that we want to empower our teams, which is a quite flawed idea.

Sean Blake:

Wow. Okay. Well, I really like the approach to work and looking at the social structure, the social networks, and the psychology behind it all. It's really fascinating and it's not something I've really come across before, especially in the Agile space. So that's really unique. Thanks for sharing that, John. Last question for you. 2020 has been interesting to say the least. We've talked about some things that have stayed the same over your career, some things that have change. What do you think is going to come next, looking forward to the next five, 10 years? What are some of those trends that you think are really going to stand out and maybe change the way that your work, it changes the way that that your nine to five looks or changes the way that you interact with your clients?

John Turley:

I think that this won't just change the way my nine to five looks. It will change like everybody's nine to five looks. I think that the world is in a difficult place. A lot of us are upset, and it looks like a bit of a mess, and we're all anxious, I think. A lot of us are anxious. But as a friend said to me, he was quoting somebody else, never let a good crisis go to waste. The amount of changes, a lot of energy in the system, the amount of changes in the system is palpably changing things.

John Turley:

Many of us recognize there must be a better way of doing things because our ways of organizing ourselves as society, including our organizations is collapsing. It doesn't work anymore. People are realizing through work that people like the names I've mentioned, and through our original research, I hope will sort of contribute in an original way to this, that there is a better way of organizing ourselves that humankind does have the knowledge and the experience to do what we need to do.

John Turley:

It just isn't in IT. We need to look outside of it to what the psychologists say about mindset, not what the Agile people say about mindset. That's a radical idea. And as we import this learning and this knowledge, we have a framework that helps us understand to a much greater degree what's really going on, and how we can unlock real change. So everything that I talked about today, very little of it is original. We have some original work I can't really talk about. Does it matter? The knowledge is out there. If we do the people and culture bit and the tools and the methodology together, then it scales, then we change the way organizations work, which is going to change everybody's nine to five.

Sean Blake:

That's great. It's bringing it back to basics, isn't it? What we know about human beings, and now let's apply that to what we know about work. So that's really eye opening. And I've learned a lot from our conversation, John. I've got a few books and a few research papers to go and look at after this. So thank you so much for appearing on the Easy Agile podcast, and we really appreciate your time.

John Turley:

Sure, my pleasure. I mean, I love and we love at Adaptavist to sharing what we're doing. So we can all engage in more joyous work, man. So thanks for helping us get the message out there.

‍

"That's a wrap on Agile2022! It was great to be able to catch up with so many of you in the agile community in-person!" - Tenille Hoppo

This bonus episode was recorded LIVE at Agile2022 in Nashville!

The Easy Agile team got to speak with so many amazing people in the agile community, reflecting on conference highlights, key learnings, agile ceremonies + more!

Thanks to everyone who stopped by the booth to say G’Day and enjoyed a Tim Tam or two ;)

Huge thank you to all of our podcast guests for spending some time with us to create this episode!

• Cody Wooten
• Gil Broza
• Maciek Saganowski
• Lindy Quick
• Carey Young
• Leslie Morse
• Dan Neumann
• Joseph Falú
• Kai Zander
• Avi Schneier
• Doug Page
• Evan Leybourn
• Jon Kerr
• Joshua Seckel
• Rob Duval
• Andrew Thompson

Transcript

Caitlin:

Hi, everyone. Well, that's a wrap on Agile 2022 in Nashville. The Easy Agile team is back home in Australia, and we spent most of our journey home talking about all of the amazing conversations that we got to have with everyone in the Agile community. It was great catching up with customers, partners, seeing old friends, and making lots of new ones. We managed to record some snippets of those amazing conversations, and we're excited to share them with you, our Easy Agile Podcast audience. So enjoy.

Maciek:

[inaudible 00:00:26].

Tenille:

Maciek, thanks so much for taking time with us today.

Maciek:

No worries.

Tenille:

[inaudible 00:00:30], can you let us know what was the best thing you've learned this week?

Maciek:

Oh, that was definitely at Melissa Perri's talk. When she talked about... Like, to me, she was talking about slowing down. And what we do in Agile, it's not just delivery, delivery, delivery, but very much learning and changing on things that we already built, and finding out what value we can give to customers. Not just ship features, it's all about value. That's what I learned.

Tenille:

That's great. Thank you. So what do you think would be the secret ingredient to a great Agile team?

Maciek:

Humility. Somehow, the team culture should embrace humility and mistakes. And people should not be afraid of making mistakes, because without making mistakes, you don't learn. That's what I think.

Tenille:

So what would be, I guess, if there's one Agile ceremony that every team should do, what do you think that might be?

Maciek:

For sure, retro, and that comes back to the mistakes and learning part.

Tenille:

Yeah. Fantastic.

Maciek:

No worries.

Tenille:

That's great. Thanks so much for taking time.

Maciek:

Okay. Thank you.

Tenille:

Cheers.

Gil:

[inaudible 00:01:42].

Caitlin:

Gil:, thank you so much for chatting with us. So we're all at Agile 2022 in Nashville at the moment. There's lots of interesting conversations happening.

Gil:

Yes.

Caitlin:

If you could give one piece of advice to a new forming Agile team, what would it be?

Gil:

It would be to finish small, valuable work together. It has a terrible acronym, FSVWT. So it cannot be remembered that way. Finish small, valuable work together. There's a lot of talk about process, working agreements, tools. This is all important, but sometimes it's too much for a team that's starting out. And so if we just remember to finish small valuable work together, that's a great story.

Caitlin:

Yeah, I love that. And you were a speaker at conference?

Gil:

Yes.

Caitlin:

Can you give our audience a little bit of an insight into what your conversation was about?

Gil:

What happens in many situations is that engineering or development doesn't really work collaboratively with product/business. And instead, there is a handoff relationship. But what happens is that in the absence of a collaborative relationship, it's really hard to sustain agility. People make a lot of one-sided assumptions. And over time, how decisions get made causes the cost of change to grow, and the safety to make changes to decrease. And when that happens, everything becomes harder to do and slower to do, so the agility takes a hit. So the essence of the talk was how can we collaboratively, so both product and engineering, work in ways that make it possible for us to control the cost of change and to increase safety? So it's not just collaboration of any kind. There are very specific principles to follow. It's called technical agility, and when we do that, we can have agility long-term.

Caitlin:

Great. I love it. Well, thank you so much and I hope you enjoy the rest of your time at the conference.

Gil:

Thank you.

Caitlin:

Great. Thank you.

Tenille:

Hi, Tenille here from Easy Agile, with Josh from Deloitte, and we're going to have a good chat about team retrospectives. So Josh, thank you for taking the time to have a good chat. So you are a bit of an expert on team retrospectives. What are your top tips?

Josh:

So my top tips for retrospective is first, actually make a change. Don't do a lessons observed. I've seen lots of them actually make a change, even if it's just a small one at the end. The second, and part of that, is make your change and experiment. Something you can measure, something that you can actually say yes, we did this thing and it had an impact. May not be the impact you wanted, but it did have some kind of impact. The second tip is vary your retrospectives. Having a retrospective that's the same sprint after sprint after sprint will work for about two sprints, and then your productivity, your creativity out of the retrospective will significantly reduce.

Tenille:

That's an excellent point. So how do you create [inaudible 00:05:03]?

Josh:

Lots and lots of thinking about them and doing research and using websites like TastyCupcakes, but also developing my own retrospectives. I've done retrospective based on the Pixar pitch. There's six sentences that define every Pixar movie. Take the base sentences, apply them to your sprint or to your PI and do a retro, and allow the team that creativity to create an entire movie poster if they want to. Directed by [inaudible 00:05:34], because it happens. People get involved and engaged when you give them alternatives, different ways of doing retrospectives.

Tenille:

That's right. So for those teams that aren't doing retrospectives at the moment, what's the one key thing they need to think about that you... What's the one key thing you could tell them to encourage them to start?

Josh:

If you're not doing retrospectives, you're not doing [inaudible 00:05:54]. So I shouldn't say that. But if you're not doing retrospectives, if you truly believe that you have absolutely nothing to improve and you are 100% of the best of the best, meaning you're probably working at Google or Amazon or Netflix, although they do retrospectives. So if you truly believe that you are the equivalent of those companies, then maybe you don't need to do them, but I'm pretty sure that every team has something they can improve on. And acknowledging that and then saying, how are we going to do that? Retrospective's a very fast, easy way to start actually making those improvements and making them real.

Tenille:

Fantastic. Great. Thanks so much for taking the time to chat to us briefly about retrospectives.

Josh:

Thank you.

Caitlin:

We're here with Leslie, who is the president of women in Agile. Leslie, there was an amazing event on Sunday.

Leslie:

Yes.

Caitlin:

Just talk to us a little bit about it. What went into the planning? How was it to all be back together again?

Leslie:

It was amazing to have the women in Agile community back together, right? Our first time since 2019, when everyone was together in Washington DC for that event. The better part of six or seven months of planning, we had about almost 200 people in the room. Fortunately, we know the [inaudible 00:07:10] of what these women in Agile sessions that we do, part of the Agile Alliance conferences every year, right? We've got a general opening. We've got a great keynote who is always someone that is adjacent to the Agile space. We don't want to just like... We want to infuse our wisdom and knowledge with people that aren't already one of us, because we get all of the Agile stuff at the big conference when we're there.

Leslie:

So that part, we always have launching new voices, which is really probably one of my most favorite women in Agile programs. Three mentees that have been paired with seasoned speakers, taking stage for the first time to share their talent and their perspective. So that's really great. And then some sort of interacting networking event. So that pattern has served us really well since we've been doing this since 2016, which is a little scary to think it's been happening that long. And it's become a flagship opportunity for community to come together in a more global fashion, because the Agile Alliance does draw so many people for their annual event.

Caitlin:

Yeah, for sure. Well, it was a great event. I know that we all had a lot of fun being there. What was your one key takeaway from the event?

Leslie:

I'm going to go to [inaudible 00:08:14] interactive networking that she did with us, and really challenging us to lean into our courage around boundaries and ending conversations. We don't have to give a reason. If some conversation's not serving us or is not the place that we need to be for whatever reason, you absolutely have that agency within yourself to end that conversation and just move on. I love the tips and tricks she gave us for doing that well.

Caitlin:

Yes, yes, I love that too. That's great. Well, thank you so much. Appreciate it.

Leslie:

Yeah. Thanks for having me.

Tenille:

Hi, Evan. How are you?

Evan:

Very good.

Tenille:

That's good. Can you please tell me what's the best thing you learned today?

Evan:

The best quote I've got, "Politics is the currency of human systems." Right?

Tenille:

Wow.

Evan:

So if you want to change a human system, you got to play the politics.

Tenille:

Fantastic.

Evan:

Which feels crappy, but-

Tenille:

It's the way it is.

Evan:

... that's the way it is.

Tenille:

[inaudible 00:09:07]. Okay, next question. What is the Agile ceremony that you and your team can't live without?

Evan:

Retrospective. With the retrospective, you can like create everything else.

Tenille:

Fantastic. That's really good. And what do you think is probably the key ingredient to a good retrospective?

Evan:

Oh, trust. Trust requires respect. It requires credibility. It requires empathy. So trust is like that underpinning human capability.

Tenille:

Yeah. Fantastic. Thanks very much.

Evan:

Thank you.

Tenille:

Yes.

Caitlin:

Right. We're here with Cody from Adfire. So Cody, how you enjoyed the conference so far?

Cody:

I'm really loving the conference. It's been awesome. To be honest, when we first got here, it seemed maybe a little bit smaller than we thought, but the people here's been incredible, highly engaged, which was always great. And plus, a lot of people are using Jira and Atlassian. So lot of big points.

Caitlin:

Win-win for both, huh?

Cody:

Yeah. Always, always, always.

Caitlin:

Very good.

Cody:

Yeah.

Caitlin:

Lots of interesting talks happening. Have you attended any that have really sparked an interest in you? What's [inaudible 00:10:15]-

Cody:

Yeah. I can't remember any of the talk names right off the top, but they've all been incredibly insightful. Tons of information. It seems like there's been a topic for everything, which is always a great sign and stuff like that. So my notes, I have pages and pages and pages of notes, which is always a good sign.

Caitlin:

Yeah, that's [inaudible 00:10:34].

Cody:

So I'm I have to go back and [inaudible 00:10:35] again.

Caitlin:

Yes.

Cody:

But it's been incredible and the talks have been very plentiful, so yeah.

Caitlin:

Good. Good. And what is the one key takeaway that you are looking forward to bringing back and sharing with the team?

Cody:

Well, I think one of the key takeaways for us was that... I talked about the engagement that everybody has, but one thing that's been incredible is to hear everybody's stories, to hear everybody's problems, their processes, all of that stuff. So all of that information's going to be a great aggregate for us to take back and create a better experience with our product and all that good stuff. So yeah.

Caitlin:

For sure. I love it. Now, I have one last question for you. It's just a fun one. It's a true or false. We're doing Aussie trivia. Are you ready for this one?

Cody:

Okay.

Caitlin:

Okay.

Cody:

Hopefully.

Caitlin:

So my true or false is, are Budgy Smugglers a type of bird?

Cody:

Are buggy smugglers-

Caitlin:

Budgy Smugglers.

Cody:

Budgy Smugglers.

Caitlin:

A type of bird.

Cody:

True.

Caitlin:

False. No.

Cody:

What are they?

Caitlin:

Speedos.

Cody:

Yeah. Well, I've got some of those up there in my luggage. So I'll bring the budgys out now.

Caitlin:

With your Daisy Dukes.

Cody:

Exactly. Exactly.

Caitlin:

Yeah. And cowboy boots, right?

Cody:

Yeah.

Caitlin:

Well, thank you so much.

Cody:

Thank you.

Caitlin:

Very appreciate it.

Cody:

Yeah. Thank you.

Tenille:

Doug, how are you?

Doug:

I'm great. Thank you.

Tenille:

Awesome. Well, tell me about, what's the best thing you've learned today?

Doug:

I think learning how our customers are using our products that we didn't even know about is really interesting.

Tenille:

That's amazing. Have you had a chance to get out to many of the sessions at all?

Doug:

I actually have not. I've been tied to this booth, or I've been in meetings that were already planned before I even came down here.

Tenille:

[inaudible 00:12:01].

Doug:

Yeah.

Tenille:

That's good. So when you're back at work, what do you think is probably the best Agile ceremony that you and your team can't live without?

Doug:

I think what I'm bringing back to the office is not so much ceremony. It's really from a product perspective. I work in product management. So for us, it's how we can explain how our product brings value to our customers. So many lessons learned from here that we're really anxious to bring back and kind of build into our value messaging.

Tenille:

Fantastic.

Doug:

Yeah.

Tenille:

Thanks. That's great. Thanks very much.

Caitlin:

He was one of the co-authors of the Agile Manifesto. Firstly, how are you doing in conference so far?

John:

Well, working hard.

Caitlin:

Yeah, good stuff.

John:

Enjoying Nashville.

Caitlin:

Yeah. It's cool, isn't it? It's so different from the [inaudible 00:12:46] what's happening.

John:

Yeah. It's good. Yes. It's nice to see a lot of people I haven't seen in a while.

Caitlin:

Yeah. Yeah.

John:

And seeing three dimensional.

Caitlin:

Yes. Yeah, I know. It's interesting-

John:

It's there-

Caitlin:

... [inaudible 00:12:54] and stuff happening.

John:

Yeah, IRL.

Caitlin:

Lots of interesting [inaudible 00:13:01] that's happening. Any key takeaways for you? What are you going to take after to share with the team?

John:

Oh, well, that's a good question. I'm mostly been talking with a lot of friends that I haven't seen in a while. [inaudible 00:13:14].

Caitlin:

Yes.

John:

And since I've only been here a couple days, I haven't actually gone for much, if anything. To be frank.

Caitlin:

I know. Well, we're pretty busy on the boots, aren't we?

John:

Yeah. Yeah. But certainly, the kinds of conversations that are going on are... I was a little bit worried about Agile. Like, I don't want to say... Yeah, I don't want to say it. But I don't want to say, Agile's becoming a jump turf.

Caitlin:

Yes.

John:

But I think there's a lot of people here that are actually really still embracing the ideals and really want to learn, do and practice [inaudible 00:14:00].

Caitlin:

Yeah.

John:

So I'm frankly surprised and impressed and happy. There's a lot. If you just embrace more of the manifesto, and maybe not all of the prescriptive stuff sometimes, and you get back to basics. [inaudible 00:14:22]-

Caitlin:

Yeah. So let's talk about that, the Agile Manifesto that you mentioned. Embracing that. What does embracing mean? Can you elaborate on that a bit more? So we know we've got the principles there. Is there one that really stands out more than another to you?

John:

Well, my world of what I was doing at the time, and I'd done a lot of defense department, water haul, and built my own sort of lightweight process, as we call it before Agile. So to me, the real key... This doesn't have the full-

Caitlin:

Full manifesto, yeah.

John:

But if you go to the website and read at the top, it talks about like we are uncovering ways by doing, and I'm still learning, still uncovering. And I think it's important for people to realize we really did leave our ego at the door. Being humble in our business is super important. So that might not be written anywhere in the principles, but if the whole thing at the preamble at the top, and the fact that we talk about how we value those things on the blog versus the whole... There's a pendulum that you could see both of those things collide. That, in my opinion, one the most important trait that we should exercise is being humble, treating things as a hypothesis. Like, don't just build features [inaudible 00:15:58] bottom up, how do you seek up on the answers, that's what I want people to takeaway.

Caitlin:

That's great. That's great advice. Well, thank you so much, John. Appreciate you taking the time to chat with us.

John:

You're welcome, Caitlin.

Caitlin:

Yeah. Enjoy what's [inaudible 00:16:11].

John:

Thank you.

Caitlin:

Thank you.

John:

[inaudible 00:16:13] tomorrow.

Caitlin:

All right.

Tenille:

Abukar, thanks for joining us today. Can I ask you both, what do you think is the best thing you've learned today?

Avi:

Best thing I've learned?

Tenille:

Yeah.

Avi:

That's a really interesting one. Because I'm here at the booth a lot, so I'll get to attend a lot of things. So there were two things I learned that were really important. One, which is that the Easy Agile logo is an upside down A, because it means you're from Australia. So it's down under. And then the second most important thing I learned about today was we were in a session talking about sociocracy, and about how to make experiments better with experiments, which sounded a little weird at first, but it was really all about going through like a mini A3 process. For those of you listening, that's something that was done to Toyota. It's a structured problem solving method, but instead of going [inaudible 00:17:02] around it and going through the experiment, going around two or three times and then deciding that's the right experiment you're going forward.

Tenille:

Thank you. How about your time?

Kai:

I've been at the booth most of the time, but from that you meet a lot of people all over the world. And we really have like one thing in common, which is wanting to help people. And it's really been nice to be in a room of people if they're at the beginning of their journey or their really seasoned, that their motivation is just to really empower others. So it's been really nice to be around that kind of energy.

Avi:

We've really learned that our friends from Australia are just as friendly up here as you are on the other side. I feel when you come on this side, you get mean, but it turns out you're just as nice up here too.

Tenille:

Well, it depends how long you've been on flight.

Avi:

Oh, exactly.

Tenille:

[inaudible 00:17:44], we're okay.

Kai:

Yeah.

Avi:Abukar:

Exactly. Good.

Tenille:

All right. One more question here.

Avi:

Sure.

Tenille:

What do you think is the secret ingredient for a successful team?

Avi:

What do I think the secret? Oh, that's a really good question. That's a-

Kai:

He's the best one to answer that question.

Avi:

That's a little longer than a two-second podcast, but I'll tell you this. It may not be psychological safety,-

Tenille:

Okay.

Avi:

... just because Google said that and Project Aristotle show that. I think to have a really, really successful team, you need a really skilled scrum master. Because to say that the team has psychological safety is one ingredient, it's not the only ingredient. A strong scrum master is someone who's really skilled to create that psychological safety, but also help with all the other aspects of getting ready to collaborate and coordinate in the most positive way possible. Plus, searching for... Her name is Cassandra. On Slack, she calls herself Kaizen. You get it? It's a joke. But that's the whole thing is that a really skilled scrum master helps the teams find the kaizens that they need to really get to become high performing. So psychological safety is an enabler of it, but that doesn't mean it creates the performance. It's an ingredient to make it happen.

Tenille:

Fantastic.

Kai:

There's no better answer than that one. Let's do exclamation.

Tenille:

Excellent. Thanks very much for taking the time.

Avi:

Thank you so much.

Kai:

Of course.

Hayley:

We're here with Carey from Path to Agility. Carey, what have you been really loving about this conference?

Carey:

I think I've loved the most about this conference so far is the interaction with all the people that are here. It's really nice to get together, meet different folks, network around, have the opportunity to see what else is out there in the marketplace. And then, of course, talk about the product that we have with Path to Agility. It's a wonderful experience to get out here and to see everybody. And it's so nice to be back out in person instead of being in front of a screen all the time.

Tenille:

Yeah, absolutely. Have you had a chance to get to many of the sessions?

Joseph:

I've tried to as much as I can, but it's also important to take that time to decompress and let everything sink in. So here we are having fun.

Tenille:

Yeah, absolutely. So thinking back to work, what do you think is the one Agile ceremony that you take that helps you and your team the most?

Joseph:

I think that finding different ways to collaborate, effective ways to collaborate. And in terms of work management, how are we solving some of the problems that we have? There's so many tools that are here to make that easier, which is made pretty special. Speaking to people and finding out how they go about solving problems.

Tenille:

And what do you think makes a really great Agile team?

Joseph:

Well, you could say something very cliche, like being very adaptive and change and so on and so forth. But I think it really comes down to the interaction between people. Understanding one another, encouraging one another, and just the way you work together.

Tenille:

Fantastic. Great. Well, thanks very much for taking the time to chat.

Joseph:

Thank you. It was nice chatting with you guys all week long.

Tenille:

Cheers.

Tenille:

Dan, thanks for taking the time to chat.

Dan:

You're welcome.

Tenille:

[inaudible 00:22:54] questions. What do you think is the best thing you learned today?

Dan:

Oh, the best thing I learned today, the morning products keynote was excellent. Got a couple tips on how to do product management, different strategies, how you have folks about seeing their focus on the tactical and the strategic. So just some nice little nuggets, how to [inaudible 00:23:12].

Tenille:

[inaudible 00:23:13], thanks for joining us today. Can I start by asking, what do you think is the best thing you've learned this week?

Speaker 17:

The best thing I've learned this week is there's no right way to do Agile. There's a lot of different ways you can do it. And so it's really about figuring out what the right process is for the organization you're in, and then leveraging those success patterns.

Tenille:

Well, I guess on that, is there one kind of Agile ceremony that you think your team can't do without?

Speaker 17:

The daily standup being daily. I think a lot of our teams, they talk all day long. They don't necessarily need to sync up that frequently. I've had a few teams already, they go down like three days a week and it seems to work for them. The other maybe key takeaway that I've seen folks do is time boxes. So no meetings from 10:00 to 2:00 or whatever it may be, and really driving that from a successful perspective.

Tenille:

I guess on that note, what do you think makes a really successful Agile team?

Speaker 17:

The ability to talk to each other, that ability to communicate. And so with all of our teams being either hybrid or remote, making sure that we have the tools that let them feel like they can just pick up and talk to somebody anytime they want, I think is key. And a lot of folks still don't have cameras, right, which is baffling to me. But that ability to see facial expressions, being face to face has been so nice because we're able to get that. So that's the other key is just that ability to talk to each other as though I could reach out and touch you.

Tenille:

Okay. Fantastic. Well, thanks so much.

Speaker 17:

You're welcome. Thank you.

Tenille:

Okay. Rob and Andrew, thanks so much for taking a few minutes with us. Can I start by asking you, what do you think is the best thing you learned this week?

Rob:

For me, it's definitely fast scaling Agile, we learned about this morning. We're going to try it.

Andrew:

For me, I really enjoyed the math programming session and learning kind of different ways to connect engineers and collaborate.

Tenille:

Great. Next up, I guess, what do you think makes a great Agile team?

Rob:

First and foremost, that they're in control of how they work and what they work on, more than anything else.

Andrew:

Yeah. For me, it's a obviously psychological safety and just having a good team dynamic where they can disagree, but still be respectful and come up with great ideas.

Tenille:

And is there one Agile ceremony that you think a great team can't live without?

Rob:

Probably retrospective. I think the teams need to always be improving, and that's a good way to do it.

Andrew:

Agreed. Yeah. Agreed.

Tenille:

Okay. That's great. Thanks so much for taking the time.

Andrew:

Thank so much. Appreciate it.

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

‍

‍