 So, I call this talk An Unexpected Journey through Agile Documentation, and that's partly because I'm a massive nerd, and, you know, Hobbits are cool, and, you know, I was reading Tolkien back in the day, partly because when I first wrote this talk, actually the more recent movie had just come out as well, so it was all kind of pertinent, but the main reason why I called it Unexpected Journey, other than the fact that Hobbits are cool, is because I never expected to be the Agile Documentation person. In fact, this is a picture of me in 2011 speaking in Cincinnati at the Open Help Conference. I answered a question at the end of giving this talk, and someone popped up and said, oh, all my development teams are going to Agile Development, and we're having a lot of trouble creating documentation around this and creating content. How do you cope with this problem? And my answer, much to my embarrassment now in 2015, my answer to that question was, well, documentation doesn't really work that way. Yeah, I wish I had an answer to the problem, but I don't. So, of course, I went back to my office at the time, and not long afterwards, I had a couple of program managers from two different development teams that I was working on, and they're like, look, we're fully Agile now, we're working in sprints, we're doing everything in this marvellously fast-paced thing, which, of course, developers love. And, you know, this old waterfall style of documentation really isn't working for us. You need to get on that. So, when I use the term waterfall, does everyone know what I mean? Most of you, few of you? Okay, so when I talk about waterfall documentation, what I'm saying is this old process where we used to write books, where we'd go and we'd organize all our requirements, we'd sit down, we'd write the table of contents, we'd go and find our subject matter experts, we'd gather all this information, and then we'd lock ourselves in a drafty garret for a few months and write the book. We'd sort of pop out somehow later on, you know, hopefully not having drunk all the absence. We come back out at the end and we're like, subject matter experts, look at our beautiful documentation, they go, well, that's wrong, that's wrong, that's wrong, we'd go back to our drafty garret. So, this is waterfall documentation, and they call it that because each step, the result of the end of each step is that it starts the next process. So, at the end of planning, you can start writing, that kind of thing. So, waterfall documentation was where it's at, and for a very long time, I was an advocate of waterfall documentation, there's lots of videos of me giving talks about the old waterfall models. And I really honestly didn't believe agile documentation was a thing that could work. What changed to that for me is we started talking about removing this idea of a book. So, when we think about books, we think about these things made out of dead tree. We start at the beginning, you write through to the end. You can't pick up Harry Potter and start at chapter six and understand what's going on, unless you've seen the movie, I guess. You can't jump into that content anywhere. So, the thing that broke it for us is eventually we stopped thinking about the documentation we were writing, we stopped thinking of them as books. We started just thinking of them as collections of content. So, briefly, I want to talk about agile documentation before I get back to the smashing the book paradigm. Agile development. Everyone familiar with the term agile? Yes, excellent. So, I want to talk about agile. I'm talking about sprint-based development. Quite often it's two weeks, three weeks, four weeks, or somewhere around then. I had one group that wanted to do one week sprints and oh my God, we nearly died. It does happen though. So, this is really fast-paced development. And the difference between agile development and the traditional way of, the old waterfall way of doing it is we don't have these big planning sessions to start with. There will be some planning sessions. There will be some general idea of we're going to try and get this feature or that feature and we're going to try and achieve something that resembles that at the end of it. But mostly those planning things are really foreshortened and we don't do quite so much of it. We do a lot more thinking on the fly with agile, which means you might get three, four, five, six sprints in. But you know that feature we said we're going to have, you know, we're not going to make that anymore. Or it's going to look different. And that's a real challenge for documentation. So, as I said before, agile documentation really shouldn't be a thing. In all sense of the word documentation isn't agile. And I really, as I said, didn't expect to be standing up here and be the agile documentation person. I get referred to as, oh, hold on, you're the agile docs person, right? And that's because I keep on giving this talk, partly. Agile documentation really shouldn't exist. The thing that unlocked it for us, and this is a very vaguely continuous picture here. I'm trying to talk about the key that unlocked the problem for us. So, you know, padlocks on the signs close. So what happened for us is topic-based authoring. And what that means in our sense is basically content reuse. So this is being able to write things in one place and reuse it somewhere else. And in tech docs land, this happens over and over again. I work for cloud documentation. It means we're constantly explaining things like what's a node, what's a server, what's a virtual machine, all those things we explain over and over again. And so it's really nice to be able to write that in one place and reuse that content elsewhere. Which also means that if we change anything, we only have to update it in one place. We don't have to go and then find all those places that we wrote about it last time. It's not even just concepts that we use topic-based authoring well for though. It's also simple tasks. Things like creating an SSH key that comes up again. I don't know how many times I have written a process for creating an SSH key. I think I've created an SSH key maybe five times in my whole entire life. And probably all of them, with maybe one exception, was because I needed to write the process for it. I wrote this process over and over again. And it's really nice to have those really short processes that is over and over again. We have them in a repository and we can just drag them out when we need them, update them if required in one place. So I was going to talk. Topic-based authoring was the thing that unlocked it for us. And this is what I talk about when I talk about smashing the book paradigm. So we no longer thought about content coming in this neatly ordered way. We all of a sudden started thinking about it as a series of topics. A series of chunks of information that we could hold in a repository and we could access in any order. It didn't matter anymore which bit of content we wrote first or which bit of content our audience saw first. It shouldn't matter. Incidentally, I give another talk called Every Pages, page one. It's related. Topic-based authoring essentially works on three basic questions. So the first question is what is it? The second question is how do I do it? And the third question is what else do I need to know? So as an example, what is it? That's a concept. That's the word we use for it. Because we're writers and we have to come up with fancy terms for everything. Instead of saying what is it, we call it a concept. And an example of a concept might be the penguin is a flightless bird. So we're explaining what this thing is. With how do I do it? That's what we call a task or a process. And that's something like push the penguin down the hill. This is something that you do. Maybe it's usually a series of steps. Like there might be step one, prepare the penguin, tell him he's about to be pushed down the hill. Step three, you know, get a brace yourself. Nice firm position on the ground. I don't know. I'm just silly. The third one, what else do I need to know? This is what we call a reference information. And this could be something like some penguins die at the bottom. I'm sorry. So this might be some penguins die at the bottom. So this could be a call out or an admonition. It could be a note or a warning. You know, don't do that. You'll lose all your data, that kind of thing. Or it could be a table. Something like a whole bunch of switches for a command or something like that. All the different options that you might have in a drop down menu. So these three things are really important. Concept, task, reference. I want you to try and remember that. Okay. Now we're going to get into the fun stuff. Oh, I'm sorry. Were you trying to? Photo opportunity. Can I do Adriana exonadus? Excellent. So how this works? That was the boring bit. I'm sorry. We've just done that. It's over. So you can all wake up again now. What I would like you to do is pull out your devices and hit this link for me if you could. I'll show the link again just in a little while. That, I promise isn't phishing you. That, I promise we'll send you to a Google doc, which I have previously organised. Don't do that quite yet, please Toby. I've just got a little bit longer to go. Sorry. Okay. So we're going to have three ten minute sprints because we're going to recreate an agile development situation here. We're going to have a code review and I've got code in scare quotes there because we're not really going to be doing any actual coding. We're going to have code review at the end of each sprint where we talk about the things that happened in that sprint. We're also going to have continuous integration of documentation. So my development team. Who would like to be on my development team and come up here and play us some Lego with me? No, I can. I've got four chairs. The gentleman in the back here come right up and the three in the front. Let's do it. I've got four chairs. I knew I had four chairs here for a reason. Toby offered to take the fourth one away and I'm like, oh, I'll put the link back up in just a second. Thank you. Sorry, it's been hard for me to tweet while I'm doing this. Okay. So feel free to open your open your Lego. My four year old niece has been playing with that Lego recently. So I don't know what you'll find in that box. If there's Barbie bits or something, don't be surprised. Okay. That's my development team. The rest of you, you're my documentation team. So I'll give you the I'll give you the URL again in just a second. Pull up your pull up your devices. Make sure you're connected to the internet. Now some things I want you guys to remember. I need you to describe what it does, not just what it looks like. It's really easy when we're describing something built out of Lego. We can describe stuff, you know, it's made out of Lego. It's small, all that stuff. Let's describe what it does. How will your users be approaching this problem? So we're going to talk more about the users and who the client is and all that kind of thing in just a second. But remember to approach this as a user and not as a developer and not as a documentation person. Put your head in the user space. So ask yourself what questions they'll need answered. Obviously we're in a very highly fanciful situation here. It's okay to make stuff up. In fact, the main reason I do this talk is because I end up getting the giggles about halfway through. So please make stuff up. Please make me laugh. And also concept task reference. I said it was important and I'm going to say it again. So my development team now you're up here and you're all set up. You have some client specifications. This is your client's specification. So I in this case is I am your client. You need to build a vehicle for the Daddy Penguins to move their eggs around. So we've got Daddy Penguins and Mummy Penguins. You know, we all understand this right. So the vehicle that you build must be fully enclosed for warmth. It must be a uniform color for camouflage. It must fit at least three penguins and their eggs. Hold on. It could be a terrible, terrible egg like disaster. We'll get there. It must be all terrain and please don't kill any penguins in the making of this. I know we were pushing penguins earlier down the hill and we're going to try to avoid pushing penguins down the hill and try not to kill any at the bottom. Development team, call with that. Don't start yet. Sprint hasn't started. Okay. Documentation team. We're all happy. Excellent. Here's that URL again. So it's a one, a capital E, a capital O, a Z, a capital C, a lower case Y and a lower case F. In case anyone's having trouble reading that. I'm sorry about the O. I try to pick URLs that don't have confusing characters in and this time it failed me. If you do feel like tweeting it, I've been using the hashtag agile doc or agile docs as well. So feel free to tweet. Okay, Toby, we might, we might switch over to the document if we can. I'm going to start the start the sprint. Sorry, I didn't organize that. Oh, excellent. That's great. I'm sorry. I normally print one out. I just realized I didn't do it. Okay, so documentation team, let's start with concepts. The best thing to do is to start with concepts because at this stage all we've got is suspect to work off we don't actually know what they're doing. We have no understanding of what this thing looks like just yet. And we've got the camera set up here. So we will flick over to them at the end of the sprint and have a look at what's going on. But for now, we don't know. We're just working off the spec. So we know it's going to be a vehicle for daddy penguins to move their eggs around. We know it's going to be all terrain. We know it's supposed to be uniform color. One thing that the development team are going to have to be aware of is that they're not going to be able to do all those specs. I might have purposefully done that because I'm a client and I can be difficult. I've given them a series of specs. It's probably impossible for them to achieve given the resources and the time they have available to them. So they're going to have to choose which of those specs they're going to drop. And then they're of course going to have to explain it to their client and tell them why they can't have the amazing flashy thing that they've got. So come on guys, start typing. We know what we've got. Concept. We know we've got a vehicle. We know it's all terrain. So nice whole sentences. I can see I've got people in there. I need something to start writing something. Hey, we've got it. Yes, penguin friendly. Remember to approach this as a penguin would approach it. So what's what's a daddy penguin going to need to know about this? He's going to need to know things like how do I get my egg from the snowy ground and up into the vehicle? He's going to need to know things like will it keep my precious baby safe? How is it going to keep my precious baby safe? We might not know all the answers today, but feel free to make stuff up. One of the best things I have learned as a technical writer is that if you make something up and you put something down on the page, it is completely incorrect. It will take about 3.4 seconds for some developer to point out to you that it's wrong. If there's nothing on that page, you'll never hear anything. Write something incorrect, you will always get corrected. That's one lesson I can give you to take away from that. Penguin sized airbags, I love that. The doors open, the mirrors touch you. Someone's in marketing. Who's in marketing? No one's going to own up to it. Excellent. Now we're getting it. So we've got a lot of dot points here. I'd like to say some full sentences if we can, because I'm a writer and a little pedantic about these things. So without trying to sound too marketing, I confess right now I have a marketing degree in my arsenal. I actually realized I didn't want to be in marketing about six weeks before I finished the degree. So I realized that would actually be a really bad idea for me. So I need to tech writing instead. But a lot of tech writing is marketing. I've given whole talks on this before too. When you're a tech writer, you don't write what sounds like marketing, but it's got to be marketing all the same, because you don't want to be presenting your product in the worst possible light. I'm wondering about the precious thing now with the title of it being all hobbits. How are we going for time guys? Six and a half minutes. Toby could we flip over to the camera just quickly and see what the development team's up to? Here we go. Excellent. So we can see the timer down here in the corner, which I'm really pleased about. Something I've not actually managed to get going before. And we do look like we're getting a lovely vehicle happening here actually. It even looks more or less like it's a uniform color for the moment, which may of course change in future sprints. We also have a lot of eggs here. If anyone wants to start shouting things out, go for it, because you know, I've got a fairly good chucking hand when I'm ready. It does need light. What will the developer team do if we throw a last minute change? Can you get some lights on there guys? No, the client has no idea. The client has a lot of ideas, but none that are particularly reasonable. Flip back to the document for a minute, please, Toby. Excellent. I love this. It's like voice activation. Okay, so Penguins can't drive. They can use their brain Wi-Fi to control the car. That is an awesome idea. I love this. Okay, the steering wheel needs to be beak friendly, of course it will. I would actually rephrase that because we're not writing a spec here. What we're doing is documenting something that already exists officially. So what we might have to write is something like the steering wheel can be operated by the beak easily or something like that. Someone wants to edit that for me. Automatic transmission due to lack of thumbs, all where the penguin friendly egg safe transport, penguin sized airbags, automatic doors. It has to be heated. White for penguins, for camouflage. Precious, precious, tasty eggs. Who wrote that? Yay. I don't know if I can throw quite that far. I don't think I'm that good. I'm rattling now. Nelly made it. Plays the scene from Madagascar. Nice work. Who did that one? I can get that far. I reckon you're in here somewhere. No one's going to own up to the point load. All that stuff just went straight over my head. Also, it's how much weight it can take. I'll pay that. I'll pay the scientific explanation that came after it too. Excellent. We're getting really good here. We must be just about at the end of our sprint, I think. Three minutes to go. Penguins are pedantic too. Tech riders are pedantic. I can tell you that right now. I'm very pedantic. Excellent. So we've got a lot of dot points happening here. Can we move this into a little bit more of a little bit more prose would be nice if we can do that. I like the waddle to accelerate. That's a great feature. It looks like it's also going very fast, judging by the blood splattering and the slapping with legs. We're going to have to put some pretty serious shock absorbers and things in here. We seem to be getting stipulations on how penguins get in and out of the vehicle as well, which is interesting considering the developers haven't actually told us anything about that yet. Excellent. Maybe what we should do is scroll down a little bit and have a look at some of the tasks. Toby, can I scroll down a bit, please? Excellent. So maybe what we should do is start thinking about some of the tasks that need to be done in just in the last couple of minutes before the sprint ends. So some of the tasks, obviously, we have to load the egg. We have to unload the egg. We have to drive the vehicle. We've got a fair few things going on in the concepts about how the vehicle's driven and how the vehicle is manipulated. So let's try and get some steps happening with that. This is always the bit that starts cracking me out. The tasks get really good. I keep all of these, by the way. They're all available still publicly on my Google Drive. If anyone wants to go make a look at the old ones, find some homeless crash testing. Crash testing. That's what we need to do. We need a quality and engineering environment going on. There might need to be some more eggs. Excellent. We've got some great eggs. Excellent. We've got some really great things happening here, really great ideas. So what we might do with the sprint just about to end, we might get our development team to do a little bit of code review Excellent. We've got a minute left in the sprint. You're doing well. Toby, can we flip back over to the camera please? Excellent. Who's going to be our development lead here? Who would like to to take the sprint master role? You'd be great at it. So if you could just pick that up, hold it up to the camera for us, it's a bit easier for everyone to see. And if you could, if I hold this here for you, then you'll be able to speak into it. Here we go. So, hello. So this is the authentic oh yeah, okay. This is the authentic peg-win-aner 2000. Complete complete with razor sharp deflectors for any polar bears in the area. Yeah, thank you. It also comes equipped with a nice window as a door because we want the door to be big enough so the penguins and eggs can get in but not so big that they fly out at random intervals. That's right. You can see we're using the all-terrain rough and tough wheels there. We had to compromise a little bit on the one color for camouflage. However, we have made ample use of the gray color in order to mask some of the bright freaking red that we had to use in order to with the materials on hand. It has a bulletproof and polar bear toothproof wind. Wow, that's really hard to say. Bulletproof toothproof. Anyway, windshield I was particularly impressed with the team's ability to put the roof on properly. That's important for an all-in-close. It is aerodynamically angled. Thank you. We're going to Mary Day. Yes. Oh, yeah. Yeah, for sure. Brian, why don't you tell us a little bit about this roof that you work so hard on? Look, it's got camouflage. Camouflage for forestry as well. And we already had the bulletproof glass. So if I could pick a design for is perhaps in the implementation, we got the egg in the driver's seat. That might cause a problem. That might have to be fixed in a future duration. Are we ready to move into our second sprint? Excellent. Let's start our second sprint then, shall we? It's up to you as a development team. If you've decided it's that terrible, you need to start again and you can. Otherwise, you can build on what you've already got. The specs have not changed at this point. I'm highly disappointed about the the variation in color that for now the client's grumbling, they're going to be okay with it. As a project manager, I think possibly I should issue the development team with some more chocolate eggs as motivation. Code review. We have pictures. Excellent. I love this. We've got a penguin driving a car. I've got a few new things have come up in this sprint. We've got all the polar bear proof glass. We do have a couple of design flaws in the way that the eggs manipulated, but we also know what color it is now. So we can talk about that. We've got the, we've seen the opening in the side so we can talk more about that information. I'm prototyping your shoes. This is going to be an all nighter, I think. We're going to have some devs doing a lot of work tonight. I'm having technical issues on my own. Okay. My nostril must not be related to empty and empty. Nice work. What have we got? So can we go back to our concepts? I'm not sure where our concepts have gone. Oh, there we are. Excellent. This is really annoying me. Okay. So we've got the Penguinator 2000. Thank you for writing. Who wrote the Penguinator 2000 down for us? Are you kidding me? Come down afterwards and get some chocolate eggs. Okay. So penguins can't drive they're using their brain Wi-Fi. The steering wheel is operated by B. So we can write it. We can write some processes about these things now. We've got a little bit of a better idea. Yeah, it's just the necklace, I think. So maybe what we could do is drop back down to our task and start talking about how the steering wheel is actually operated with the beak. How does one do this? How do you start the vehicle? How do you manipulate the steering? But now the development team might be able to help me out. But what was the purpose of the tree on top? They're not listening to me. Development team. I'm sorry. Could you please explain the tree on top? Because I think we just have a slight question here from the documentation team. Sorry, there's a question. There was a tree on top of the vehicle? There was. Oh, that was... That was camouflage. It's not a bug, it's a feature, right? Oh, good. That was camouflage, I'm told. Okay. Four fish must be consumed per hatch deck. That gives me an idea. We haven't talked about how these things powered yet. Do they have to refuel it? Are there petrol stations in the Antarctic? I'm not certain. We may need to discuss something like that. Let's go... We've got reference information down the bottom there. Maybe we should have a think about what reference information we can get in. So this is stuff like... Remember, we can use warnings. We've got more penguins than cars. In rage polar bears. Oh, no, we can't have any red. The red's got to go. Regulations. We're just going to, I don't know, have to do something about the polar bears. Feel the fence or something. Interestingly, polar bears and penguins, my 11-year-old would be very, very quick to point out, probably a good 10 minutes ago now, that polar bears and penguins don't actually live in the same place. She is highly upset by this fact, I might add. This is one of the ones that really bugs her. So I like teasing her about it. Okay, so if we can just go back up a little to our tasks. Excellent. Excellent. I keep saying that. So I think what we need to do is actually involve some steps. So step one, maybe, I don't know, prepare the egg for loading into the vehicle. Step two, lift the egg with appropriate, I don't know, harness, something like that. So I'm sure somebody can come up with some interesting stuff there. Things like move eggs from A to B. This is a great high-level concept. What we need to be able to do is break that down into steps. So I guess to get back to the agile documentation theme as well, what we're doing here is we're coding on the fly. We started out by making things up. And the reason we're working off very small bits of information, things like the spec and the kinds of conversations you would have in the corridor with the developer. This is actually a real-life situation. This happens to me all the time. We go in with the first sprint. We have no clue what we're doing. We're making stuff up. Children's tears. Who wrote children's tears? No one's owning up to the children's tears. It's like you guys don't even like chocolate. No one's owning up. Okay, fine. I'd like to know what the egg tickling is about. Who is responsible for the tickling the egg? No one's owning up to that one either. I don't know. I actually stood up on stage at Linux Confair U in January and had a very in-depth and meaningful conversation with the audience there about noodling, which is, it turns out, a Southern American sport where you catch catfish with your bare hands. And it's absolutely terrifying. I suggest you don't Google this. Anyway, it just makes me think egg tickling and that kind of thing sort of brings me back to noodling. So I think we could probably write a process about the egg containment straps as well, because it sounds like this person here knows a fair bit about egg containment straps and the reverse carbuccal binocular systems. I'd really like to see some more specifications about that. And possibly the person who wrote that could drop down into the reference information, because there might be some more specs and things we need to know about that. There could be an ISO standard or something. Is anyone going to admit to writing that bit? Every time I move, my necklace interferes with the microphone again. What have we got? Okay. Must drive over an ice sheet without sinking. So that's a spec. Once again, what we need to do is actually turn that into either a concept or a process or possibly even a reference information. It might just be, bear in mind, you can take this over this amount of thickness and it won't think. I'm sure we could probably have some more information about the polar bear deflectors. Two, who wrote the polar bear deflectors? No one's admitting to anything anymore. I'm going to put all the chocolate away and I'm going to eat it later. How are we going for time? About two and a half minutes. We might flick back over to the camera, Toby, and see what our development team's doing. It looks like we've had a complete redesign. So this is normal for the second sprint. I might add. Second sprint is normally when the development team comes back and go, actually, you know what? That first one didn't really work. We threw that one away. And that's an interesting part of our gel development as well. When I do slightly more serious talks about our gel development, I do talk a lot about fidelity. And so you start out with really low fidelity in the early sprints and that fidelity grows and grows over time. So the low fidelity is kind of the equivalent of the scratchings on a napkin that you have over lunch with your colleagues. And when you get over time, that fidelity improves and improves until you get to your end stage, which is this hopefully wonderfully polished and correctly working thing that we can release into the public. So we are improving in fidelity as far as I can tell. Where'd it go? Excellent. How am I going for time? Beauty. All night is happening in the development team again. So now would be a really good time considering we're coming up to the end of the sprint for the documentation team to be taking a quick look over their documentation and proofreading and making sure these things are accurate. So making sure you've not got anything silly in there. Well, too silly in context that you've explained things properly and that kind of things. We're just about to prepare your questions in your head ready for our development team at the end of the sprint. How are we going there, Dev? So we're just about ready for a code review. Please reapply the roof. We'd like to see it with the roof on. This is getting very highly technical now, guys. I hope you're following me. And people say I don't give highly technical talk. Seven, six, five, four, three, two. Oh, I have a microphone. Nice. Welcome to our second demo. Wonderful documentation team. This is our new aerodynamic awesomeness Panguinator 2500. Yes. And the improvements we've made over the last one is now we have a steering wheel. That's important. Steerable now. Yes. And also instead of the egg steering the car, we now have a penguin steering the car. That's also pretty crucial. We've, as you can see, slanted the roof. Definitely on purpose. Why don't you tell us more about that? So not only do we cut through wind, the snow falls off the side. Beautiful. Beautiful. I love this innovation. I hope my documentation team has written that down ready for the next sprint. Oh, you're talking about the rear door. Yeah. Okay. No, no, it's the rear doorinator. Yeah, this took a long time to put together, but switching the door to the back means that the penguins can get out in an orderly fashion without breaking their eggs. And more even weight distribution on the wheels. Well, weight distribution, as we've just learned, is extremely important. We've applied a polar bear deflector since we had no choice but to use red on the door due to materials. But you can see there is no other red visible in anywhere else. And so this is our little polar bear deflector thing. So. And the car is now much more symmetrical. So we have deflectors on the same point, on the same sides. And there's no bits sticking out weirdly. Symmetry. Symmetry is important, guys. I'd just like to say the team worked really well together this sprint. Thank my parents, Anne Rand and God. Excellent. Okay. I think we're probably running a bit short on time, so we might cut the final sprint a little bit shorter. Tom, are we supposed to be finishing? I'm sure. I'm meant to be timekeeping for this session. And I think we're meant to finish at... To 3.15? 3.15. Okay. So we've got five minutes. What I might do is we won't actually do this as a formal sprint. We'll ask these guys to finish up their final designs, and I'll start taking some questions from the audience, and we'll do a combined last-minute hurdle through the deadline. Excellent. Final design. Set 2, development team. It's pretty good. Toby, I might get you to flip back over, actually, because this tends to be where the hysteria starts. Questions? Shall we start taking away? What haven't I addressed yet that you guys would like me to talk about? Nothing. I said everything. If you do this in real life, would you ideally stick a documentation person in the same room as the developer so that there could be better cross-communication? That's a really good question. Because I didn't introduce myself at the beginning, I work in documentation, and I work here in Australia, and my development team is all in the US, and I have had a very similar geographic setup for most of my professional life as a tech writer. So while I think in my head, it's like, yeah, that would be really nice if we could have the developers in the doc team in the same location together. That would be really cool. It would be really nice to have someone who just sat next to me and I could go, hey, Bob, what do you think about this? Realistically, though, I've never had the luxury of working that way, and I don't know. It seems to work. You do tend to pick subject matter experts. You tend to form relationships with people, obviously, that tends to be fairly synergistic, I guess, if I can use a marketing word. I tend to find that I actually adjust my working hours slightly to better associate with my US colleagues. I have US staff as well, which makes things a little more complicated again. So I tend to start really early because that's in their afternoon, and we can catch up and do a bit of a handover at the end of the day. I don't know. I think, yeah, in my head, ideally, yes, it would be great to have someone who sat next to you, but realistically, I don't think you have to. How to incorporate the documentation team into your development process, regardless if you're physically in the same location. Like, you guys are writing something. We were building something. We were telling you what we were building, but we weren't hearing back any feedback. Yeah, to be honest, that was probably a fault of mine. What I probably should have done is had the documentation team asking more questions. I think I did actually say at one point, documentation team, prepare your questions for the development team. So yeah, that's kind of synergistic thing will happen. And because you tend to, again, form these relationships with people, you do tend to have people that you can just send an email or quickly grab on chat and say, oh, hey, I don't quite understand this. Could you help me understand it? Or could you explain this kind of thing for me? Or what's that phrase mean? So there does tend to be that back and forth. Oh, we've actually got steps now. That's great. Well done, guys. So yeah, there does tend to be the, it's not quite as formal as it looks in this scenario. There is a little bit more back and forth. And of course you've got endless meetings like any corporation does. So you do have a chance to have more informal conversations with people over time, other than just within the code review and within the grooming sessions. I think we've got, yeah, one more question. Hi. We do, like these one page, two page spec documents. We modeled from the guys from Atlassian, more or less. But we kind of struggle with maintaining the documents as Dev has started. I was wondering what your thoughts were in terms of best practice for writing these specs and maintaining them. The really easy answer to that is make sure you've got someone who that's their job. And I think possibly that's where a lot of development teams fall down. I know I've come across it so many times, especially when I started at Red Hat actually, incidentally, when I first walked into Red Hat, the documentation team is very, very small. There's only a bunch of us in Brisbane. And all the development happened in the US with absolutely no exceptions. And they didn't even sort of realize we existed for the most part. And what would happen is someone on a new development team would make a request and say, we really need someone who's good at documentation. They'd get, yeah, there's about three of them in Australia, like, you know, don't hold your breath. So then they'd nominate some developer within the, you know, once sat next to someone who wrote docs. And then he would be the guy who would do the documentation and then one of us, but normally, you know, me, considering this has happened right when I started, I rocked up and I'm like, hey, I'm here to be your documentation person. And they're like, oh, but we've got this guy now. And it's like, yeah, he doesn't know anything. Get out of the way. You know, let me do it. So the easy way, of course, is to have someone who's dedicated. That's their job is to look after it. In terms of having other people do it as a sideline, I guess it's just got to be prioritized. I don't have a good answer for you, I guess is what I'm trying to say. That really, so because agile documentation isn't actually a thing. It's something that I made up in my head a few years ago. There's no real formal way of doing that. And every time I talk to agile development people, of course, they always go back to the agile manifesto, which basically says documentation isn't that important. Every time I read that manifesto, I come up with more problems that I have with it. But yeah, so a lot of, there's no formal way of doing that. What I would normally recommend in this case is you do have a separate documentation team, which may be one person. Separate documentation, they sprint alongside. So as we did here, we sprint all at the same time. We meet up at the end and we do our grooming and our planning and all that kind of stuff at the same time. We work together that way. But you do have someone who, that's their job, is to sprint alongside the team. And you know, but they actually, we do our own scrums. We have our own little individual sessions as a documentation team, as opposed to in with the larger dev team. So it was a pleasure. I appreciate it. Excellent. Thanks, guys. And thanks, Toby. Toby, can we just give a round of applause to Toby? Thank you, Toby.