A baseline workflow for any team

In this episode of Workflow, Brian and Tom talk about a baseline workflow that can be used by any team.

00:43  What's happening at Rindle (a bit on our podcast/marketing workflow)
03:45  Intro to the baseline workflow
07:20  Our recommended baseline workflow
13:18  Benefits of this baseline workflow
16:23  How work should flow in this baseline workflow
26:45  Tips for taking action!

Helpful Links

• Help article we wrote on this same baseline workflow
• Our webinar on how to create a Visual Workflow for your team

Brian: 00:00 This is Workflow, Episode Four. Workflow is the podcast that helps teams figure out the best way to work, collaborate, and get stuff done. Brought to you by Rindle. Hey, everyone. I'm Brian.

Tom: 00:30 And I'm Tom.

Brian: 00:31 And we're the co-founders of Rindle, and this is our podcast Workflow. Today we're talking about a baseline workflow for your team. So before we kick into talking about the baseline workflow, what's happening at Rindle, Tom?

Tom: 00:43 Everything is going great at Rindle, right? We actually are working on this podcast right now. Recently, you and I had a discussion that we were co-managing this podcast stuff in Google Doc, as typically things start out, I feel like, in Google Docs so you can quickly collaborate on them, and then map some high level stuff out. And then I had messaged you that maybe we should actually turn this into a Rindle board because we basically ended up just having a bunch of bullets in that document.

Brian: 01:15 Yeah, and I think the first thing I thought about was we currently have a marketing board that we track marketing meetings, tasks for the marketing team in general to execute on, and little internal marketing projects. And then we have at the time which was an editorial/content board where we tracked blog post creation, things like that. So my first thought was, well, maybe this podcast effort as far as tracking episodes, and topics, and all of those things, should go into the content board.

Brian: 01:47 Then quickly realized, well, we have a pretty big backlog already from that Word doc that you mentioned of ideas. That would really clutter up that board really fast. So I said, "Okay. Yeah. Let's break out the podcast board and then change the editorial/content board to just blog posts." Now we have a marketing board, a blog post board, and a podcast board. When I mentioned this to Asia, who is heading up our marketing, she kind of reacted like, "Oh, okay." Like she didn't expect that, which I thought was interesting.

Brian: 02:21 It made me second guess myself as to, well, maybe it should be part of the editorial board, and all the editorial stuff should live, and the content stuff should live in one board. Then when I mentioned it to you, you reaffirmed it and gave me more confidence in that decision saying, "Yeah. That makes sense to me because we have such a large backlog of episodes and ideas that it should live in its own board."

Tom: 02:43 Yeah. I definitely think it should probably live in its own board, and when we ultimately get these mirrors in, we can maybe move some stuff over, mirror some stuff onto some common board if we see the need to. But overall, each of these topics potentially could have a lot of other details or chat conversations within the tasks themselves, which the tasks in this scenario are what we're using as like, "These are the topics for each week or the ideas for each week." It just kind of makes sense that it should just be its own board.

Brian: 03:22 Yeah, and I did confirm also when I set up the podcast board, it actually is a slightly different workflow. So, it actually makes a lot more sense than just pushing it through what the blog post workflow is, which is similar, but it just has a couple extra unique steps for the podcast itself. It does keep things really clean and comprehensive.

Tom: 03:42 All right. What are we talking about this week?

Brian: 03:45 Yeah. We're going to talk about a baseline workflow that could basically work for any team. It could be a software team. It could be a marketing team. It could be a production team for a manufacturer. So really just a baseline workflow that can apply, especially if you're looking for a place to start.

Tom: 04:02 Yeah, and it's really interesting, actually. In developing a project management software, even actually before we started developing the actual project management software of Rindle, people constantly came to us and were asking us like, "Well, what type of workflow should I use? How do I get started?" It seems to be just a really common question that people have when starting to use some sort of software to start managing a project. They just don't really know what to do with the workflow and how to even get started.

Brian: 04:39 Yeah. I kept on hearing it over and over again enough to where it inspired us to say, "Okay. Well, yes. We keep on answering this question over and over again and giving direction, a base of where to start with your workflow." And then we ended up writing a help desk article on it so we can start pointing people to a pre-developed article that goes into some best practices, how to start with a baseline workflow, and other things about that workflow that you can start to implement. So, that really became a helpful tool in trying to describe because we did have best practices. We did have things that we were recommending to our customer base, and to other people we chat about this stuff with. So, it was great to get that out into a document so we can put a stake in the ground and say, "Yes. These are the best practices that we recommend."

Tom: 05:25 Yeah, and those best practices really are just a very simple basic set, right? It all stems from this traditional kanban-type approach of three columns: to-do, doing, done, which is just the real starting point of projects in this kanban-type world.

Brian: 05:48 Yeah. I think that's probably the best example of a true common baseline of a kanban-style type workflow, and we say kanban-style or the kind of workflow meaning these are lists that run left to right. So to-do would be your first list or column, and then doing second, and then done third. If you scour Google, or the internet, or whatever, you will find plenty of examples of to-do, doing, done referenced everywhere. That really is the true baseline and we even currently, even in Rindle, start some boards off with to-do, doing, done as just a starting point. It's really easy for people to wrap their heads around. Things I have to do, things that I'm currently doing, and things that are finished.

Tom: 06:32 Sure, and this can be in virtual softwares on the internet, like a Rindle, or a Trello, or whatever, but this could also just as easily be done on a whiteboard with three columns: to-do, doing, done. This type of simple workflow really can be brought into any software.

Brian: 06:51 Yeah, and on a whiteboard introducing along with the columns written out on a whiteboard, put post-it notes to track the task within each column, and you can pick up the post-it note and move it from column to column and track your work.

Tom: 07:05 Yep. I think we've all seen it on Silicon Valley.

Brian: 07:09 Yes. That big giant post-it note board they have, and I think the backlog is filled with 100 items.

Tom: 07:16 Yep, until they move them all to done.

Brian: 07:20 Exactly. So, our recommended baseline workflow is a little bit more in-depth than a to-do, doing, done workflow. We recommend basically starting with four lists, and we'll go through each list kind of what each one is, but we recommend starting with a backlog being the first list leftmost position. Then in progress, blocked, and done. The backlog is basically the place where all of ... And this comes from agile terminology, but a place where it's a backlog of things that need to get done. Typically, that's prioritized top down. So, the thing at the top of the backlog is the next thing to get done, and if you have ideas or things that you want to do, you add them to the backlog and when there's availability, those are the next things that get done.

Tom: 08:10 Yeah, and I think that's probably really important to note that that is the second dynamic of a kanban-type approach is that you have the columns, but also the items are in a particular order that they can be arbitrarily ordered. In that sense, we choose to order them in priority as opposed to in date order or just alphabetically, and we really make use of the fact that you can order them however you want.

Brian: 08:41 Yeah, and that's really easy to understand as well. Just if you prioritize top down, it's really easy just to understand that's just the way we prioritize our boards. The next list is in progress, and that's just basically things that come from the backlog and move into in-progress. These are actual tasks that you're doing now. Typically in this step they'll be assigned to somebody. So, if I grab a task that I'm going to do and I move it to in-progress so everybody can see that I'm working on it, I'll also assign it to myself. Everybody can see that as well, and in some of the practices out there, like kanban and things like that, some even recommend limiting how much work you have in-progress at one time. But for this baseline example it's really just if you have a team, no matter what size team is working on that set of tasks, everything that each person is working on ends up in this in-progress. So again, visually it lets you see quickly who is working on what.

Tom: 09:32 Yeah. I was actually going to mention the limiting factor, but honestly if you have your whole team on this, and they're giving it a go, it probably will happen kind of naturally that, hey. You can only really be working on one thing at a time, maybe two things if they're related. One item in progress as a time per person-type deal.

Brian: 09:56 Yeah. I think if it gets above a couple things you're working on, really everybody says they can multitask, which some people can, and of course you can have a couple things going on at once. But at a point it gets to be less productive and you will actually be probably slowing the progress of those tasks down than speeding them up. The next list is blocked, and basically we recommend having this list in here just to have a space for if you have a task that is reliant on something else, either a person's input or another task that needs to get completed, any other kind of dependency, moving it from in-progress to blocked is a great way to organize it and let everybody, again, know on the board that this is blocked. Also, taking it out and separating it from all the in-progress and backlog tasks, and just kind of segmenting out into its own list.

Tom: 10:45 Can you skip this column if you just move something directly from in-progress to done? Do you have to go from column, to column, to column, or how does that work?

Brian: 10:53 That's actually a great question, Tom.

Tom: 10:54 Thanks.

Brian: 10:55 Yes. You can skip the blocked list. Of course if you're working on something, and there is nothing impeding the progress, and you can actually get it done. There's no dependencies. There's no other input needed. You certainly can move it right from in-progress to done, and that will be your typical workflow, actually. Probably the blocked tasks will be more the edge case because hopefully you're not having as many dependencies and issues with getting tasks done. So, it will be more of the edge case where that gets moved in occasionally, and then most of your tasks will go from in-progress directly to done.

Tom: 11:28 Now, I do feel that as we have actually been working on these workflows as we use Rindle to develop our product, blocked wasn't actually typically on the board in the early iterations of this. We actually moved things back to the backlog, but then adding blocked actually gave us a lot more clarity because it doesn't really make sense to move something from in-progress back to the backlog just if you can't finish the job because it's not really giving it any real indication as to what happened with that. Then it just gets lost in this backlog when actually it could be partially done.

Brian: 12:08 Yeah. I think, yeah. It definitely alleviates confusion because it was already started, and the backlog typically is a list of things that haven't been started yet that need to get done. So, I think just the fact that it got started, moving it back to the backlog just doesn't really make sense, and it definitely confused us. People were kind of unsure. Well, is Tom working on this, or is he not, or is it partially done, half done, not started at all? Yeah.

Brian: 12:36 I think the blocked list definitely adds a clarity as far as, well no. This is started. I'm going to finish it, but I'm waiting on some things, and let me add some comments to that task or whatever to articulate what I'm waiting for so everybody knows, but yeah. It's a much better flow, I think, since we've introduced that. The last list is done. So, it's pretty self-explanatory. When tasks are done, they get moved there and really it should be done done when it gets moved to that list.

Brian: 13:00 And really, it should be done, done, when it gets moved to that list, not, well, I'm done with it, but somebody else has to do something. If that's the case, it should still live in, in progress or whatever needs to happen, or maybe even blocked. But when it's complete, fully done, it moves to done. It gets marked as complete, and you move on to the next task.

Tom: 13:18 Perfect. So Brian, what are the benefits of this workflow?

Brian: 13:23 I think using the visual type workflow with these lists running left to right as we described them, it does give instant visual feedback to everybody who's collaborating on that board or project. By using a list, it actually segments the work so your brain can actually interpret what's happening a lot faster. It's just like, us as humans looking at a picture and interpreting so many data points in a picture, way faster than we do reading text.

Brian: 13:53 So if you have to read through a list of a 100 tasks in that project, for whatever reason, and decipher, well this is actually what Brian's working on. This is what Tom's working on, these are the things that are due, it takes a lot of time and a lot of energy. Then you've got to re-look at it over and over again, and make sure what you saw was correct. So by laying it out in this type of workflow, left to right, which introduces this visual element, it just gives insight into well, how many tasks still need to be worked on, which tasks are currently in progress, who's working on them, who's assigned to them, what's blocked, what needs attention, and what's been completed, right? So it's really simple to see that on an on-demand basis.

Tom: 14:33 Sure, which leads right into the next point, which is that it makes for a great tool to bring up during a meeting. I know we have SAS meetings every day. We try to keep them short, they typically go a little bit longer. But we do start off by using this tool to keep the meeting running smoothly, like what we're currently working on, and what we've completed the previous day. And then, we'll, from a higher level take a look at the backlog to see what else needs to be done, to see if we're going to be able to hit our goal.

Brian: 15:11 Yeah, I think we actually use, pretty much probably in every standup we have, we reference a board, depending on what we're working on at the moment. But we are looking at a project or board with that kind of workflow, that's tracking our work, we're referencing that constantly. In our case, we're using Rindle. So not only backlog of what we're working on, but also what's in progress, right?

Brian: 15:34 So a lot of times I'll be asking, "Well, what is Scott working on? What's Tom working on," et cetera. And we can all see the same thing and hone in on that information really quickly because it is segmented out. So I like it just because it speeds up the conversation because we're not like, "Wait, no, no, not that task. Wait, no, no, I'm talking about this one. It's over in this list somewhere else." It's very easy to hone in on the same task pretty quickly, as we're all on the same page when we're talking.

Tom: 16:00 You know, one other thing, since we're actually on that board during the meeting, if we're talking about something or something comes up, it's really easy just to add additional things to the backlog right then and there, which is a big benefit. We're already in the project board so just hop right in and add additional stuff if it needs to be added.

Brian: 16:22 Absolutely.

Tom: 16:23 Now that we have a basic understanding of the workflow, how should actual work flow through this workflow?

Brian: 16:33 As we mentioned with the backlog, all tasks that need to get done get added to the bottom of the backlog. And because again, we're prioritizing it top-down, that's a pretty good practice, that any time you add something new, add it to the bottom. And then of course, it can be reprioritized from there. It could be certainly moved to the top of the list if a team ended up deciding, hey, this actually needs to get done tomorrow, and they move it to the top, or move it to the middle. But typically, best practices, if you don't know where it falls in the backlog, just add it to the bottom. And then it will flow up from there.

Tom: 17:06 And then as you have time, like the team members have time, you basically pull a task from the backlog and move it into in progress. And then we assign it to ourselves. That's the first thing that we do.

Brian: 17:17 Yeah, exactly, and if you're not assigning to yourself, if you have a project manager or somebody else like that, that person will sometimes move it over to in progress for you, and then assign it to you, or whatever team member needs to get it done. So whoever's really doing that, it typically just pulls from the backlog, and moves it to in progress, and is assigned to the right person.

Tom: 17:34 Sure, and initially, I think it's important to talk about that, initially, we were preassigning tasks to people in the backlog, but I actually think that muddied the water if you will, and we stopped doing that and it actually gave us a little more clarity, if that makes any sense. The stuff in the backlog is changing fairly rapidly and you don't really need to be worried about it until it moves to in progress, I don't think.

Brian: 18:05 Yeah, because then what you end up having is a bunch of tasks that are assigned out. And what I've found is, if you look at your plate in Rindle, and say, "Oh, what am I actually working on across all my projects," and things like that. You end up having a bunch of tasks that actually you're not working on, which makes no sense. So it's just really muddying the water for you, and now you have to sift through a bunch of other information.

Brian: 18:27 So, by just keeping this process and letting the backlog keep tasks that need to get done, but they're not assigned yet, and only when they move to in progress, delegate it out and assign it, and track who's doing it, makes a ton of sense. And if you do this across all your projects, then it'll keep everybody's workload clean, as far as when they look at all the tasks on their plate, they'll see actually what is in progress right now.

Tom: 18:51 Although, I do think that if there's project managers out there, they're probably going to be like, well, how do I plan stuff out? It's probably a topic for another podcast, but there are other methods for being able to plan out who's get what tasks, other than actually assigning it to those members basically.

Brian: 19:10 I've heard this before too, and I actually used to do this back in the agency days. Sometimes you're pre-delegating work out, so everybody knows what their responsibilities are. But as I've grown in my career a little bit, that makes less and less sense to me. Just because for the reason we just described, you are basically just bogging down their workload with stuff that they're going to do in three weeks.

Brian: 19:34 Yeah, there're other ways to communicate those things, but as far as leveraging, especially a software platform, and you're trying to look at reports and other kinds of views of data, doing that, makes those reports and views of data almost impossible or useless. Just because you're looking at, again, a bunch of information that doesn't apply to what you're doing today, or this week.

Tom: 19:57 Yeah. And again, typically those things longer term, change rapidly. In three weeks, those items might not even be on the backlog anymore. Or, might not even be need to be done at.

Brian: 20:11 Right, so it basically just wasted a bunch of time, getting your attention, you're looking at it over and over again, and in the end, it's going to be deleted a week from now. And all that time's been wasted, and energy's been wasted. When things are still in a planning mode, which the backlog is great for, really delegating shouldn't happen at that point just because things change so rapidly, like you said.

Tom: 20:31 Cool. So then after a task moves to in progress, this is the point in time where you basically have a decision to make. If it's done, it moves to done, but if it's not done, it moves to the block column.

Brian: 20:42 Yeah, absolutely. And once it's in block, if that's the path forward, it needs to be moved to blocked, because it's waiting on a dependency or something else to happen. When that thing is done, whether it's another task you're waiting for, or input from another person, it should move back to in progress, to show that okay, it's no longer blocked. All of those things have been alleviated or solved. And I'm now continuing, and this is now in progress and now I'm going to continue it to completion, unless it gets blocked again for some reason, or completed, and moved to done.

Tom: 21:11 Awesome. And I think it's important to note here that you really should avoid leaving stuff in, in progress if you're going to start something else. It's better to move it to blocked, and have it wait there, as opposed to leaving it in progress, and moving another task to in progress because really, I mean, we said before, maybe you could be working on two things at once, but it's really unlikely that you'll be working on two things at once if you're trying to map out granular enough tasks.

Brian: 21:39 Yeah, and to that same point too, if it's something that's delayed for some reason, that is going to really not be picked up again, or you don't know when it's going to be picked up again, maybe it should be unassigned at that point and moved back to the backlog, right? And picked up by somebody else at a later time, maybe it gets moved to the bottom of the backlog.

Brian: 21:57 I think there are a couple of scenarios here, like you said, moving it to blocked so it gets out of in progress if you're not really working on it, and you are slowing down, or not working on it for a certain reason. And the other case is if maybe it's being delayed permanently or semi-permanently, and you should actually unassign yourself, and put it back in the backlog and get it out of in progress in the same light.

Tom: 22:15 When the task itself is actually done, done-done, as Brian said before, move it to done, and it really shouldn't ever move out of done at that point. It should never really move back to backlog, or back to in progress. It should be actually complete.

Brian: 22:31 Cool. So on top of that baseline workflow that we just went through and described, there are a couple of other lists that we find popping up quite a bit. They're not part of the actual baseline that we just laid out for you, but there are things definitely, that you should consider. One of them being a review column. So this is basically, if you have a process of testing, QA, if you're doing software development or something like that, like we do. Or if you have a proofing step, maybe you need a copy editor to review a blog post, or maybe even a creative approval step, where you have a creative director reviewing designs, or something like that.

Brian: 23:12 A review list, and this list could be named whatever you need it to be named. In the end, it could be QA, it could be testing, it could be proofing, it could be creative director review, but review is a great generic name. And that becomes a place where it can move to review before it gets marked as complete and moved to the done list. So it gives you a step to say, "Okay, yep, this is done," the task is done. But in order for it to be considered done-done, it actually needs a review by whatever process you have in place on your team.

Tom: 23:41 Very rapidly, a simple workflow can become complicated, right? Because now you're in this review column, and as you just mentioned, potentially, you're assigning someone else to the task in order to review it, or proof it, or whatever the item may be. Potentially, you might have multiple review columns, right? It could start to get complicated quickly.

Tom: 24:05 And then, after they review it, they find that there is an issue or a bug, if it's software development, or something else has to be done. So, you have a question then, do you move this task back to somewhere? Like, do you move it back to the backlog, or do you move it to in progress, or blocked, or what do you do? And personally, we've debated this a lot, I personally find the best thing to do is to create a new task at that point. Because typically, whatever has to be done is a granular piece of that task, and it's clearer just to create a very specific task and put that in the backlog, and then someone will hopefully get to it.

Brian: 24:56 Yeah, in the earlier days, I was definitely, if I tested something in our software development workflow, I was moving the entire task back to in progress, and saying, "Oh, there's an issue with this, it needs to be fixed." And then you guys kept on saying, "Well, it's actually done, it's just you found a problem with it." So it's confusing actually, for me to move the whole task back and say, well, it looks like this thing hasn't been done at all, and somebody needs to do it. As opposed to, like you're saying, creating a new task and actually specifying the exact issue so it looks like a new item to everybody and everybody understands what's going on as far as what needs to get done.

Brian: 25:36 So yeah, I think your reaction to that when I used to do that kind of use case where I moved the whole task back, definitely drove your recommendation on maybe we should create new tasks. And I think that's worked out quite a bit better, as far as just the flow of everything, and everybody seems to be a lot clearer on what's going on.

Tom: 25:55 Yeah, definitely makes things clearer I think. But the question then is, what do you do with that task, that's in the QA column? Because is it actually done at that point?

Tom: 26:00 With that task that's in the QA. Is it actually done at that point once you've created that new task?

Brian: 26:07 Yeah. I think the way we're at least flowing it, and I think this makes sense, is that it does get moved to done because the actual work has been done. So even if you take a blog post for example, and it's a first draft and you've kind of reviewing the first draft of a blog post, the draft was actually completed. It's now on your plate to review as the copy editor. The copywriter wrote it so that task is done. The fact that there's edits or other changes or maybe even some revisions that need to go back to the copywriter, that's definitely a new task. It's not, "Hey, first draft needs to be created again," unless you really wash out the whole thing, but I think it makes sense to move the first draft to done and then create a new task and progress for X, Y, and Z edits to that first draft.

Brian: 26:52 It really becomes clear as to what exactly people are working on and why and you could even do multiple drafts that way or anything you need to flow through that same cycle.

Tom: 27:02 Awesome.

Brian: 27:03 Another list that we recommend that you consider is a resources list. If you have things that you need to reference on the board for the entire team, so they're not necessarily tasks that need to get done but they are resources and references, maybe it's links to websites, maybe it's documents, things like that, you can create a resources list in your workflow. I've tried it in both places, on the far left, meaning it's before the backlog all the way to the left of the workflow, and I've also tried it at the far right and I really like it a lot better off to the side on the right because it's not affecting the daily workflow from backlog on over. I recommend definitely keeping it on the far right. This is just a place that's kind of stagnant. The tasks really don't move from that list. It's really just there for reference when people are like, "Oh, what's the image size for that blog post for the hero image?" Or, "Wait, there's a documentation that I need to reference." It's just a place that you can keep those things organized.

Tom: 28:00 The reason why we're saying a column for this is really because we're using software to do this and we don't have another place to put that within a project, but if you're actually using the whiteboard to do this, you might just have some Post-It notes at the top of the board that are not ... they're not tasks or whatever. They're just general information. Right?

Brian: 28:22 Yep, sure.

Tom: 28:23 Cool. Then another list to consider is Up Next. We all know that you have a com called In Progress. This is basically a com before that that's like, hey, this is the next thing we'll be working on so it's not sitting in the backlog at the top of the backlog or whatever, but I know that I'm actually gonna do this next.

Brian: 28:44 I think it's great for when the backlog prioritization isn't enough, so if you're kind of prioritizing backlog top down and people are pulling tasks from the backlog and assigning themselves or just kind of moving stuff to In Progress, if you need a better way to kind of show what people should be doing next, this Up Next is a great list to do it. Instead of just having a huge backlog and assuming people are gonna pick the right tasks from that top upper piece of the prioritization, you could pull it out, move it into Up Next, and actually delegate out one or two tasks. I would say don't use it unless you have to. If the backlog works for you and that prioritization works well, one less list is always better because you're kind of making it shorter workflow, but if you need it, you need that segmentation, it's a great option to help you kind of delegate and show clearly what people should be doing next.

Tom: 29:33 Yeah. We typically kind of half use this com. If we're on a call and we're like, "Okay, that's not gonna take too long. Let's figure out what we're gonna work on after that," it's a good way to organize and figure out what's happening.

Brian: 29:49 Yeah. We use this on our road map right now. We have a backlog of road map items that we plan to work on, or at least on our radar to work on, and we will kind of pull out some prioritization into an Up Next list, because our backlog can get pretty long, so to look through that backlog all the time, to kind of constantly sift through that, is time consuming and a waste of energy, so having an Up Next list really just segments it out really quickly. When we have a conversation about the road map, we look at it really quickly and say, "Oh, these are the next five things we said were up next." We can see that picture really easily.

Tom: 30:24 Cool. So let's get into some tips for taking action.

Brian: 30:29 The first thing I would recommend is definitely check out the help article that we wrote I mentioned at the top of the podcast. That really lays out a lot of what we talked about today in words so you can really digest it in a little different way. We have screen shot examples of the workflows and things like that. It also gets into some other topics we didn't cover today, like how many lists you use, what are the best practices for number of lists. How can you use tagging or other kind of labeling system to organize your tasks and things like that within that workflow and even getting into some automations and things like that on how you can automate steps in your workflow. A lot more information to kind of dig into a little deeper, so I definitely recommend checking out that article.

Tom: 31:15 All right, yeah. Another big thing. We talked to a lot of people about this workflow and we always end with, "Try this out in a test project, a sample project, pick a smaller project that you have and just try it out. Try out this workflow and see how it works for you."

Brian: 31:35 I think people tend to get an idea for something new, like, "Oh, this baseline workflow could work for us, great. How can we roll this out to our whole team?" Well, wait a minute. Don't over-complicate your life quite yet. Just start it with a sample project first. Make sure that it works. Make sure that people can wrap their heads around it and everybody's on board with this kind of approach before wasting a lot of time, like documenting process, figuring out how to roll it out to your team or company. Just don't put the cart before the horse. Really make sure you're comfortable with it and it will also give you an opportunity to get feedback on that process from everyone.

Tom: 32:12 Sure. The KISS approach is always the best, right? Keep it simple.

Brian: 32:17 Keep it stupid simple.

Tom: 32:18 Keep it simple, stupid.

Brian: 32:20 Or I guess politically correct is keep it super simple.

Tom: 32:24 Yeah, I guess that's politically correct.

Brian: 32:27 So the next tip is don't be afraid to iterate. In the same spirit of creating a test project, you definitely want that test project to test the waters and get feedback and when you get that feedback, you can't be afraid to make changes to your baseline workflow. After all, this is a baseline. That's why we call it baseline. It's a foundation to kind of start with, but definitely should be tailored to kind of tweaks and little things happening in your workflow. Maybe you need to add an extra list, maybe you need to take a list away, whatever it might be, but as feedback comes in, if it makes sense, an entire team kind of working in this flow, definitely don't be afraid to change it, test that, get more feedback until you're really super comfortable with how the workflow is.

Brian: 33:10 We've been at this for a while, even with Rindle, and we've made quite a bit of tweaks here and there to our workflow as we figure things out.

Tom: 33:16 Yeah, we make changes on a per project basis. We have a lot of different boards and some boards don't even end up having these columns at all by the end of them, because we're using them for something completely different where it's a different type of workflow, but it typically always starts out this way, because it's a good baseline.

Brian: 33:37 Yeah, that's a really good point. Our road map board has a different workflow than our development board, than our marketing board, than our podcast board. We are tailoring and starting kind of with this baseline approach, but tailoring it to each type of workflow for the need at hand.

Tom: 33:54 I think the last point tip that we want to offer is basically if you feel that this is too basic and your workflow is more complicated, it might justify your team actually sitting down and doing an exercise in order to define a custom workflow, which Brian, you actually have created a workflow webinar, right?

Brian: 34:18 Yeah. We did a webinar on visual workflow and kind of how to define and create a visual workflow for your team. Sometimes the best thing to do is kind of get everybody in a room together and talk about all the work that's on your current plate for each individual person, how that work currently flows to your team, and kind of document that and the end product for that process is kind of a customized visual workflow that's really super tailored to your team.

Brian: 34:47 If you feel like this is a great baseline, but I just know our process is more complicated than this and we're just a much more involved team into what ever aspect of work we're doing," then this might be a great option for you in the same spirit of this kind of more visual approach, this kind of a list left to right approach. You can still tailor it to exactly what your team needs, it just might take a little extra collaboration to make that happen.

Tom: 35:13 I think it's really important to do these exercises as a team and develop this workflow as a team because if you do that, you'll get more buy in from the team. If everyone has a say in what the workflow should be and understands the reasoning behind it, they're more likely to use it and buy in in project management is I think a really important thing.

Brian: 35:39 Couldn't agree more. I think that's actually probably another podcast episode that we could put together, but it's one hundred million percent accurate. It will make your whole life easier if you include your team in the process.

Tom: 35:52 Well I think that about wraps us up for the day. If you have a question for us, you can call it into our voicemail number at 860-577-2293, or you can email it to us at workflow@rindle.com. Our theme music is an excerpt from Thunder Rock by MagikStudio, used under creative comments. Subscribe to us on iTunes by searching for workflow and visit rindle.com/workflow-podcast for a full transcript of each episode. Thanks for listening, and we'll see you next time.