All right, so here is something that I say and every single meeting with every single potential client we have a Titan It's a little weird saying it here, but whatever. It's fine What we do at Titan in terms of our development workflow is we pick up the most important week of work that can possibly be done for you And then we do the best job we can of doing that and then we deliver it to you and when you're ready We ship and then we do that same process over and over and over again until you 're happy with the outcome That's our development methodology and there's tons of other development method

're happy with the outcome That's our development methodology and there's tons of other development method ologies that are worth considering I want to name specifically that we've used base camps shape up before some for some clients And we had a really good time with it So I want to honor those, but I don't want to honor all other ways of doing development Actually, the vast majority of development methodologies that I've seen are things that I think are

Actually, the vast majority of development methodologies that I've seen are things that I think are Particularly damaging to the likelihood of any work actually getting done because they serve leadership Not actual development happening and we can talk about that in all in a little bit But I do want to say of all the different development methodologies that I've tried of ways to figure out Tasking and who's working on what when I've never been unhappy with this simple weekly cadence we've come up with

Tasking and who's working on what when I've never been unhappy with this simple weekly cadence we've come up with So let's get started by talking about what our cadence is for meetings with the client because a lot of these systems So structure things around sprint retrospectives or planings or anything like that once a week we meet up with the client And we say here's what we did last week see if they have any notes about it and any feedback We say here It's what we're gonna do next week and we can ask them any questions we have or

We say here It's what we're gonna do next week and we can ask them any questions we have or they can give us any notes to make sure that We're gonna do it according to their goals And then that's really it for the meeting and in between meetings. We only meet internally if necessary Everyone's in a while. It's a quick meeting to you know to show the PM something But it's usually just pair programming sessions or the main meetings that happen

But it's usually just pair programming sessions or the main meetings that happen But we don't have daily stand-ups. We don't have sprint retrospectives or planning sessions Literally just these weekly check-ins handle all of those functions and it works great for us There are a decent number of clients that will give that the end of every single day a written update just says Here's what I worked on quick bullet points and some clients, especially more technical clients

Here's what I worked on quick bullet points and some clients, especially more technical clients We'll ask for pairing sessions with our developers or planning sessions with our PM So there are opportunities for other meetings But at the core the actual kind of tasking system is based around the single weekly meeting Everybody together in one place recapping the previous works weeks work and planning the next For years I've been talking on the internet about what I call lowercase a agile

planning the next For years I've been talking on the internet about what I call lowercase a agile which is just the delineation between agile as an adjective, you know, we move in a way that is agile versus agile, which is a formal structure The agile manifesto notice agile net agile manifesto was a document and it talked about how we can work with agility how we can be agile Which is literally just an adjective that means able to move quickly able to move easily able to change directions quickly And since then an entire world an entire consulting ecosystem has developed co-

move easily able to change directions quickly And since then an entire world an entire consulting ecosystem has developed co- opting Some of the ideas and a lot of the language of agile and it's called agile but I don't actually believe in agile I don't believe in scrum I think the entire agile industrial complex is a scam And I have never once in my career seen a team become more effective in defining and delivering tasks and value and working software Because they switch to agile

defining and delivering tasks and value and working software Because they switch to agile I have seen it go the opposite direction They switch to agile because things are wrong and they get more wrong and now there's more money in the pockets of consultants However, I think the agile manifesto and the idea of agility in the first place Is the most brilliant thing that's ever happened to development team feature definition and delivery If you haven't read the agile manifesto, it's super short It's 12 points and I definitely recommend you check it out

If you haven't read the agile manifesto, it's super short It's 12 points and I definitely recommend you check it out I would love to cover the whole thing here But once again, I don't have time But if you're looking for some spice in your version of that check out the more modern work of somebody named allen holob Who really kind of takes it a little bit further The manifesto itself though has 12 principles behind it And if you read them, you will hear echoes of many of those points in this course and not just in this video

And if you read them, you will hear echoes of many of those points in this course and not just in this video For this particular episode, there's two points that are really key and it's the first two Early and continuous delivery of valuable software Unbothered by changing requirements, and that's not how they word it But those are kind of general ideas and every aspect of my ideal tasking system wants to enable those things to happen And now I'm going to introduce you to my ideal development workflow at least as I have access to right now

And now I'm going to introduce you to my ideal development workflow at least as I have access to right now Kanban Kanban is a way of visualizing tasks created by Toyota I think in the 60s and inspired from their perspective by how supermarkets namely pigly wiggly in the US Handle stocking The goals of Kanban are to make it easy to visualize work that needs to be done And track its movement through the various stages of progression or for our sake for the various stages of development

And track its movement through the various stages of progression or for our sake for the various stages of development So it can be used for lots of purposes, but I think it's especially well suited for software development There are a lot of different tools that you can use to implement Kanban A lot of folks add Kanban after the fact you can start simple with something like Trello You can become enormously difficult to deal with like jira or new and sexy like linear But I'd recommend if you're getting started and you're not attached to a tool

linear But I'd recommend if you're getting started and you're not attached to a tool trello is simple and proven and it's a great place to start So with Kanban, you can change what your columns are based on the project or based on how you work But I'd recommend at least ideologically starting with four to do Doing ready for review and done Cards which represent tasks start on the left and move right until they're done And within each column the top to bottom order can mean many things But very often it represents priority or sometimes time

And within each column the top to bottom order can mean many things But very often it represents priority or sometimes time So on our weekly meetings with the client We take a look at the to-do column and we make sure there's at least what feels like around a week worth of work in that column And that those cards in that week worth of work all make sense enough that we can actually implement them right now without further meetings with the client We also make sure that the top priority work that the client wants done is at the top of that list And then we pull those until they're done

the top of that list And then we pull those until they're done But unlike scrum and a lot of other agile sprint based systems Kanban is never locked If we pull a card and we need to change our priority or focus midweek, we just do If we reach the end of the week and we run out of work, we just pull another card Or if we reach the end of the week and a card that we're working on is not done , we just don't finish it

Or if we reach the end of the week and a card that we're working on is not done , we just don't finish it It's not a big deal and we're not structuring things around the expectations of the sprint And I make this reference all the time and I'll make it again here People are not made for systems. We don't work long hours trying to cram a task in before the weekly meeting Or tool at our thumbs at the end of a sprint because god forbid we start something at the end of the week We're not confident we can finish within the week

something at the end of the week We're not confident we can finish within the week That's a dumb way of working and it's not actually productive Systems are made for us to be productive and they should bend and flex for us when necessary So we can stay productive and just like with code-based processes These task processes exist to support developers writing and shipping good code Not supporting them getting their velocity aligned with a number of commits to match some t-shirt Size planning poker estimate they made two weeks ago when they barely

match some t-shirt Size planning poker estimate they made two weeks ago when they barely comprehended this task So let's say you've agreed with me you know that conban is a way to go and now you need to figure out What does it look like to define a task in an actual card in your conban? Well, you want to define as minimally as possible. I would say bare minimum a sentence fragment What it would look like for somebody who does not understand this task to know enough to do it

What it would look like for somebody who does not understand this task to know enough to do it You could say something like add user login and the more likely it is that that 's going to be misunderstood by the developer The more you need to explain For example, you could write allow users to log in with github And that's actually a decent card in some settings and not in others It requires the developer to figure out where the github button should go How to handle it if the user's github provided email already exists in the database as a normal user

How to handle it if the user's github provided email already exists in the database as a normal user If you're not using layer value, you might have to figure out what tooling do we want to use for this and on and on and that could be fine If you have independent developers my favorite who could make these sort of choices and a client or product owner who's fine for them? Do so also my favorite then allow users to log in with github is a perfectly well-defined task But if not if you know that your client or business team is going to be mega picky

But if not if you know that your client or business team is going to be mega picky Or if they need to run everything through the designer first or if this particular developer is not yet capable of making these sorts of decisions on the fly To get this card to a point where it's fleshed out in a way that it is defined the must-haves Like if it must look this way, then it's there if it must have a particular workflow It's there, but again keep it as minimal as possible

workflow It's there, but again keep it as minimal as possible And then uh at that point the dev is capable of picking it up You will not be surprised to hear me say this, but I highly recommend keeping your cards as simple as possible And I would much prefer a card that says allow users to log in with github And then freedom to do what makes the most sense over a extremely complicated one with four pages of spec But that's not always possible. So you do what you can More often than not your tasks will come from your client or your product owner

But that's not always possible. So you do what you can More often than not your tasks will come from your client or your product owner as large ill-defined features Complete with unhelpful prescriptions on how to solve the problem Which is your domain, but not enough information about why or to what end which should be their domain The goal of a project manager or process lead is to work together with business to flesh out those non-technical aspects of the feature spec to make it clear How it should work and why and then they're going to work together with the technical lead to split that up from a

How it should work and why and then they're going to work together with the technical lead to split that up from a Sense of what makes sense to split up from a technical perspective because sometimes Feature splits don't always line up the same as as technical splits you get the two together And they'll find the best kind of scenario the best solution for that And then what that means you're going to end up with is features that span many cards Often a card is just one task that's one piece of a larger feature

cards Often a card is just one task that's one piece of a larger feature And so you can imagine your feature might be something like add social off Well, it turns out what we need to do is a card for setting up the area for those social off buttons to go in They might have a card for every single social off provider that we're going to add And then maybe later we're going to add a card that says oops We didn't expect that github would allow you to social off without having an email address back

We didn't expect that github would allow you to social off without having an email address back And so we need to add off logic for that to actually work in our application You're splitting up these tasks into the smallest unit of useful change That a client can reprove if it's a feature or another developer can approve If it's a purely technical task And obviously the smallest amount you can approve is a pretty arbitrary measure But I would just say if you're unsure always err on the side of smaller tasks There's very little cost that comes from completing four tasks in a day But there's a lot of costs that comes from completing only one task every two

There's very little cost that comes from completing four tasks in a day But there's a lot of costs that comes from completing only one task every two weeks So if you're not sure keep them small As such the ideal cards on a compound board can be done in hours or days not weeks or months If your card takes more in a week, it's more than one card But that's fine First of all, this is a learning process and second of all you might learn that a day or two in

First of all, this is a learning process and second of all you might learn that a day or two in You can split out the task between multiple cards midway That's actually one of the big beauties of Kanban is that you don't have to do it perfect at first You do the best with what you have But then the longer you've worked on the project or feature or even task the more you'll know And as you know more you update the Kanban card or the Kanban board And sometimes those updates mean we have to take a task that we thought would

And as you know more you update the Kanban card or the Kanban board And sometimes those updates mean we have to take a task that we thought would take a certain amount of time And then split it out in multiple tasks and sometimes it makes it larger and longer That just means we need to have a conversation about what that means to our team Should we cut some of the subtasks? Should we push them to another phase? Do we just need to communicate that we're going to deliver later than we expected?

Do we just need to communicate that we're going to deliver later than we expected? These are all reasonable options, but in order to See them as options and know which to take you have to split everything out into different cards first So as i've already said, I prefer simply to find tasks that give the developer the ability to do what makes the most sense to them I don't hire people without any real-world experience. We're looking for empat hetic Considerate people who want to understand the customer and build what actually

hetic Considerate people who want to understand the customer and build what actually makes the most sense for them And these people are therefore uniquely positioned to combine their expertise in programming so in solving problems With their understanding of the need in order to make the best final outcome that anybody could make So i'm looking to give developers reasonably reasonably fleshed out tasks With immediate access to business or client or product owner or whatever for clarification

With immediate access to business or client or product owner or whatever for clarification And then leeway to make the best choice that they can figure out And we have other developers and pms looking at all the work they do So it's not like anyone's going to go rogue and commit something to the client that we don't believe in So this is a really safe option If you've ever read the enders game, I just finished reading it with my son for the umpteenth time There's a classic way at battle school for building armies

the umpteenth time There's a classic way at battle school for building armies The leadership tells everybody exactly what to do But then when the battle gets going they're all left waiting for input for the leaders And then they're overwhelmed and they don't get any feedbacks. They're kind of useless But then there's the ender way of building armies where he builds small groups Led by empowered leaders who do understand his overall goals and check in occasionally

Led by empowered leaders who do understand his overall goals and check in occasionally But they have agency and practice to do what makes the most sense in the moment So as development managers, I want us to be more like ender I've mentioned pair programming a few times throughout this course, but I haven 't talked a ton about it There's not really a ton to pair programming effectively There are more complex forms and if you read anything from the extreme programming folks You'll probably see there's a very right and wrong way to do it according to

programming folks You'll probably see there's a very right and wrong way to do it according to some folks But for me the end Pair programming is just two people working on the same code on the same screen Doesn't even have to be the same physical screen I think we've proven that remote pair programming works just fine Usually one person is driving, which means they have the keyboard in the mouse And the other person is taking more of like a high level look They're reviewing code. They're maybe looking up ideas and syntax and

And the other person is taking more of like a high level look They're reviewing code. They're maybe looking up ideas and syntax and requirements They might be making longer-term plans And the driver can and should change throughout the pair session So sometimes you're driving and sometimes you're planning At Titan, we just use zoom for pairing because we already use it for business stuff But there's also a tool called tuple built specifically for pairing. That's also very popular

But there's also a tool called tuple built specifically for pairing. That's also very popular I put this section in the episode about task Process because the idea that two developers are working on the same task at the same time Can often be scary from a tasking perspective Doesn't that mean they're just going to be half as fast? But in the end healthy pair programming is an opportunity to effectively build Coding and code review into the same step even also some planning You have two full brains worth of insight and two full brains worth of

Coding and code review into the same step even also some planning You have two full brains worth of insight and two full brains worth of experience Working on the same task at the same time And you usually find that your team doesn't want to pair on all tasks But a specific set of tasks that match their own internal criteria That make it make the most sense for them to pair on And the tasks that they want to pair on are usually the tasks that they'd get slowed down on Or have to do more planning on or ask for more review on anyway

slowed down on Or have to do more planning on or ask for more review on anyway And they'd end up reaching for help anyway Don't worry that pair programming is going to mess up your tasking or your pace As long as you have responsible developers working on it So there are many much more complicated systems and tools and processes You can use from what I talked about here You could use JIRA You could have used Pivotal Tracker in the past Although there are IP now

You could have used Pivotal Tracker in the past Although there are IP now You could use Scrum You could use ShapeUp In the end you're going to have to figure out what makes the most sense for your team But pick something and stick to it for sure But I will tell you right now that the temptation that most people in leadership positions have Is to be too structured

leadership positions have Is to be too structured Too formal Too micromanaging Not the opposite direction So whatever you do I would just say Please start as simple as you can Only add complexity when it's actually necessary And ensure that when you're adding something You're doing it because you actually have proof it's going to benefit the team

And ensure that when you're adding something You're doing it because you actually have proof it's going to benefit the team Versus it's just what people do Because if I see one more company That in the absence of knowing how to run a dev team well Just chooses to go all out and scrum and JIRA Save my blood pressure please Keep it simple