Webinar: Turn Strategy into Goals That Get Delivered

Close the gap between planning & execution

Easy Agile Podcast Ep.14 Rocking the Docs

Listen on
Subscribe to our newsletter

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

Related Episodes

  • Podcast

    Easy Agile Podcast Ep.6 Chris Stone, The Virtual Agile Coach

    Sean Blake

    What a great conversation this was with Chris Stone, The Virtual Agile Coach!

    Chris shared some insights into the importance of sharing and de-stigmatising failures, looking after your own mental health, and why work shouldn't be stale.

    Some other areas we discussed were, why you should spend time in self reflection - consider a solospective? and asking "how did that feel?" when working as a team.

    "I really enjoyed our chat. Plenty to ponder over the silly season, and set yourself up with a fresh perspective for 2021. Enjoy and Merry Christmas!"

    Transcript

    Sean Blake:

    Hello, and welcome to another episode of the Easy Agile Podcast. It's Sean Blake here, your host today, and we're joined by Chris stone. Chris is going to be a really interesting guest. I really enjoyed recording this episode. Chris is the Virtual Agile Coach. He's an agility lead. People First champion blogger, speaker and trainer, who always seeks to gamify content and create immersive Agile experiences. An Agile convert all the way from back in 2012, Chris has since sought to broaden his experiences, escape his echo chamber and to fearlessly challenge dysfunction and ask the difficult questions. My key takeaways from this episode were; it's okay to share your failures, the importance of recognizing our mental health, why it's important that work doesn't become stale, how to de-stigmatize failure, the importance of selfreflection and holding many self retrospectives, and the origins of the word deadline. You'll be really interested to find out where that word came from and why it's a little bit troubling. So here we go. We're about to jump in. Here's the episode with Chris stone on the Easy Agile Podcast. Chris, thanks so much for joining us and spending some time with us.

    Chris Stone:

    Hey there Sean, thank you for having me. It's a pleasure.

    Sean Blake:

    I have to mention you've got a really funky Christmas sweater on today. And for those people listening on the audio, they might have to jump over to YouTube just for a section to check out this sweater. Can you tell us a bit about where that came from?

    Chris Stone:

    So this sweater was a gift. It's a Green Bay Packers, Chris, Ugly Christmas Jumpers, what they call it. And I'm a fan of the Green Bay Packers, I've been out there a few times to Wisconsin, Green Bay, Wisconsin. It's so cold out there in fact. When you're holding a beer and minus 13 degrees, the beer starts turning to slush just from being outside in the cold air. It's a great place, very friendly, and the jumper was just a gift one Christmas from someone.

    Sean Blake:

    Love it. There's nothing better than warm beer is there? Okay. So Chris, I first came across you because of the content that you put out on LinkedIn. And the way that you go about it, it's so much fun and so different to really anything else I've seen in the corporate space, in the enterprise space, in the Agile space even, why have you decided to go down this track of calling yourself the virtual Agile coach, building a personal brand and really putting yourself out there?

    Chris Stone:

    Well, for me, it was an interesting one because COVID, this year has forced a lot of people to convert to being virtual workers, remote workers, virtual coaches themselves. Now, what I realized this year is that, the aspiration for many is those co-located teams, it's always what people desired. They say, "Oh, you have to work harder, Katie, that's the best way." And I realized that in my whole Agile working life, I'd never really had that co-located team. There was always some element of distributed working and the past two years prior to where I'm currently, my current company, I was doing distributed scaled Agile with time zones, including Trinidad and Tobago, Alaska, Houston, the UK, India, and it was all remote.

    Chris Stone:

    And I thought, all right, this is an opportunity to recognize the fact that I was a virtual Agile coach already, but to share with others, my learnings, my experiences, the challenges I've faced, the failures I've had with the wider community so they can benefit from it because obviously, everyone, or more many have had to make that transition very quickly. And there's lots of learnings there that I'm sure people would benefit from. And this year in particular, I guess the honest answer, the reason for me being, I guess out there and working more on that side of things, being creative is because it's an outlet for my mental health.

    Chris Stone:

    I suffer from depression and one of my ways of coping with that is being creative and creating new content and sharing it. So I guess it's a reason of... it's linked to that also, but also the stories that people tell me afterwards, they motivate me to keep doing it. So when someone comes to me and says, "Hey, I did the Queen retrospective, the Queen Rock Band retrospective, and this program manager who never smiles connected to the content and admitted he liked Queen and smiled." And this was a first and when people come to me and say, "Hey, we did the Home Alone retrospective, the one of your Christmas themed ones and people loved it. It was great." It was the most engaging retrospective we've had so far because the problem is work can become stale if you let it be so.

    Chris Stone:

    Retrospectives can become this, what did we do last time? What are we going to do next time? What actions can we do? Et cetera, et cetera. And unless you refresh it and try new things, people will get bored and they'll disconnect and they'll disengage, and you're less likely to get a good outcome that way. So for me, there's no reason you can't make work a little bit fun, with a little bit of creativity and a little bit of energy and passionate about it.

    Sean Blake:

    I love that. And do you think a lot of people come to work even when they're working in Agile co-located teams and it's just not fun, I mean what do you think the key reasons are that work isn't fun?

    Chris Stone:

    I think because it can become stale. All right. So let's reflect on where we are today. Today, we're in a situation where we're not face-to-face with one another. We don't have time for those water cooler chats. We don't connect over a coffee or a lunch. We don't have a chat about idle banter and things of that on the way to a meeting room, we didn't have any of that. And that forces people to look at each other and see themselves as an avatar behind a screen, just a name. Often in particular, people aren't even on video camera.

    Chris Stone:

    It forces them to think of people as a name on a screen, rather than a beating heart on a laptop. And it can abstract people into just these entities, these names you talk to each day and day out, and that can force it to be this professional non-personal interaction. And I'm a firm believer that we need to change that. We need to make things more fun because it can, and in my experience, does result in much better outcomes. I'm very, very people first. We need to focus on people being people. People aren't resources. This is a common phrase I like to refer to you.

    Sean Blake:

    I love that, people aren't resources. You spoke a little bit about mental health and your struggle with depression. Something that I hear come up time and time again, is people that talk about imposter syndrome. And I wonder, firstly, if you think that might be exasperated through working remotely now. People are not so sure how they fit in, where their role is still the same role that it was 12 months ago. And do you have any tips for people when they're dealing with imposter syndrome, especially in a virtual environment?

    Chris Stone:

    Well, yeah I think this current environment, this virtual environment, the pandemic in particular, has led to a number of unhelpful behaviors. That there's a lot more challenges with people's mental health and negativity, and that can only lead to, I guess, less desire, less confidence in doing things, maybe doubting yourself. There's some great visuals I've shared on this recently, and it's all about reframing those imposter thoughts you have, the unhelpful thinking, that thing that goes through your mind that says, Oh, they're all going to think I'm a total fraud because maybe I don't have enough years of experience, or I should already know this. I must get more training. There's lots of “shoulding” and “musting” in that. There's lots of jumping to conclusions in this.

    Chris Stone:

    And a couple of ways of getting around that is, so if you're thinking of the scenario where I'm a fraud think, "Oh, well I'm doing my best, but I can't predict what they might think." When you're trying to think about the scenario of do I need to get more training? Well, understand and acknowledge the reality that you can't possibly know everything. You continue to learn every single day and that's great, but it's unrealistic to know it all. There's a great quote I often refer to and it's, true knowledge is knowing that you know nothing. I believe it's a quote from Socrates.

    Chris Stone:

    And it's something that very much resonates with me. Over the years I've gone through this learning journey where, when I first finished university, for example, I thought I knew everything. I thought I've got it all. And I'd go out to clients and speak and I'm like, "Oh yeah, I know this. I've got this guys." And then the more involved I've become and the more deeper I've gone into the topic, the more I realized, actually there's so much that I don't know. And to me, true knowledge is knowing that you know nothing tells me there's so much out there that I must continuously learn, I must continuously seek to challenge myself each and every day.

    Chris Stone:

    Other people who approach me and say, "How do you, or you produce a lot of content. How would you put yourself out there?" And I say, "Well, I just do it." Let's de-stigmatize failure. If you put a post out there and it bombs, it doesn't matter, put another one out there. It's as simple as that, learn from failure, Chuck something out there, try it, if it doesn't work, try something else. We coach Agile teams to do this all the time, to experiment. Have a hypothesis to test against that. Verify the outcomes and do retrospectives. I do weekly solospectives. I reflect on my week, what works, what hasn't worked, what I'm going to try differently. And there's no reason you can't do that also.

    Sean Blake:

    Okay. So weekly solospectives. What does that look like? And how do you be honest with yourself about what's working, what's not working and areas for yourself to improve? How do you actually start to have that time for self-reflection?

    Chris Stone:

    Unfortunately you got to make time for some reflection. One thing I've learned with mental health is you have to make time for your health before you have to make time for your illness or before you're forced to make time for your illness. And it can become all too easy in this busy working world to not make time for your health, to not make time and focus on you. So you do just have to carve out that time, whether that's blocking some time in the diary on a Friday afternoon, just to sit down and reflect, whether that's making time to go out for a walk, setting up a time on your Alexa to have a five minute stretching break, whatever it is, there's things you can do, and you have things you have to do to make time for yourself.

    Chris Stone:

    With regards to a solospective, the way I tend to do things is I tend to journal on a daily basis. That's almost like my own daily standard with myself, it's like, what have I observed? What have I... what challenges do I face in the past day? And then that sums up in the weekly solospective, which is basically a retro for one, where I reflect on, what did I try it? What do I want to achieve this week? What's gone well? What hasn't gone well. It's the same as a retrospective just one and allows me to aggregate my thoughts across the week, rather than them being single events. So that I'm focusing more on the trajectory as opposed to any single outlier. Does that make sense?

    Sean Blake:

    It does. It does. So you've got this trajectory with your career. You're checking in each week to see whether you're heading in the right direction. I assume that you set personal goals as well along the way. I also noticed that you have personal values that you've published and you've actually published those publicly for other people to look at and to see. How important are those personal values in informing your life and personal and career goals?

    Chris Stone:

    So I'd say that are hugely important, for me, what I thought was we see companies sharing their values all the time. You look on company websites and you can see their values quite prominently. And you could probably think do they often live up to their values? You have so many companies have customer centricity as their value, but how many of them actually focus on engaging with their customers regularly? How many have a metric where they track, how often they engage with customers? Most of them are focusing on velocity and lead time. So I always challenge, are you really customer centric or is that lip service? But moving aside, I digress. I thought companies have values, and obviously we do as well, but why don't we share them? So I created this visual, showing what mine were and challenged a few others to share it also. And I had some good feedback from others which was great.

    Chris Stone:

    But they hugely influence who I am and how I interact on a day-to-day basis. And I'll give you an example, one of my values is being open source always. And what that means is nothing I create, no content I create, nothing I produce would ever be behind a payroll. And that's me being community driven. That's me sharing what I've learned with others. And how that's come to fruition, how I've lived that is I've had lots of people come to me say, "Hey, we love the things you do. You gave me flying things. Would you mind, or would you like to collaborate and create this course that people would pay for?" So often I've said, "If it's free, yes. But if it's going to be monetized, then no."

    Chris Stone:

    And I've had multiple people reach out to me for that purpose. And I've had to decline respectfully and say, "Look, I think what you're doing is great. You've got a great app and I can see how having this Agile coaching gamification course on that would be of great value. But if it's behind the payroll, then I'm not interested because it's in direct conflict with my own values, and therefore, I wouldn't be interested in proceeding with it. But keep doing what you're doing, being people first, #people first." This is about me embodying the focus on people being beating hearts behind a laptop, rather than just this avatar on a screen. And I have this little... the audio listeners, won't be able to see this, but I'm holding up a baby Groot here. And he's like my people first totem.

    Chris Stone:

    And the reason for that is I have a group called the Guardians of Agility, and we are people first. That's our emblem. And these are my transformation champions in my current company. I like to have Guardians of Agility, and I've got this totem reminding me to be people first in every interaction I have. So when, for example, I hear the term resources and I'm saying, well... As soon as I hear it, it almost triggers me. I almost hear like, "Oh, what do they mean by that?" And I'll wait a little moment and I'll say, "Hey, can you tell me what you mean by that?" And you tease it out a little bit. And often they meant, "Oh, it's people, isn't it?" If you're talking about people, can we refer to them as people?

    Chris Stone:

    Because people aren't resources. They're not objects or things you mine out the ground. They're not pens, paper or desks. They're not chairs in an office. They are people. And every time you refer to them as a resource, you abstract them. You make it easier to dehumanize them and think of them as lesser, you make it easier to make those decisions like, oh, we can just get rid of those resources or we can just move that resource from here to there and to this team and that team, whether they want to or not. So I don't personally like the language.

    Chris Stone:

    And the problem is it goes all the way back to how it's trained. You go to university and you take a business degree and you learn about human resources. You take a course, Agile HR, Agile human resources, right, and it's so prevalent out there. And unless we challenge it, it won't change. So I will happily sit there and a meeting with a CTO and he'll start talking about resource and I'll say, "Hey, what do you mean by that?" And I'll challenge it and he'll go, "Yeah, I've done it again, have I not?" "Yes. Yes, you have." And it's gotten to the point now where I'll be on this big group call for example, and someone will say it, and I'll just start doing this on a screen waving, and they'll go, "Did it again, didn't I?" "Yes, you did."

    Sean Blake:

    So some of these habits are so ingrained from our past experiences our education, and when you're working with teams for the first time, who's never worked in Agile before, they're using phrases like resources, they're doing things that sometimes we call anti-patents, how do you start to even have that conversation and introduce them to some of these concepts that are totally foreign to people who've never thought the way that you or I might think about our teams and our work?

    Chris Stone:

    Sure. So I guess that the first response to that is with empathy. I'm not going to blame someone or make out that they're a bad person for using words that are ingrained, that are normal. And this is part of the problem that that term, resource is so ingrained in that working language nowadays, same as deadlines. Deadlines is so ingrained, even though deadlines came from a civil war scenario where it referred to, if you went past the line, you were shot. How did that land in the business language? I don't know. But resources, it's so ingrained, it's so entrenched into this language, so people do it without intending to. They often do it without meaning it in a negative way. And to be honest, the word itself isn't the issue, it's how people actually behave and how they treat people.

    Chris Stone:

    I said my first approach is empathy. Let's talk about this. Let's understand, "Hey, why did you use term?" "Oh, I use it to mean this." "Okay. Well." Yeah, and not to do it or call them out publicly or things like that. It's doing things with empathy. Now, I also often use obviously gamification and training approaches, and Agile games to introduce concepts. If someone's unfamiliar to a certain way of working, I'll often gamify. I'll create something, a virtual Agile game to demonstrate. The way I do say, is I'm always looking to help people understand how it feels, not just to talk theory. And I'll give you an example. I'm a big fan of a game called the Virtual Name Game. It's a game about multitasking and context switching.

    Chris Stone:

    And I always begin, I'll ask group of people, "Hey guys, can you multitask?" And often they go, "Yeah, we can do that." And there'll be those stereotypical things like, "Oh yeah, I'm a woman. I can do that." It happens. Trust me. But one of the first things I do, if I'm face-to-face with them, I'll say, "Hey, hold your hands out like this. And in your left hand..." And people on the audio can't see me, I'm holding out like my hands in front of me. In my left hand, we're going to play an endless game of rock, paper, scissors. And in my right hand, we're going to play a game of, we have a thumb war with each other. And you can try, you can challenge them, can they do those concurrently? No, they can't. They will fail because you just can't focus on both at the same time.

    Chris Stone:

    Now the Virtual Name Game, the way it works is you divide a group of people up into primarily customers and one developer. And I love to make the most senior person in the room, that developer. I want them to see how it feels to be constantly context switching. So if you were the developer, you're the senior person to review the hippo in this scenario, the highest paid person. I would say Sean, in this game, these customers, they are trying to get their name written first on this virtual whiteboard. And we're going to time how long it takes for you to write everyone's name in totality. The problem is that they're all going to shouting at you continuously, endlessly trying to get your attention. So it's going to be Sean, Sean, write my name, write my...

    Chris Stone:

    And it's just going to be wow, wow, wow, who do I focus on? You won't know. And this replicates a scenario that I'm sure many people have experienced. He who shouts loudest gets what they want. Prioritization is often done by he who's... or the person who shouts loudest not necessarily he. We then go into another rounds where you say, I'm this round, Sean, people are to be shouting their name at you. But in this round, you're going to pay a little bit attention to everyone. So the way you're going to do that is you're going to read the first letter of one person's name, then you move on to the first letter of the next person's name, and you're going to keep going around. The consequence of that is everyone gets a little bit of attention, but the result is it's really slow.

    Chris Stone:

    You're starting lots of things but not finishing them. And again, in each round, we're exploring how it feels. How did it feel to be in that round? Sean, you were being shouted at, how did that feel? Everyone else, you were shouting to get your attention. You had to shout louder than other people, how did that feel? And it's frustrating, it's demotivating, it's not enjoyable. In the final around, I would say, "Hey, Sean, in this round, I'm going to empower you to decide whose name you write first. And you can write the whole thing in order. And the guys actually they're going to help you this time, there are no shouts over each other, they are going to help you." And in this scenario, as I'm sure you can imagine, it feels far better. The result is people finish things, and you can measure the output, the number of brand names written on a timeframe.

    Chris Stone:

    It's a very quick and easy way of demonstrating how it feels to be constantly context switching and the damage you can have, if, for example, you've prioritized things into a sprint and you got lots of trying to reorder things and so on and so forth, and lots of pressure from external people that ideally should be shielded from influencing this and that, and how that feels and what the result is, because you may start something, get changed into something else. You got to take your mindset of this, back into something else, and then the person who picks up the original thing might not have even been the same person, they've got to learn that over again. There's just lots of waste and efficiency costs through that. And that's just an example of a game I use, to bring that sort of things to life.

    Sean Blake:

    That's great. That's fantastic. I love that. And I think we need to, at Easy Agile, start playing some of those games because there's a lot of lessons to be learned from going through those exercises. And then when you see it play out in real life, in the work that you're doing, it's easier to recognize it then. If you've done the training, you've done the exercise, that all seems like fun and games at the time, but when it actually rears its head in the work that you're doing, it's much easier to call it out and say, "Oh wait, we're doing that thing that we had fun playing, but now we realize it's occurring in real life and let's go a different direction." So I can see how that would be really powerful for teams to go through that so Chris [crosstalk 00:22:26].

    Chris Stone:

    I'd also add that every game that I do, I construct it using the four Cs approach. So I'm looking to connect people... firstly, connect people to each other, and then to the subject matter. So in this game is about multitasking. To contextualize why that matters, why does context switching and multitasking matter in the world of work? Because it causes inefficiencies, because it causes frustration, de-motivation, et cetera. Then we do some concrete practice. We play a game that emphasizes how it feels. And at the end we draw conclusions, and the idea is that with the conclusion side of things, it's almost like a retrospective on the game. We say, "Hey, what did we learn? What challenges we face? And what can we do differently in our working world?" And that hopefully leaves people with actionable takeaways. A lot of the content I share is aiming to leave it with actionable takeaways, not just talking about something, but reflecting on what you could do differently, what you could try, what experiment you might like to employ with your working life, your team that might help improve a situation you're facing.

    Sean Blake:

    Okay. Yeah, that's really helpful. And you've spoken about this concept of Agile sins, and we know that a lot of companies have these values, they might've committed to an Agile transformation. They might've even gone and trained hundreds or thousands of people at accompany using similar tactics and coaching and educational experiences that you provide. But we still see sometimes things go terribly wrong. And I wonder, what's this concept of Agile sins that you talk about and how can we start to identify some of these sins that pop up in our day-to-day work with each other?

    Chris Stone:

    I guess, so the first thing I would emphasize about this is that using sin, it's a very dogmatic religious language and it's more being used satirically than with any real intent. So I just like to get that across. I'm not a dogmatic person, I don't believe there is any utopian solution. I certainly don't believe there's any one size fit to all situation for anyone. So the idea that there's really any actual sins is... yeah, take that with a pinch of salt. The reason the Agile sins came up is because I was part of... I'd done a podcast recently with a guy called Charles Lindsey, and he does this Agile confessional. And it's about one coach confessing to another, their mistakes, their sins, the things they've done wrong.

    Chris Stone:

    And I loved it because I'm all about de-stigmatizing failure. I'm all about sharing with one another, these war stories from one coach to another, because I've been a proponent of this in the past. I've shouted, "Hey there, I failed on this. I made this mistake. I learned from it." And I challenge others to do so as well and there's still this reluctance by many to share what went wrong. And it's because failure is this dirty word. It's got this stigma attached to it. No one wants to fail, leaders in particular. So the podcast was a great experience.

    Chris Stone:

    And it was interesting for me because that was the first time I'd given a confession, because I'll be honest with you, I'm someone who is used to taking confession myself. I go to this hockey festival every year and I got given years ago, this Archbishop outfit, and I kind of made that role my own way. I was drunk, and I said, "You're going to confess your sins to me." And if they haven't sinned enough, I tell them to go and do more. And I give them penicillin with alcohol shots and things like that. And I've actually baptized people in this paddling pool whilst drunk. Anyway, again, I digress, but I wasn't used to confessing myself, usually, I was taking confession, but I did so and it was a good experience to share some of my failures and my patterns was to create... and it was my own idea, to create my videos, seven videos of my seven Agile sins. And again, this was just me sharing my mistakes, what I've learned from that, with the intent of benefiting others to avoid those similar sins.

    Sean Blake:

    So you've spoken to a lot of other Agile coaches, you've heard about their failures, you confessed your own failures, is it possible for you to summarize down what are those ingredients that make someone a great coach?

    Chris Stone: And that is a question, what makes someone a great coach? I think it's going to be entirely subjective, to be honest. And my personal view is that a great coach listens more than they speak. I guess that would be a huge starting point. When they listen more than they speak, because I've... and this is one of the things I've been guilty of in the past, is I've allowed my own biases to influence the team's direction. An approach I'd taken in the past was, "Hey, I'm working with this team and this has worked well in the past. We're going to do that." Rather than, "So guys, what have you done so far? What have you tried? What's worked well? What hasn't worked well? What can we create or what can we try next? That works for you guys. Let's have you make that decision and I'm here to guide you through that process to facilitate it, rather than to direct it myself."

    Chris Stone:

    Again, I find ... it's an approach that resonates more with people. They like feel that they own that decision as opposed to it being forced upon them. And there's far less, I guess, cognitive dissonance as a consequence. So listening more than speaking is a huge for me, a point an Agile coach should do. Another thing I think for me nowadays, is that there's too much copying and pasting. And what I mean by that is, the Spotify, the Spotify model came out years ago and everyone went, "Oh, this is amazing. We're going to adopt it. We're going to have tribes and chapters and guilds and squads, and it's going to work for us. That's that's our culture now."

    Chris Stone:

    I was like, "Well, let's just take a moment here. Spotify never intended for that to happen. They don't even follow that model themselves anymore. What you've done there is you've just tried to copy and paste another model." And people do it with SAFe as well. They just say, "Hey, we're going to take the whole SAFe framework and Chuck it into our system in this blueprint style cookie cutter." And the problem is that it doesn't take into account for me, the most important variable in any sort of transformation initiative, the people, what they want, and the culture there. So this is where another one of my values is, innovate, don't replicate. Work with people to experiment and find that Agile, what works for them rather than just copying and pasting things.

    Chris Stone:

    So tailor it to their needs rather than just coming in with some or seen dancing framework, and then the way I do it is I say, "Hey, well, SAFe is great. Well, it's got lots of values, and lots of great things about it. Lots of benefits to it, but maybe not all of it works for us. Let's borrow a few tenent of that." Same with LeSS, same with Scrum At Scale, same with Scrum, similar to Kanban. There's lots of little things you can borrow from various frameworks, but there's also lots of things you can inject yourself, lot's of things you can try that work for you guys, and ultimately come up with your own tailor-made solutions. So innovate, don't replicate would be another one for me.

    Chris Stone:

    Learning, learning fast and learning often, and living and breathing that yourself. Another mistake I and other coaches I think have made is not making time for your own personal development to allowing, day in, day out to just be busy, busy, busy, but at the same time you're going out there, coaching teams, "Hey, you've got to learn all the time. You got to try new things." But not making that time for yourself. So I always carve out time to do that, to attend conferences, to read books, to challenge myself and escape my echo chamber. Not just to speak to the same people I do all the time, but perhaps to go on a podcast with people I've never spoken to. To a different audience, maybe to connect with people that actually disagree with me, because I want that.

    Chris Stone:

    I don't want that homophilous thinking where everyone thinks exactly like I do, because then I don't get exposed to the perspectives that make me think differently. So I'm often doing that. How can I tend to conference that I know nothing about, maybe it's a project management focus one. Project management and waterfall isn't a dirty word either. There is no utopian system, project management and... sure traditional project management and waterfall has its benefits in certain environments. Environments with less footing, less flexible scope or less frequently changing requirements works very well.

    Chris Stone:

    I always say GDPR, which is an EU legislation around data protection, that was a two year thing in the making and everyone knew exactly what was happening and when they had to do it by. That was a great example of something that can be done very well with a waterfall style, because the requirements weren't changing. But if you are trying to develop something for a customer base that changes all the time, and you've got lots of new things and lots of competitors and things like that, then it varies, and probably the ability to iterate frequently and learn from it is going to be more beneficial and this is where Agile comes in. So I guess to sum up there, there's a few things, learning fast learning often. I can't even remember the ones I've mentioned now, I've gone off on many tangents and this is what I do.

    Sean Blake:

    I love it. It's great advice, Chris. It's really important and timely. And you mentioned, earlier on that the customer base that's always changing and we know that technology is always changing and things are only going to change more quickly, and disruptions are only going to be more severe going forward. Can you look into the future, or do you ever look into the future and say, what are those trends that are emerging in the Agile space or even in work places that are going to disrupt us in the way that we do our work? What does Agile look like in five or 10 years?

    Chris Stone:

    Now that again is a very big question. I can sit here and postulate and talk about what it might look like. I'm going to draw upon what I think is a great example of what will shape the next five or 10 years. In February, 2021, there's a festival called Agile 20 Reflect, I'm not sure if you've heard of it, and it's built as a festival, not conference, it's really important. So it's modeled on the Edinburgh festival and what it intends to be is a celebration of the past, the present and the future of Agile. Now what it is, it's a month long series of events on Agile, and anyone can create an event and speak and share, and it will create this huge community driven load of content that will be freely accessible and available.

    Chris Stone:

    Now, there are three of the original Agile manifestor signatories that are involved in this. Lisa Adkins is involved in this as is lots of big name speakers that are attached to this festival. And I myself, I'm running a series of retrospectives on the Agile manifesto. I've interviewed Arie van Bennekum, one of the original Agile manifesto signatories. They're going to be lots of events out there. And I think that festival will begin to shape in some way, what Agile might look like because there's lots of events, lots of speakers, lots of panel discussions that are coming up, coming together with lots of professionals out there, lots of practitioners out there that will begin to shape what that looks like. So whilst I could sit here and postulate on it, I'm not the expert to be honest, and there are far greater minds than I. And actually I'd rather leverage the power of the wider community and come into that than suggesting mine at this time.

    Sean Blake:

    Nice. I like it. And what you've done there, you've made it impossible for us to click this video and prove you wrong in the future when you predict something that doesn't end up happening. So that's very wise if you.

    Chris Stone: Future proof myself.

    Sean Blake: Exactly. Chris, I think we're coming almost to the end now, but I wanted to ask, given the quality of your Christmas sweater, do you have any tips for teams who are working over the holiday period, they're most likely burnt out after a really difficult 2020? What are some of the things you'd say to coaches on Agile teams as they come into this time where hopefully people are able to take some time off, spend some time with their family. Do you have any tips or recommendations for how people can look after their mental health look after their peers and spend that time in self-reflection?

    Chris Stone:

    Sure. So a number of things that I definitely would recommend. I'm currently producing and sharing this Agile advent calendar. And the idea is that every day you get a new bite-size piece of Agile knowledge or a template or something working in zany or a video, whatever it may be. There's lots of little things getting in there. And there's been retro templates, Christmas and festive themes. So there's a Home Alone one, a Diehard one, an elf movie one, there's all sorts. Perhaps try one of those as a fun immersive way with your team to just reflect on the recent times as a squad and perhaps come up with some things in the next year.

    Chris Stone:

    And there's for example, the Diehard one, it's based on the quotes from the movie Diehard so it's what you'd be doing in there, celebrate your... to send them to your team. Or there's one in there about, if this is how you celebrate Christmas, I can't wait for new year. And that question was saying, what do we want to try next year? Like this year has been great, what do we want to try differently next year? So there's opportunities through those templates to reflect in a fun way so give one of those a go. I shared some Christmas eve festive Zoom backgrounds, or Team backgrounds, give those a go and make a bit fun, make it a bit immersive. There's Christmas or festive icebreakers that you can use. What I tend to do is any meeting I facilitate, the first five minutes is just unadulterated chat about non-work things, and I often use icebreakers to do so. And whether that's a question, like if you could have the legs of any animal, what would you have and why, Sean, what would that be?

    Sean Blake:

    Probably a giraffe, because just thought the height advantage, it's got to be something that's useful in everyday life.

    Chris Stone: Hard to take you on the ground maybe.

    Sean Blake:

    Yes. Yes, you would definitely need that. Although, I don't think I would fit in the lift on the way to work, so that would be a problem.

    Chris Stone:

    Yeah. That's just how I start. But yeah, that's just a question, because it's interesting to see what could people come up with, but there's some festive ones too, what's your favorite Christmas flick? What would put you on the naughty list this year? Yeah, does your family have any weird or quirky Christmas traditions? Because I love hearing about this. Everyone's got their own little thing, whether it's we have one Christmas present on Christmas Eve or every Christmas day we get a pizza together. There's some really random ones that come out. I love hearing about those and making time for that person interaction, but in a festive way can help as well.

    Chris Stone:

    And then on the mental health side of things, I very much subscribed to the Pomodoro effect from a productivity side of things. So I will use that. I'll set myself a timer, I'll focus without distractions, do something. And then in that five minute break, I'll just get up and move away from my desk and stretch and get a coffee or whatever it may be. But then I'll also block out time, and I know some companies in this remote working world at the moment are saying, "Hey, every one to 2:00 PM is blocked out time for you guys to go and have a walk." Some companies are doing that. I always make time to get out and away from my desk because that... and a little bit more productive and it breaks up my day a little bit. So I definitely recommend that. Getting some fresh air can do wonders for your mental health.

    Sean Blake:

    Awesome. Well, Chris, I've learnt so much from this episode and I really appreciate you spending some time with us today. We've talked about a lot of things from around the importance of sharing your failures, the importance of looking after your mental health, checking in on yourself and your own development, but also how you tracking, how you feeling. I love that quote that you shared from, we think it Socrates, that true knowledge is knowing that you know nothing. I think that's really important, every day is starting from day one, isn't it? De-stigmatizing failure. The origins of the word deadline. I did not know that. That's really interesting. And just asking that simple question, how did that feel? How did that feel working in this way? People were screaming your name, walk up work, when work's too busy, how does that feel? And is that a healthy feeling that everyone should have? So that's really important questions for me to reflect on and I know our audience will really appreciate those questions as well. So thanks so much Chris, for joining us on the Easy Agile Podcast.

    Chris Stone:

    Not a problem. Thank you for listening and a Merry Christmas, everyone.

    Sean Blake:

    Merry Christmas.

  • Podcast

    Easy Agile Podcast Ep.9 Kit Friend, Agile Coach & Atlassian Partnership Lead EMEA, Accenture.

    "From beer analogies, to scrum in restaurants and neurodiverse teams, it's always a pleasure chatting with Kit"

    Kit talks to agile methodology beyond the usual use case, like working with geologists & restaurant owners to apply scrum.

    Kit also highlights the need to focus on a bottom-up approach, providing a safe space for leaders to learn & ask questions, and whether neurodiverse teams are key to effectiveness.

    This was a really interesting conversation!

    Be sure to subscribe, enjoy the episode 🎧

    Transcript

    Nick Muldoon:

    G'day folks. My name's Nick Muldoon. I'm the Co Founder and Co CEO of Easy Agile, and I'm delighted to be joined today by Kit Friend from Accenture. Kit is an agile coach at Accenture and he's also the Atlassian Practice Lead there. Kit, good morning.

    Kit Friend:

    Morning, Nick. Sadly only the Practice Lead for a bit of things, but I try my best. It's a pleasure to be with you, for the second time we've tried this week as well, in the lovely world of broadband dependent remote working and things. But here's hoping, eh?

    Nick Muldoon:

    It's beautiful, isn't it? Now, for those of you at home listening in just so you've got a bit of context, Kit is a father to two, he lives in London, and he's been at Accenture now for a little over 10 years, right?

    Kit Friend:

    Yeah, September, 2010. Fortunately I met my wife in pretty much the same summer, so I only have to remember one year, and I can remember one by the other. So it helps when I'm trying to remember dates, and sort things through because I'm not very good with my memory, to be honest with you.

    Nick Muldoon:

    Oh well. So for me, the reason to get you on today, I'm super excited to hear about the journey that you've been on in Accenture, and I guess the journey that you're on with your clients, and on these various engagements. Before we dive into that though, I wanted to know, can you just tell me what is one of your favorite bands from the '90s, from the early '90s?

    Kit Friend:

    Yeah, and I really enjoy that we had a delay between things, because it's like one of those questions, because I'm like, "Hmm." And I think I'm a victim of playlist culture, where it's like naming an entire band feels like a real commitment. It's all about tracks now with things, right? But I have narrowed it down to two for my favorite 90s band and I think I'm going to commit afterwards. So my undisputed favorite 90s track, Common People by Pulp, right? Hands down, yeah, it's right up there. For me, I studied at St Martins, the Art College, so for me Common People is the karaoke track of my university days with things there. So Common People by Pulp, favorite track.

    Kit Friend:

    For bands wise though, I was split between... Initially I went Britpop, I was like, "Cool, that feels like a happy place for me." Particularly at the moment in our weird dystopian society, I listen to Britpop and it's kind of happy. So Blur was right at the top for me for band commit of the 90s thing then. But then I remembered that Placebo is actually technically a 90s band, even though I did not listen to them as a 13 year old Kit and things. So I think Placebo edges it for me on favorite 90s band of things, just about. But I do have to admit, even though it's not my favorite 90s track, I do think Wonderwall is perhaps the best song ever written.

    Nick Muldoon:


    Oasis? Love it.

    Kit Friend:

    Yeah, for track wise. But for me particularly I was at Oktoberfest with some colleagues a couple of years ago and I don't think any other track could get 600 drunken Germans up on benches together with everyone else, all the way around from the world, with a rock polka band singing at the top of your voices at 11 o'clock at night or something. So yeah, that smorgasbord, but I'll commit to Placebo for favorite band in that weird caveated sentence.

    Nick Muldoon:

    I love it, thanks for that, Kit. And so it's interesting because you touched on then that you went to St Martins, which was an art college. So I'm interested to know, what did you study? What are your formal qualifications and then what led you into this world of Agile delivery and continuous improvement?

    Kit Friend:

    Yeah. I mean to do the Twitter bio caveat that all the opinions are my own and not Accenture's before we go down the journey of things. Although it must be said I am trying to convert as many of my colleagues and clients to my way of thinking as possible. But so I studied St Martin or studied at St Martins College, so in the UK certainly, I don't know what it's like in Australia, but when you go and do an art and design degree they basically distrust your high school education. They're like, "Nah, everything you've done before is..."

    Kit Friend:

    So they make you take what's called, or they advise you to take what's called a foundation year where you try a bunch of stuff. So you come in thinking you're going to be a painter or a product designer or something, and they're like, "No, no, no. You haven't experienced the breadth of the creative industries and things." So I did one of those, which was amazing, and I came in thinking I was going to be a product designer. Ended up specializing in jewelry and silversmithing and things, so I made like... Yeah, sort of wearing long black trench coats and things, I was making gothy spiky armor and all sorts of things, and [inaudible 00:04:24] work with silver. So I do have a Professional Development Award in Welding from that year, so that was my first formal qualification on that. I'm a really bad welder though.

    Kit Friend:

    Then at the end of it I was like, "I don't really know what I want to do still." As you do as you go through university, so my formal degree title, adding to my trend of very long unpronounceable things, is, Ba Hons Art And Design And The Environment, Artifact Pathway, and what it was was... Your face is-

    Nick Muldoon:

    Yeah, I'm trying to process that.

    Kit Friend:

    Yeah. I think the course only existed for three years, it felt like a bit of an experiment, or it only existed in that format. So we had architecture students doing the first part of their architectural qualification, we had what were called spatial design students who were, I think, designing spaces. They weren't interior designers, they were a bit more engineery and then we had this weird pathway called Artifact, which was the rest of us and we weren't quite as strict as product designers, we weren't artists. We were making objects and experiences and things.

    Kit Friend:

    Yeah, it was a really interesting experience. I mean towards the end of it I began specializing more and more in designing ways for communities to come and build things and do stuff together, and it's a bit weird when you look backwards on things. You're like, "I can directly trace the path of the things I've done since to that sort of tendency [crosstalk 00:05:54] liking bringing people together."

    Nick Muldoon:

    So yeah, do you think that community building aspect was kind of a genesis for what you've been trying, the community around Agile transformation you've been developing over the past decade, or?

    Kit Friend:

    I don't know. It's easy to trace back to these things, isn't it? But I guess I've always-

    Nick Muldoon:

    You don't see it at the time.

    Kit Friend:

    ... liked bringing people together to do things. No. It's a theory anyway, isn't it? An origin story theory as we go. So I did that and then I complained lots about my course, I was like, "This is rubbish. This is all really random and things." So I got elected as a Student Union Officer, so I don't know how it works in Australia but in the UK you can be elected as a full time student politician effectively, and you can do it... You take sabbatical either during your course or at the end of your course where it's not really a sabbatical. So I was the Student Union, served full time for two years after I finished my degree, which is a bizarre but educational experience.

    Kit Friend:

    Again, it's about organizing people, like helping fix problems and having to be very nimble with... You don't know what's happening the next week, you're going to protest against unfair pay or you're going to have someone who's got their degree in trouble because of their personal circumstances and things, so it's a really interesting mix. So yeah, that's where I started my journey into things.

    Nick Muldoon:

    So it's interesting for me, because you talk about this, the early piece of that is, "We don't trust anything that you've learnt prior to this and we're going to give you a bit of a smorgasbord and a taste of many different aspects." How does that relate to an Agile transformation? Because I feel like we went through a decade there where an Agile transformation was literally, "Here's Scrum, do two weeks Scrum, story point estimates, no rollover. If you rollover we slap you on the wrists."

    Nick Muldoon:


    There probably, 10 years ago, there wasn't a lot of experimentation with different approaches to delivery. It was just, "We're going from this Waterfall approach to this Agile approach." Which back then was very commonly Scrum. Why don't we give people the smorgasbord and why don't we give them three month rotations where they can try a bit of Scrum and a bit of Kanban and different approaches?

    Kit Friend:

    Well, I guess it's practicality, isn't it? These things. It's a challenge, and it's a challenge, it works within a contained place. I teach a lot of our product container courses for our clients and we always use the David Marquet video of Greatness Summary. What's great about the David Marquet situation, he's got this Petri dish, right? Literally a submarine, aint no one interfering with his submarine crew. So he can do that, he can go, "Well, let's try this thing." I vastly oversimplify because it's an amazing story, right?

    Kit Friend:

    But you've got that space to do something and try something out, and actually when we do talk to clients and colleagues alike about Agile transformations, I think one of the things that I say consistently in terms of the role of leadership is they do need to create a safe space, a little place where they protect and they're like, "In this space we're doing Agile, we can experiment, we can do these things. Leave my guys alone. Trust me within that."

    Kit Friend:

    I think where I see Agile going well, it is where there is a bit of that safe space protected to do things. I've got colleagues who work in companies where they go like, "Okay, we're going to try now and all we're going to ask you to do is forecast your next week's volume of stories. Everything else is up to you, you can choose to apply Scrum, you can use Crystal, DSDM, whatever it is. All you have to do for us as a company is give us a high level view of these metrics or something." So there's flexibility. I think when I think about your journey as an Agilist and trying to do things though, people saying try a bit of everything, it's lovely advice but it's a bit difficult to actually do because it's like we still need to make things, we still need to do stuff practically.

    Kit Friend:

    So when I talk to people who are starting off their journey or both clients and colleagues who are wanting to move through things like that, like what do they do first, I still say Scrum is a really good place to start because I think there's that quote from somewhere, it's probably in the Scrum Guide, about, "It's simple to understand but complex to get right." And you would think with complex and chaotic situations, right? But I think that-

    Nick Muldoon:

    And the discipline required is-

    Kit Friend:

    Yeah, yeah. But discipline's a good thing, right?

    Nick Muldoon:

    Mm-hmm (affirmative). But not everyone has it.


    Kit Friend:

    No. But one of my colleagues, Nick Wheeler, he uses the phrase, "Too many beanbags, not enough work done to talk about Chaotic Agile." I think you've got to have that focus on getting things done, right? Value delivery has got to be there, as well as it being a pleasant working atmosphere and balance. So it's about somewhere between the two, and I like Scrum because it gives people something too... It's a framework, right? It gives people something to hang off to start their journey, otherwise I feel like you could spend months debating whether you have an Agile master and what do they do? Where do we go? Do we have a person who holds the vision and things?

    Kit Friend:

    I think when people are starting off I always say, like, "Why not try Scrum? Why not see? Try it for a couple of sprints and see what works for you and then see what comes out in the wash." I mean if they're in an area where there's some fundamental contradictions, like, "Yeah, I'm not going to force sprints on a call center, right? It doesn't make sense." I was talking to someone yesterday who works on a fraud team, and it's like I'm not going to ask her how much fraud is going to be committed in two weeks time, or as part of MPI, right? It's absurd.

    Kit Friend:

    So in those circumstances, yeah, you start with Kanban methods and processes and practices instead. But for people who are building products, building things, I think the Scrum is a pretty good fit at the beginning. So yeah, that's my answer, so both. Why not have both is the answer to that, I guess, on the way. Yeah. It'd be interesting to see what other frameworks rear their heads. I mean I found the other day a scaled Agile framework called Camelot that involved lots of castles and things in the YouTube video. I thought that was marvelous. But there's room for a lot of planning and thinking.

    Nick Muldoon:

    As soon as you saw Camelot, for some reason my mind goes to Monty Python. I don't know quite why. But what's this flavor of scaled Agile called Camelot? Can you tell me about it? Because I'm not familiar with it.

    Kit Friend:

    I've seen one YouTube video on it, Nick. For anyone Googling it, you can find it related to the X Scale Alliance. I think it's a picture of the Monty Python Camelot on the front page.

    Nick Muldoon:

    Is it actually?

    Kit Friend:

    Yeah, yeah. I'm pretty sure weird things. And you know what it's like with techy geeks, right? There's a lot of embedded Hitchhikers' Guide To The Galaxy and Monty Python references in component names and things. So I'd be unsurprised. What I like about something like the Camelot model, other than me thinking Monty Python and castles and things, is it does evoke something in people. I think when we're talking to people about Agile we do need to evoke a feeling with them. We need to get people going, "Oh yeah, I kind of get where you're going."


    Kit Friend:

    So I always like to do the cheesy uncapitalize the A, what does agile mean to you? Yeah, is it about being nimble? Is it about being flexible and that kind of thing?

    Nick Muldoon:

    I mean I'm conscious you've obviously done Lean Kanban in university, you've done Scrum Alliance Training and Certification, Prince2, Scaled Agile of course. Why do you do all these things? I mean is it curiosity? I mean is it there's an expectation from clients that you have these certifications? And would you go and get a certification in Camelot? Or even one that I was introduced to recently was Flight Level Agile, Flight Level Agility. Which is a different way of-

    Kit Friend:

    Ooh, another one?

    Nick Muldoon:

    Yeah, another one. A different way of describing. Actually I remember, bit of a sidebar sorry, but Craig Smith from... who was at the time I believe was working at Suncorp, an Australian bank. He did 46 Agile methods in 40 minutes or something like that, and he spent a minute and he introduced people to all of these different approaches.

    Kit Friend:

    Yeah, and methods versus frameworks and things is a fun one to draw the lines between. I mean I've been surprised actually how few times I've been asked for certifications around things. It's changing a bit more, and I've seen definitely more enthusiasm from our clients, and in fact I'm seeing new people within Accenture which is really nice, to require and encourage certification. I don't think it's necessary that the safe course then guarantees that you're going to scale Agile successfully, right? But it's a good way of demarking whether people have done their homework and have put some effort into [crosstalk 00:14:50] knowledge.

    Nick Muldoon:

    And they got the foundational baseline stuff.

    Kit Friend:

    Yeah. Now in terms of your question around Brett, so my view is that if we try and attach the word coach to ourselves... I think I've seen country by country different trends, so when I look at my colleagues in the States there's a bit more codifying on the term Agile Coach. There's an attachment to ICA Agile and Lisa Adkins work and all sorts of different things over there which is good. Certainly in the UK and Europe, I see it as a lot more varied at the moment and it's a term that's attached to a lot of people.

    Kit Friend:

    If you look at people, just anyone on LinkedIn with a CV title or little bio title Agile Coach, you can see a big variety of people who've been doing different Agile frameworks for like 20 years doing things, and you can see someone who's been a Scrum Master for three months and then switched jobs, and they'll have like Agile Enterprise Coach as their title. And you're like, "Hmm, how many people have you ever done Scrum with? And have you done anything but Scrum?" And my view is if 40-

    Nick Muldoon:

    But I mean Enterprise Agile Coach because I've done Scrum with my team of six people in a-

    Kit Friend:

    In an Enterprise, right?

    Nick Muldoon:

    In Enterprise.

    Kit Friend:

    But my feeling is if all you can do to a team that you're coaching is offer one way of thinking and one approach to doing stuff, how are you coaching them then? There's no breadth to what you're able to offer. But if all you've experienced is Scrum and then you get landed with a team doing fraud investigation, how are you going to guide them on a path which doesn't include sprints and those things? I mean you might do, because you're going to take things from Scrum that become sensible, but you need that spectrum.

    Nick Muldoon:

    Give us a sense, Kit, what is the most quirky, or unusual perhaps is a better way to frame it, what is the most unusual team that you have introduced to Agile practices and Lean principles?

    Kit Friend:

    So I've got to embarrass my colleague Giles, because mine is not the most interesting. So Giles was looking at introducing Scrum to geologists for site surveying and things, which I love as an example to talk about because it's so-

    Nick Muldoon:

    Wow. Yeah.

    Kit Friend:

    When you unpack it's so interesting to think about what that would mean, and I need to catch up with him to see how far through they got actually applying it. But because it's like, "Why would you do that?" And then it's like, "Ooh, actually, they probably have a really big area to survey. Wouldn't it better to introduce some feedback loops and look at how you slice down that problem to get some value and learning delivery out of things?"

    Nick Muldoon:

    That's interesting.

    Kit Friend:


    So I really, really like that. Yeah. Then I always reference when we're teaching, there's a restaurant called Ricardo's in London that I have to make sure it's not gone out of business. I think it's still in business, but-

    Nick Muldoon:

    Well, I thought it-

    Kit Friend:

    Well, COVID, right? I think he's their owner, Ricardo. At least he's the person that's inspired their name. He applied Scrum and it's beautiful, looking at the exercises they went through when they put it in place. And on his website, which I'll ping you the URL for the show notes, but they do this cross functional teaming thing where they got all the staff at the restaurant to look at the role types that they needed, and then their availability and things. They were like, "Only this one guy can do the bar. Maybe we should up skill some other people to be able to work on the bar?" And I love that thinking of applying those elements of stuff.

    Kit Friend:

    So back to your question though of where have I applied unusual things to my teams, I haven't done any really quirky ones, to be honest with you. I mean I think having a background in art and design I find it... When I talk about iteration and all those areas, my mind immediately goes back to projects where we made things and did stuff and have it there, and particularly when people get panicked in a business situation I think back to... I used to freelance doing special effects with my dad whilst I was at university, because it's a great way to make cash for things. My dad worked for the BBC and freelance. I think about that immediacy and panic when I'm talking about Kanban and handling ops and incidents and things, and I'm like, "You guys don't need to panic, it's not like you're on live TV." And they have a countdown of three, two, one, right?

    Kit Friend:

    No one has that in our business. We panic sometimes when something falls over, but there's never that second by second delay. So I think the quirkiest places that I've applied Agile thinking are probably before my career in technology. They were in that kind of place where we're making creative things and doing stuff, and it's there where you're like, "You would never do a 400 line requirements document for a piece of product design or jewelry, right?" You would produce something rough and see what people think about it, and build things in so there's a balance there.

    Kit Friend:

    I mean when you're launching live products though, you do some strange things, right? And you have some fun memories from that. So I remember when we launched YouView in the UK, which is a public credential because it was for Accenture. Fine. But during launch day a colleague of mine, Ed Dannon and me, we became shop display people for the day so we were at the top of John Lewis in Oxford Street in London demonstrating the product, and that was a part of our Agile working for that week because that's what they needed. That was how we delivered value was physically being the people going like, "Hello, Mrs Goggins. Would you like to try this YouView box at the top of things?" So I remember those days fondly.


    Nick Muldoon:

    And so was that capture on a backlog somewhere, or?

    Kit Friend:

    Do you know what? YouView is where I was introduced to my love of dura, so I suspect, yeah, I don't think we did formally add a backlog somewhere. It would've been nice too, wouldn't it? I'd like to claim that my entire Accenture career could be constructed out of Dura tickets if I piled them one on top of each other for 10 years. Certainly about a 60%-

    Nick Muldoon:

    How many Dura tickets do you reckon you've resolved over the years?

    Kit Friend:

    God. How many have I duplicated is probably the question, right? Which is like 8,000. There's always duplicate of things. It's got to be in the thousands, hasn't it?

    Nick Muldoon:

    Tell me, you've, okay, over thousands of duplicates resolved. But you've been doing this for a while in the Atlassian space, and obviously with the Agile transformations at scale. How have these engagements at scale evolved over the past seven or eight years? And what do they look like in 2021 with this completely remote mode of operation?

    Kit Friend:

    Yeah. Starting at the end of that, I see light, I see goodness in things. But I guess similar to how you expressed 15 years ago, 10 years ago everyone was like, "Do Scrum and have some story points and things." I think during that period, if we go back like 10 years ago, so we're like the early 2010s or whatever we call the teens in the decades, I think we see a lot of people experimenting with early versions of SAFE. They'll do wheel reinvention and people simultaneously going, "Let's have a big meeting where everyone plans together. How do we normalize story points? You shouldn't, maybe we should. How do we do metrics there?" And that kind of stuff.

    Kit Friend:

    So I think certainly what I've seen is a lot of people trying out those things as we go through, and then trying to weave together concepts like design thinking and customer centricity, and there are all these bits of stuff which feel good, but they weren't very connected in any way that was repeatable or methodical or codified. Then what I quite enjoy, and linking back to your last question, is then the branching of the approaches to things. You've got SAFE, which is laudably to everyone who works on that, right? They try and write down everything.

    Kit Friend:

    I always say this to everyone, you're like, "Thank goodness someone decided to go on that website and make everything clickable and everything." Because when you do need to reference one of those elements, it's a godsend being able to go and go, "Yes, here is the page that talks about Lean budgets. I might not agree with everything on it, but it's a really good starting point. It's a really good point of reference to have."

    Kit Friend:

    Then you've got the others, and I do use SAFE at one end of detail, and even if you're doing SAFE correctly you don't do it by the book and copy and paste, right? And that kind of thing. But there is a lot of detail and a lot of options there. At the other end of the scale you've got things like Less, where it's intentionally about descaling and it intentionally focused on simplicity. Look at the front pages of the website, and on the SAFE website you've got everything. On the Less website it looks like we've done it on a whiteboard, right? And that's intentional, both of them are intentional at the end of the scale. Then we've got Scrum on the scale, which seems to be the new, rising, kind of darling of things at the moment, and that was the other thing. So what I see now-

    Nick Muldoon:

    And they all have a place, don't they?

    Kit Friend:

    Yeah.

    Nick Muldoon:

    It's interesting that there's a large enough audience and market for all of these to succeed, and there's a lot of overlap between them in the various ideals and practices that they suggest that you experiment with.

    Kit Friend:

    Yeah. I mean what I've seen in the past few years is that I think people often get laudably enthusiastic about the scaling bit. So they take a look at a word like Lean Portfolio Management or a business problem they have of how can I capacity manage? And they go straight to the scaling frameworks without stopping at the teams on the way, and that's definitely a tendency I hear more and more from friends, colleagues, geeky friends, colleagues, clients, right? They don't make that initial investment in getting the teams going well, whether it's Scrum or whether they're running in anything else.

    Nick Muldoon:

    Sorry. But hang on, are you saying then, Kit, that people are actually coming into a scaled Agile transformation and they haven't got the team maturity? Sorry, forgive me, but I felt I guess my belief and my understanding was that these scaled Agile transformations, for the most part, are building on top of existing successful team transformations.

    Kit Friend:

    I think that is how it should work right. We should be going bottom up, or at least to a certain extent. In the SAFE implementation roadmap it talks about reaching a tipping point and having... I mean you can start with Waterfall and the SAFE implementation roadmap, but it talks about ad hoc Agile and those things there. I think when people in large businesses and organizations come with a problem though, they're coming with a big problem and they want to fix that, and yeah, it's a difficult message to land, the, "Hi, you've got one to two to five years worth of getting your teams working before you can deploy the fancy portfolio management Kanban and see a flow of things right." Because people are nice. Most people are nice, most people are enthusiastic, most people want to fix things, and so they want to fix that big scaley thing.

    Kit Friend:

    But it's difficult to land, the, "No, you've got to fix these things at the bottom." I was describing to a colleague, Lucy, last week, and I said, "If you want an answer a question of how do I capacity manage and how do I balance demand across a large organization, you should imagine each of your..." Let's pretend they're Scrum teams without debasing it for a moment. Let's pretend your Scrum team is like a bar with a row of different glassware on it, and each time box is a different sized pint glass or a schooner or whatever you have. Now, my capacity management for a single team is me with a big jug of beer and I've got all the work that I want to do in that beer. My whole backlog of things. My capacity management for a team is pouring it in and hopefully I guess it right. I probably don't and I spill some beer in the first ones as we go through. But over time I'm trying to guess how much beer I can pour into each time box of things and we go through.

    Kit Friend:

    Now, the only way that I can know how much I can fit in in the future is if I see what I've got in the past, like how it went and can I predict the size of the glass, and over time I can, and we stabilize. So everything's a pint glass after a while, after we've experimented with everything there. Now, if we don't have that ability to forecast and measure, get the actual data back via some tooling at a team level, how can we manage across multiple teams? Right? You can't. You can't have a big top down roadmap where you're like, "Yeah, we want to launch the easy Agile bank across all these areas and go into the teams." Unless you have that team level maths that you can rely on.

    Kit Friend:

    It doesn't matter whether that's story points or whether you're doing no estimates stuff and you're just measuring flow or you're using Monte Carlo, whatever it is. You need some mathematical way of helping people understand the flow of work and what's happening there, and ideally tying it back to value with some data. Workout whether is your easy Agile bank actually a good idea or should we pivot and do something else? Yeah, is it delivering the thing that customers want when we've given them easy Agile bank beta at the beginning of things.

    Nick Muldoon:

    How good do you think clients are these days? So here's the thing, I guess, you talk about early transformations and it was, "Hey, we're going to go Scrum." But now there's the design thinking, I mean there's devops, there's DevSecOps, there's so many different aspects now that people are exploring and they're exploring at the same time. How do you help the client navigate this? Because they get it from every different angle from different aspects of the business, and in fact it's just got to be overwhelming, quite frankly.

    Kit Friend:

    Well, it's overwhelming for us trying to help right, right? People like yourselves, I mean you're like, "How do we cope with this weird specific configuration that they want to feed into easy Agile programs?" So I think that the light at the end of the tunnel that I referenced before is I see a lot more people coming with an ask of helping them get the bottom up things right, so they understand there's a pincer. We can't ignore-

    Nick Muldoon:

    Get the foundation.

    Kit Friend:

    Yeah. But we can't ignore that there's the big business, right? There's the people expecting big things and they've drunk the Agile Kool-Aid, they've read the article and they want to be there. So there is that top down pressure, but I am seeing more and more asking for advice and help to do things at the bottom. On a couple of areas recently, my current theory of the day, and I have a favorite theory every six months or so so this won't be the same later in the year, but I really, really like training the product owners first to help with that transformation. My current theory is that it's because they're like the battering ram to help the business understand what's happening with these delivery teams, and build the bridge and link between things and form that.

    Kit Friend:

    Because if you don't have the product owners being the conduit and the voice of the business and the customer and the voice of the team back to the business in doing things, I think the rest of it falls down. So my theory at the moment is that if you start by training the product owners that's the best way to begin things and it helps with the scaling body scaling, the focus on the team level to help do things.

    Kit Friend:

    To be honest, even if they're not doing Scrum, I think that the role of a product owner, relatively close to what the Scrum guy says, if we take out the sprint references and things, I think that's a sensible thing to have in every cross functional Agile team, regardless of what you're doing. And it's a distinct personality type, right?

    Kit Friend:

    I often talk when people are doing our Agile Foundations course, where we're like, "Here's everything. Find your place." I think that most people, or certainly most people I train, fall quite clearly into a product owner or a Scrum Master style personality type. I'd say about 80% you can tell, like, "You're a producty person. You're a Scrum Mastery type person. Or if you're not doing Scrum, a coach, a facilitator, a team builder." Maybe about 20% can flit between the two, and they're special people. The Unicorns as we have in every industry and type, but most people fit into one of those. I think it's good to think about how those personality types work in your business.

    Kit Friend:

    The other thing I love about training the product owners first, it really unveils upon them that, let's say, we're now at... "Hi, Nick. Yesterday you were the business owner for this process and doing things. You're now a product owner, go. And you can only have till Monday." If we train you, you're like, "Oh my God, I didn't realize I was now accountable for the value of this whole team delivering. It's my problem to make sure they're delivering good things? I didn't know that." So if we do that training right at the beginning I think it sets a baseline of expectations of what we're asking of those people, and the responsibility that's placed on them. Yeah.

    Nick Muldoon:

    When you're doing this Agile Foundations course that you run for folks through, are you doing a DISK profile as part of that? Again to assess their personality type.

    Kit Friend:

    No, no. That would be really good. What a great suggestion. I can include that.

    Nick Muldoon:

    Well, I'm merely inquiring because I wonder. I'm just thinking about it now, I'm wondering, are there personality types that are more likely to be the product owner? Is a product owner more of a CS and is a... Yeah, I don't know.

    Kit Friend:

    I don't know. I mean it's one of those things, isn't it? I forget the number of personality types and roles I've been assigned in various bits of my career. I can't remember. Back when I was a Student Union Officer, I'll have to look up the name of it, but we had the ones where, "Are you a completer finisher or a shaper?" And all sorts of those things there, and then DISk was relatively popular. We've got a Gallup Strengths Test within the Accenture Performance Management Tool, which is actually really interesting.

    Kit Friend:

    The bit I like about the Accenture one is when you join a new team you can bunch yourself together in the tool and see what people's different strengths and personality traits are, so you can be like, "This team's very heavy on the woo. Or you're a team that's full of energy or ideas with things, and it's quite interesting too." I mean it's nice to see the strength, but it's also interesting to notice where you might have gaps and you're like, "I need to make sure that someone's keeping an eye on quality because we all get very excited and run fast."

    Nick Muldoon:

    Do you remember, this would have to be a decade ago now, I'm sure, but I think his name with Larry Macaroni or Larry Macayoni, and he was working for Rally Software at the time, and he did a very wide ranging study of the effectiveness of Agile teams? And I'm just thinking back on that now, because he was looking at things like defect rates, escaped bugs versus captured bugs and all sorts of other bits and pieces. But I don't think he touched on the personality traits of these teams and whether even Dave the Cofounder here at Easy Agile, my business partner, he was talking. He shared a blog article this morning about neurodiverse teams and I'm just trying to think, do we know is there a pattern of DISK profile distribution, neurodiversity distribution, that leads to a more effective team?

    Kit Friend:

    I don't know. I haven't read. Yeah, it's Larry Maccherone, but it's not spelt the way I suspected originally. I put in Macaroni, based on your pasta based pronunciation of things. So it looks like it's the quantifying the... What's it called? Quantifying the Impact of Agile on Teams, which is really interesting.


    Nick Muldoon:

    But I don't know if that sort of study has been done since he did it back then.

    Kit Friend:

    Particularly the personality types is interesting, and neurodiversity is another interesting element. So I've got dyslexia and dyscalculia, and one of the bits I've found-

    Nick Muldoon:

    What's dyscalculia?

    Kit Friend:

    Well, just like dyslexia, there's quite a spectrum covered by one term of these, so it's large. But effectively my particular diagnosis, I have problems processing sequences of numbers. So you can read me out a sequence of numbers and if it's exactly that, I can cope with it normally because I can do visual processing, because that's my creative industries background, it's what we do, right? We visually process. But I can't repeat them back to you backwards, I can't reprocess them as units of stuff with things. My wife says-

    Nick Muldoon:

    How did you even come across that?

    Kit Friend:

    So a retrospective again, so my sister was diagnosed with dyslexia at school, and she's got a more traditional dyslexic diagnosis. So when you hear dyslexia, people normally associate it with not being able to read and spelling and grammar and that kind of stuff. Dyslexia, as you might know from [inaudible 00:35:00] is actually... I'm waiting for them to split it, to be honest with you, because it's so broad. But my diagnosis of dyslexia is more about my short term memory processing, so it's the ability to process. I can read and write fine.

    Kit Friend:

    My sister got diagnosed at school, had blue glasses, all the conventional grammar and spelling related elements of dyslexia. My dad got diagnosed then in his mid 50s, I think at the time. So he started working at the University Arts London, my art college, my dad still runs the woodwork shop in central St Martins in their beautiful new campus in King's Cross in London. He got diagnosed with things, and I was like, "Hmm. I know it's hereditary, I should probably get checked." So I think I was 25 or 26, and one of the lovely bit... I mean there's many lovely bits about working at Accenture, but a large corporation has really, really good support networks and things.

    Kit Friend:

    So I pinged the right people around, and they were like, "Yes, of course we can support you getting an assessment. We'd love to make sure that you're able to function." So I got an assessment done and they were like, "Yeah, you're dyslexic and dyscalculic on this kind of area." But the more interesting thing was that they were like, "Here's the coping mechanisms that you've developed." And the coping mechanisms was a list of my career and choices and education. It was like, "You will choose things where you can do abstract thinking and drawing." It was really funny because I never felt like it blocked me at school, I quite enjoyed exams and things.

    Kit Friend:

    But I was terrible at revising, right? I can't go through notes and do things there. Looking at my diagnosis I was like, "It's because I don't process things that way." I have to process things visually, I have to draw, I have to chunk things. Now I look at the way that I work with Agile teams and I coach teams, and I create abstract references to things, right? I'm teaching product owner and Scrum Master courses on Mural where we move things around and create objects.

    Nick Muldoon:

    Or the example that you used before, Kit, with the beer glasses at the bar.

    Kit Friend:

    Yeah. I can't deal with numbers in abstract, right? I have to deal with them in an analogy or I have to be able to visual them. I'm hopeless at coding, I can't store concepts like variables in my head. They just fall apart, it's like building with sand in front of me and it's all dry and crumbly. And I think in fact when I looked at that diagnosis and I was still, what? I'd be like three or four years into my career at Accenture. I looked at the way that I'd begun to get slowly addicted to tools like Atlassian and Dura, and I was like, "Ah, I'm compensating for the fact that I have basically no ability to memorize things in the short term." I'm helping visualize stuff in the way that I help teams and build tasks and things, in a way that means I'm outsourcing my short term memory to this lovely tool where we do things there.

    Kit Friend:

    Yeah. I've grown to love it, I think you have to work with it right. I speak to some of my colleagues, I teach at the moment with an Agile coach called Lucy Sudderby and another one called Charlotte Blake, and I'm like, "Thank you, guys, for compensating for my dyslexia. I appreciate that you kind of balance out my inability to memorize anything." Yeah, hopefully they feel they benefit from some of the quirky strengths of it when we go through, but it's a balancing act, right?

    Nick Muldoon:

    That's very cool. Thanks for sharing that.

    Kit Friend:

    No worries.

    Nick Muldoon:

    I'm just thinking about it now, as you mentioned coaching with Lucy and Charlotte, and going back to something that you said earlier, Kit, with respect to... I don't know if you said the leaders, but basically the folks at the top drinking the Kool-Aid. I'm interested to know, how do you create, going back to this other thought that you had, I'm trying to connect dots, going back to this other thought that you had right up at the top about the psychological safety, right? And that feeling safe. How do you provide a safe space for these leaders that could be CEOs of business units or execs, GMs, whatever they happen to be, provide a safe space for them to actually ask questions and do Q&A and learn without feeling?


    Kit Friend:

    Yeah. Because we forget that they're people too, right?

    Nick Muldoon:

    Yeah.

    Kit Friend:

    There's this idea that these leaders are somehow insurmountable, they have no fear. But we need to build a safe space for everyone around things, I think you're right. I think we get the same sort of question when people talk to me about how they can convert people to Agile or make the case for things in an organization but not sure about it. I think that the answer, relatively saying, in that we need to give them some data, some facts. So my view is that it's not good to come to people and talk about...

    Kit Friend:

    I somewhat cynically criticize when people talk about Agile ways of working, and they'll often abbreviate it to WAW or something as well. I think when we talk about agility too abstractedly, and I say the phrase wavy hands too much, but when we talk about it within specifics too much, it encourages a sense of anxiety and it's a nebulous, wishy washy kind of thing so I like to bring some data to people. My favorite ones to use, and I need to get updated stats, but the Sandish Chaos Reports are an amazing project management journal, where they talk about success and failure of Waterfall versus Agile projects.

    Kit Friend:

    Now, there's a bunch of questions it leads you to about how do they classify Agile and all sorts of things. But indisputably, what it tells you is that the traditional way of doing things that we are told is secure and safe, if I go to a procurement team or a finance team and I go, "I'd like to build this thing, guys." They're like, "Great, give me the milestones, give me the plan." And there's this inbuilt assumption that that's a safe and responsible and proven way to do things.

    Kit Friend:

    The Sandish Chaos Reports tell you it's a terrible way to do things, right? They're like, "Statistically, doesn't matter what you're building, what industry, what you're doing, it's a terrible idea to fix scope at the beginning, trust your plan and have a system which fails when you have any change." And when you unpack it, like when we talk about agility overall, what are we saying? We're saying it's not a good idea to begin something and for it only to be able to succeed within fairly tight boundaries, where no one changes their mind for the duration of the thing, everything goes exactly as you plan and when does that ever happen with technology? And the world doesn't change for the duration of your thing.

    Kit Friend:

    Most of the time when we're talking about these project things, like how long are they? Three months to three years is the window I usually give. Three months, I see rarely in any industry these days, right? These big efforts where people are trying to do these things at scale, you're talking multiyear. What are the chances that the scope can be frozen for that period? Pretty low, and also what's the chance that the people that you asked for the requirements at the beginning really knew them all? Everyone's normally really nice, they try their best.


    Nick Muldoon:

    The chance that the people you ask at the beginning are going to be there when you actually get to the next-

    Kit Friend:

    Yeah. There's a whole set of fundamental problems with that. So I like to bring that kind of data to our leaders when they're asking about the case for agility, so it's not about, "Do you want to sign up to use a framework?"

    Nick Muldoon:

    But let's say, Kit, that they've made the case for agility, they're there, they're doing it. What's the space that you provide for them? Do you have a CEO round table where they can go and they've got a shoulder to cry on and go, "This Agile transformation is going harder than I thought it was going to be"?

    Kit Friend:

    Agilists Anonymous, [crosstalk 00:42:19] company. Yeah. I think it is a good idea to pair them up, so I get a lot of requests at the moment for us to provide coaches directly to support leaders. I've also seen a trend in reverse mentoring, separately big companies. But that kind of idea of, okay, you've got these people who are really experienced, and their experience is relevant, right? We're not saying that the CEO's 30, 40, 50 year career in something is invalid now and we know better than them. But they're trying to match that up with these, not even emerging, right? Because the Agile Manifest is 20 years old now. But they're trying to match these up with these foreign, new practices and things they've got, and that requires a bit of hand holding. So yes, there's a personal angle there. I don't think necessarily a round table is the way to do it per se, but giving them someone that they can chat too and, yeah, an ability to relate and go like, "What is this thing?" And decode the jog, I think is really useful.

    Kit Friend:

    So data about success rates is important, right? But the other data that's really important I think to help provide that sense of safety is about value delivery, and this is where I think most people are still having trouble. We've just about got to the point where people can start to attach a concept of benefits and value at the start of things. Now, often that's still too big. We talk about the value of the entire project, can you assign a notion of value to every epic and story in your backlog or whatever units of stuff you're doing?" Probably not, right? Can you do it in a pound or dollar or euro or whatever your local currency is figure? Probably not. But can you even rank them one to 10? Maybe with things.

    Kit Friend:

    So I think the evolution of OKRs and KPIs coming in, and people starting to internalize that more, offers some hope. It's still relatively immature in most organizations and you're still kind of getting there. I feel like every sort of practice and things, it's probably going to have some misinterpretation, enthusiastic and well meaning interpretation, but you're going to get some people using it somehow to Waterfall things probably in some areas. But bringing that data that gives them some sort of feedback loop that makes sense to those people in those senior positions I think is really powerful. The opposite of this is where they expect to see RAG statuses and milestones and that's the only data they get from their teams, right?


    Kit Friend:

    I sat down with an executive of an organization a few years ago and I was like, "Please invest in your tooling. Please do it." And he's like, "Why would I need to? I have these slides where they tell me green and the dates are there." And I was like, "I love that you're trusting, and I like to trust." The trust in the teams was really, really good. But I knew the teams and I knew they didn't have any tools. It was project managers getting stressed and running around, and then I knew that all the RAG statuses were going to go, "Green, green, green, green. Red." It was the Watermelon Effect that was going to happen, right?

    Kit Friend:

    So when I see conversations like that happening, I want to empower them. I want to empower them with data and bring those things together. I think that data about why doing Agile is really important, the data about how it's really going on your teams, and the ability to make decisions based on it is really important. There's the Scrumming case study on the Saab Gripen is lovely because they, in one of the articulations, they do the sequence of morning standups and allegedly, according to the case study, I'm pretty sure it's true, they do 7:30 in the morning, which is insane. I don't know why they start at 7:30 in the morning in Sweden, but apparently they start at 7:30 in the morning. But they do a sequence of standups and the idea is by the end of the hour the cascade of standups means that any impediment can reach the executives within the hour and they can fix it.

    Kit Friend:

    That feeling of connection, that trust in teams and that show of progress, real working things being the way that we communicate that we're making progress, I think that's how we build some safety in and help our leaders do things. Not RAG statuses and milestones and Gantt Charts. They have to have that realness with things, hopefully.

    Nick Muldoon:

    It's interesting. It makes me think, we did a factory tour recently and it's a factory that makes air conditioning manifolds for commercial buildings, and they actually-

    Kit Friend:

    What? Why were you touring an air conditioning factory? Were you buying some air conditioning?

    Nick Muldoon:

    No, no, no. Lean principles, right? You want to see the application of the principle.

    Kit Friend:

    Wow, you're living it, you're living it. It's wonderful.

    Nick Muldoon:

    Yeah. So they do breakfast from 6:15 to 6:45 or 6:30, something like that, and then they get going. I think they do their standup at 7:45 after they're actually in the flow, they come together, "Okay, where are we at for today? What are we working on?" Then that rolls up to the ops team and then that rolls up to the leadership team, and then at the end of the day they do their closing huddle for the day, "Hey, have we got all of our tools? Are we back? What are we going on with tomorrow morning?" So it was like the start and the finish of the day and it's really interesting.

    Nick Muldoon:

    Just thinking about, we introduced an end of day huddle in COVID, when we were all on Zoom all the time, and I think it was very useful. But then of course as we get back into the office, it drops away. It's interesting how things evolved, right?

    Kit Friend:

    Yeah. And you're the big Head Honcho, right, Nick? I have a worry niggle with end of day meetings, about whether they're for the team they're for people to feel they're across stuff, and I find it interesting because I'm having to take people through practicing for Scrum Master exams and things, lots at the moment, and I really like talking about how standups are for the team. They're for the developers, they're not for the product owner even, they're certainly not for the stakeholders. Now, I consistently see with a lot of these Agile ceremonies, I'm like, "Who's getting the benefit from that meeting? Is it someone getting a status check in or is the team getting it?"

    Kit Friend:

    And if the team enjoys it, if the team gets something from the end of day huddle and things, I'm cool with it. But sometimes I see things, and the two anti patterns I see with leaders joining, of any level, joining the meeting, so the first is that they use it as like their aeration platform. The team's ready to go with their standup and then the leader of whatever level pops in and he's like, "Team, I've got this update for you." And then it's like 10 minutes of their amazing update and mini vision for the day, and then at the end it's like people are going, "Yeah, now do your standup. Now do the Scrum kind of thing." And then the other thing is that where it becomes like a status check in for stuff, and I'm like, "It's not what it's for, guys. We should be focused on [crosstalk 00:48:57]-"

    Nick Muldoon:

    We do. So we can get done with 22 people in six to eight minutes.

    Kit Friend:

    That's slick.

    Nick Muldoon:

    It's taken time to get here, but what we actually started out asking for was one good thing, and that's typically a family, community thing, what are you going on with today, do you have any blockers? And it's interesting now that we're having this chat, Kit, I do not see blockers come up very often, so I wonder why that is.

    Nick Muldoon:

    Yeah, anyway. Hey, Kit, I'm conscious of time. I've got one last question for you.

    Kit Friend:


    Yeah, go for it.

    Nick Muldoon:

    What are you reading at the moment? What books are you reading or have read recently that you'd recommend for the audience to read?

    Kit Friend:

    Yeah, I'm between businessy books. I need to find a next one. One attribute, and it's probably not my dyslexia, I think it's just because I'm lazy, I'm really bad at reading business books, like serious books with things. So I rely on audiobooks lots to consume meaningful data. I really, really enjoyed listening to Lisa Adkins Coaching Agile Teams audiobook when she released it, because I knew I wasn't going to get through the book and so-

    Nick Muldoon:

    Did she narrate it?

    Kit Friend:

    Yeah, which is even better, right?

    Nick Muldoon:

    Cool, yeah.

    Kit Friend:

    So lovely to hear from the authors' voices when they're doing things. So I'd really recommend that, and then accompanying it after... I mean either way round, listen to the Women In Agile podcast series on coaching Agile teams, because they talk about each other and there's a whole episode on language, and she talks about how between writing the book and narrating the book, reading it, there was bits of language where she just cringed and she was like, "I can't believe I wrote that." And it really resonates it with me, thinking about my Agile journey and how I would cringe at what I did with teams five, six years ago. As we all do, right? You look back with hindsight.

    Kit Friend:

    So Coaching Agile Teams is really, really good, and I'd recommend. When [crosstalk 00:50:54]-

    Nick Muldoon:

    Isn't that beautiful, right? Because if you look back and you cringe, it shows that you've evolved and adapted and you've learned, and you've improved?

    Kit Friend:

    Oh yeah, if you look back and don't cringe, either you were perfect which is unlikely, right?

    Nick Muldoon:

    Unlikely. Unlikely.


    Kit Friend:

    [crosstalk 00:51:07] things, or you're oblivious which is more likely. I don't mean you personally, Nick. So Coaching Agile Teams is really good, I still recommend the Whole Time if people are trying to get their head round what it's like to work in Agile, what's there. I used to recommend The Phoenix Project, and then I really enjoyed The Unicorn Project more for filling in a team. Your talking about the air conditioning factory just reminded me because of all the Lean kind of things. I really like that, and I struggle when I explain to people because I'm like, "It's not dry, it's a novel about an Agile transformation, but it's not [crosstalk 00:51:42]

    Nick Muldoon:

    It's not. I love it. I get up and I read the newspaper, right?

    Kit Friend:

    Yeah.

    Nick Muldoon:

    That's my thing in the morning, and I would never read a business book at night. But The Phoenix Project and The Unicorn Project, I've read them several times as bedtime books.

    Kit Friend:

    Yeah. To your kids, Nick? Do you sit there [crosstalk 00:52:01]

    Nick Muldoon:

    I will. I'll get there. I'm starting to teach them about Lean principles, build quality in. Yeah.

    Kit Friend:

    Yeah. If you haven't done it already, getting your kids to story point Lego is really amusing and I've enjoyed a lot. I know it's just like time gym, but I enjoy doing it with my son, Ethan, because you know how difficult it is to get adults to get relative sizing in units, and kids just get it. It's wonderful how they just don't get distracted by the fact that you've got an abstract unit, and they're like, "I get that idea." I got Ethan story pointing in five minutes, I've struggled to get some adults story pointing in like five days and they argue about, "Do you mean it's days, ideal days, hours?" Things.

    Kit Friend:

    So yeah, Unicorn Project I think are really good. I haven't actually read it all yet, but I do want to read and I recommend the whole time because of a really good podcast, 99 [inaudible 00:52:51] Invisible Women by Caroline Criado Perez. So when we talk about being customer centric and about really knowing who we're providing our products for, I think there's a really powerful story around making sure we understand the data and when we're going through, and Invisible Women has some amazing, horrifying, but amazing stories and bits of data and narrative around it. So I think those would be my three at the moment, three's a good number to ask people to start with, isn't it?

    Nick Muldoon:


    Okay, cool. Kit, this has been wonderful. My takeaway is I've got to read The Invisible Woman, because I haven't heard that book.

    Kit Friend:

    Invisible Women, there's lots of them is the problem, Nick.

    Nick Muldoon:

    Invisible Women, okay. Thank you. That's my takeaway that I've got to read. Kit, this has been beautiful, I really enjoyed our chat this morning.

    Kit Friend:

    It was a pleasure as well. Thank you so much for having me, Nick.

    Nick Muldoon:

    I hope you have a wonderful day, and I look forward to talking about this journey again. I want to come back and revisit this.

    Kit Friend:

    Yeah. Let's do a check in. We should do our DISK profiles for the next one maybe, and we can find out maybe I'm meant to be a product owner and you should be, I don't know, you'll be like test lead or something it'll say. I don't know. We'll find out.

    Nick Muldoon:

    It's beautiful. All right, thanks so much, Kit. Have a wonderful day.

    Kit Friend:

    And you. Bye now.

  • Podcast

    Easy Agile Podcast Ep.17 Defining a product manager: The idea of a shared brain

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

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

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

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

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