In Agile, executing is often prioritised over planning. However, not planning enough can be as costly as planning too much. Herman Swart, Custom Project Development Manager at Tangent Solutions, thinks that rigorous planning is critical, even in Agile. The skill, he says, comes in knowing when you’ve planned enough, and he’s set up a process that helps his team reach the optimal amount of planning for every project.

Herman_Clock_6-Steps-to-Spend-the-Right-Amount-of-Time-Planning-a-Project_Inner-Article-Image

Herman says that the misconception in Agile he sometimes encounters is that teams should jump into execution as soon as they can. Although he doesn’t think the entire project should be spent planning, executing shouldn’t come at the cost of sufficient and structured planning stages:

“Planning is a fundamental part to get the project out the door. In my opinion, planning sets the baseline for all expectations, all requirements, and the overall project functions.”

Too much planning might risk team morale, productivity, and overengineering the details of the project - details that are bound to change once you get going anyway; too little planning, on the other hand, could risk unforeseen changes down the line, meaning you backtrack on work you’ve already done, or that you need to add days of production to your timeline.

Herman’s team has a six step planning process, divided into two phases, for scoping a project before execution. He talks through each step in our conversation, which can be found at the time stamps alongside:

1. THE PROPOSAL PHASE

[00:22:22] 1.1 The project proposal: Understanding the client’s wants and needs

[00:28:33] 1.2 Scope of work: Laying out the delivery

2. THE DEVELOPMENT PHASE

[00:41:00] 2.1 Resource allocation: Finding the right people to do the right things

[00:45:12] 2.2 Client briefing session: Setting roles and responsibilities

[00:50:21] 2.3 Product backlog and feature list: Planning sprints and deliverables

[00:57:51] 2.4 Project setup: Setting up environments and addressing dependencies

____

Transcript:

[00:02:42] Jomiro: So thanks for being on the podcast and making time to chat. I know it's a bit up in the air for everyone at the moment, with coronavirus and COVID-19, but it's super, super cool to have you hear.

Herman: Awesome, thanks for having me, man.

[00:02:58] Jomiro: So for people who are listening, could you start with just some sort of insight into how your development team in particular is set up? So how many people are you, and sort of how is your team organised?

Herman [00:03:08]: Cool, so basically what we do is we tackle projects. So we have a bunch of developers on a bench - or, I wouldn't say bench but on the floor - and then when a specific client or requirement comes in, we then React accordingly. So we would then stack up guys in a team that will make a self-sufficient running development team. So it's basically a ‘pick of the litter’, so we would just pick and assign developers to project and take it from there. Our main focus and main methodology that we use is Scrum, so we use spring to develop features.

[00:04:07] Jomiro: So your team is actually quite dynamic. From that, it seems like you don't have fixed teams, necessarily. It's a project by project basis.

Herman: Correct, correct. The only qualifying criteria for a specific project is then the tech stack, so we won't have React guys sit with UJS or something like that. It's more like a Django PHP React or Xamarin kind of platform or tech stack. And then all the developers according to that tech stack will then be added on too.

[00:04:43] Jomiro: Team dynamics must be super important for you, then, because you sort of have to be able to work with everyone, basically.

Herman: That's true. There's two elements, in my opinion. You have the tech stack and then the actual personality. There are a couple of guys that I can just see, by just you mentioning that, that won't be able to work on the same team. They have the same team, or they have the same technology and tech stack, but you won't put them in the same team. So the dynamics of people are just as important.

[00:05:22] Jomiro: So yeah, I mean I think what you were talking about with Scrum, what is your favorite part about that methodology in your team and being able to use that? Is there a particular example that comes to mind where it saved you?

Herman: So in the old days, when we just got the project and kind of ‘fake-Agile’ tried to develop it, the key fundamentals of Scrum were kind of lost and not adhered to. But for me it's the interaction that you have with the client and the developers... So a client or the product owner from the client side forms part of your team, and that is such an important thing. A developer knows what is expected. There are so many unknowns when you have a project just from a piece of paper, but this way any blockers or impediments get resolved then and there, because the developers have the ability to actually chat to or engage with the client in a technical term. So I think for me it's literally that transparency and communication. That's one of the big wins.

[00:06:42] Jomiro: Yeah, and you've spoken before about this sort of misconception, that Agile means little planning, quick execution. It's about super fast iteration cycles. But you've made a point to emphasize the planning and the project setup quite a lot. Why emphasize that so much?

Herman: Sure, but so to be fair, the only reason this is important and forms part of the project phase is the fact that we're still dealing with an industry bound to the financial year-ends, budgets, ROIs and stuff like that. So planning just sets the groundwork in order to manage those limitations, say, for other clients, meaning that they can provide us with a budget, and that allows us to look at the budget, see what they have available and then in a Agile way kind of manage expectations against return on investment so with the Scrum methodology, the communication is always there.

So you would say, "Look, you want these three features. Let's make an MVP first. That's going to cost, or we're going to take, two or three sprints to get this done." And then that opens up and kind of teaches the client to not think about budget or set amounts, which in our industry is, funny enough, one of the biggest hurdles that we have.

[00:08:20] Jomiro: So it's got something to do with clients maybe not being so used to... I mean, maybe the fintech industry is slightly unique, and your context is slightly unique, where clients don't necessarily know Agile and Scrum very well. But focusing on planning and having that set up maybe explicated slightly more than you normally would, helps build that relationship and also obviously makes it less risky, I guess, to some degree.

Herman: Definitely, and also the clients that you work with has got a misconception around what Agile is. If you start talking to a CEO about Agile, the only thing he can think about at the end of that meeting is, okay, this company came to me. I have to open my wallet, and maybe something great will come out of it. So it's literally, it's so difficult; but client education and clients getting the right information to the client is just as important as actually producing a platform or a product or feature for developers.

[00:09:29] Jomiro: And what would you say to someone who maybe responds with this idea of you spend too much time on planning? You're not doing as much or not doing as well as you can. What would you say to someone?

Herman: So on that one, planning is and always will be the essential part of any execution; it doesn't matter what. Think of the situation we are in currently. Companies and entire industries need to plan on how to keep the company going and the gears running, how to get stuff delivered, how to keep shops open. But it is, in theory, an Agile Reactive kind of thinking.

So planning is a fundamental part to get the project out the door. So in my opinion, planning sets the baseline for all expectations, requirements and the overall project functions. When I mention planning, it's not to say that it's for the entirety of the project. So if a company wants a mobile app that links into payment gateways, and there's users, and think of the biggest app like writing a Uber. So we're not writing Uber with Uber Eats and all that kind of stuff. It's literally we're starting off iterations or sprints. So you work out what the MVP is. What can they get out to the market quickly in order to make their money back? And that's where the conversation slots with planning. That planning is then for MVP, and then once that MVP is discussed and kind of ring fenced, then the team and everyone involved can actually start to plan the product backlog, even the project backlog.

But then the product backlog and Scrum backlog comes from there, and the planning would literally be two or three or four weeks, depending on the iteration length. It'll do that planning to a task level like proper, proper planning.

[00:11:51] Jomiro: Right, so there's the planning before the MVP, and then there's the planning once you've sort of have a running MVP, right?

Herman: Exactly, exactly.

[00:12:01] Jomiro: And how much time do you spend on that? I think you said two to four weeks. Is that for that initial step before the MVP planning?

Herman: Sure, so I would say the initial... so when we engage with the clients, and we have this discussion on “What would you like to have?”, there's a difference between asking a client what they would like to have and what they need to have. So what they need to have is that kind of MVP mentality in getting them to think small, think iteration wise, think feature wise. So if they have an application that can work off of three features, that is the MVP, and that's what we build.

So planning on that scale is rather the bigger picture for what they would like to have, is kind of a workshop, getting all of the wishlist items out of there. And then from that workshop, it is the MVP discussion, which is a similar workshop. And then once we have all of the needs and wants, and everybody is happy with the MVP, that's when you sit with the team and the company to go, right. This is what we're doing. This is our sprint goal. This is MVP requirements or vision for it.

[00:13:25] Jomiro: I think a skill we can all learn from is knowing the difference between what we'd like to have and what we need to have. So I think that's an across-the-board skill. But that's really interesting. We'll dive into some of that planning just now. One thing I did want to ask you before we jump into your actual process, in this importance of planning, what have you experienced as hurdles or challenges or difficulties when you haven't put enough time into planning? What are some of the impacts of not planning enough?

Herman: Not planning enough, I would say it breeds a culture of cowboys. In our industry, everybody likes to be called a cowboy, or they know the term, cowboy. It always goes that it's more the developers make the choices on the client's behalf, because the steps weren’t followed. We'll talk a little bit later about the process. If that's not followed, it opens up so many uncertainties. And with uncertainty comes, in my opinion, bad code, or bad decisions, or bad decisions that result into bad code.

So I've had many projects handed to me, and there's nothing, absolutely nothing. It's just people going from day to day. They don't have an end goal, and giving somebody a project to do with no direction or finish line, I think in my opinion, that's the worst thing you can do for any developer. So yeah, I think it's literally just creating that safe environment to put everyone on the same page for the same goal, which the client has agreed upon.

[00:15:29] Jomiro: Cool, so certainty of having a finish line, having an end goal, those are all what you want to get out of your planning. That's your north star, I guess.

Herman: And it sounds so simple, but it just comes down to human nature. You won't start something that you would never finish. Why put in the effort? Why drive or go to work every day, or in our situation now, just sit at your desk? So yeah, that's very, very important. And without proper planning, it's 99.9% projects that fail.

[00:16:10] Jomiro: And would you say that Agile is maybe particularly vulnerable to not enough planning? Do you think people get caught in that must iterate quickly sort of mindset?

Herman: 100%. I was part of... so I did my Scrum master certification a while back, and something that came out of that is a company that gets forced into being Agile. So one day the CEO pitches up and says, "Okay, everyone, we're doing Agile." It's a gateway for everyone to, especially in the corporate environment, to go “Cool, it's Agile. I don't have to plan. I don't have to do budgets, I don't have to do project reports or anything like that. It's YOLO.” Everyone is just out there, and I think that's kind of what breaks Agile at the moment, is the misinformation around all the conceptions that people have, what Agile actually is. So I think the lack of knowledge is kind of hurting it at the moment.

[00:17:16] Jomiro: Cool, so on that, I think getting a little bit of insight into how you set up your planning is really useful to dive into this now. So when a project comes in, sort of high level, what is your step-by-step process from start to finish in your sort of back planning and setup?

Herman: Cool, so I think, and we'll keep it simple, and there is quite a lot of other steps going into this as well, but in short, the main process for the Agile project management and setup from our side is we have two stages. We have the proposal stage and then the development stage. Obviously we'll have handovers and SLA stages afterwards, but that depends on the client. So basically from a proposal stage is a proposal is compiled with the assistance of a dedicated technical team, which is the most important thing for me. If you have a solution for a client, let the developers look at it. A sales guy can't literally just think that he knows everything and then put a random amount in there, the client is happy, and they sign it off. The development team needs to be involved or not the team itself but a technical advisory team. They'll just be there for the proposal side.

Then once that is established, and the client is happy with everything that we do, the client onboarding, and then we do what we call the scope of work. So the scope of work is that little MVP that I spoke about. So that's where that workshop comes out, and then we'll try our best to break those into predefined sprints.

So every sprint, a client already has a high-level idea of what's coming because of a technical team looking at it. They would then prioritise the project features to make sense at the end of the day. We're not going to start with a single user if there are a hierarchy of 50 users that we need to create. So they'll make sure the priorities are in line for actual development and kind of convince the product owner or the client that that's the way to go. Then from there, we step into the project development stage, which then the resource allocation happens like we said.

We've got the open floor. We pull in guys that are able and capable to create a self-sustaining team, which means business analysts, graphic designers, UX/UI designers, all of those guys besides the actual developers, front and backend stack, whatever you need. Then the development team gets a briefing from the client, so that's when we introduce the team to the client. So the client then has got an opportunity to sell their idea to the developers. They need to convince the developers what they're doing is for the greater good, and it has an impact. Telling a developer that he's doing something great is different to showing him from a client's perspective why they're doing something great.

Then we go into the product backlog, and then we set everything up in Azure, and then we follow our Scrum methodology for the execution. And that's a high level, basically what we do from the time we get a client in.

[00:21:07] Jomiro: And am I right in saying that the timeline for that process generally depends on the actual product itself. You don't have a set from start to finish, necessarily.

Herman: No, it all depends. So the nice thing about this process is you can go through each and every step, but for a small client and for a small project, it just happens quicker. So we try our best to follow the process or keep following the process without breaking anything within it, so at the end of the day, we have all the boxes checked when we deliver the project, regardless of the size.

[00:21:48] Jomiro: And I assume, I mean there's obviously dependencies on waiting for clients to respond and stuff, but I'm sure within your own, the sort of workflows you have at each part of the process, you have ideal timelines that you try and stick to.

Herman: 100%. And just to mention the scope of work, just the one step before the project development, that scope of work has got timelines attached to it as well. So once the client sees the timelines, they will sign off on that. So they would know a start date for the project.

[00:22:22] Jomiro: Cool, I will definitely ask you more about that when we get to the ‘scope of work’ part, but let's start unpacking it straight from the beginning. So you said the first sort of step is that whole proposal that gets sent to the client. So tell me more about what actually happens there. Who is involved, and what kind of tools do you use, or what does it look like?

Herman: So we have Leah on our team. And she'll probably kill me if I said this. She's a business architect. Yeah, I wanted to say business analyst, but she's way higher than that. So she's the business architect that takes the client through a process.

So she gets all the needs and wants out of the client themselves, and then she presents this to the team. Then we sit with, and this is still the proposal stage. Then we can sit and think about what is the best technical way for us to assist the client. And that's kind of where tech stacks and those kinds of discussions come in as well.

Once that is established, then we can look at a broader view on things like, in this industry on previously delivered projects, and things like that. We are able to gauge an estimation of how much or how long this is going to take. And that's kind of where the proposal ends, and we share that with the client and say, "Listen, if you want to do this, we estimate it at 1.5 million to 2 million including all of these things." So we'll set the 2 million bar, but we can do an MVP for your needs, because the proposal is the “what”, and out of the proposal we get the needs, which is the scope of work for a specific feature.

So we'll break up a proposal into three, four, five phases, depending on how the project is or how long they're going to spend on getting it out to market.

[00:24:39] Jomiro: Cool, and that's sort of ... Okay, so they obviously get the chat with their wants and needs. You give some sort of idea of the tech solutions you can offer, but the way you sort of court them or give them an idea of commitment and timeline at this stage, is up until the MVP point, or is it like project completion sort of thing?

Herman: It would be project completion, but sometimes, like a current client that we have, the overall scope or the overall project is... There's too many unknowns, even on their side. So then we dial it back and say, "Cool, the proposal for this one would only be for the MVP."

[00:25:19] Jomiro: Okay, so you sort of gauge how many unknowns there are and then adjust the dynamic dynamism, I guess. Cool, that makes sense. So you haven't actually decided on the teams, the actual squad that's working on this thing at this point yet.

Herman: No.

[00:25:35] Jomiro: So when you said your team sort of looks at the wants and needs of the company, how big is that team, or who is sitting on that?

Herman: So I really do like having two types of guys in there. So one is always a cloud guy so Azure or... What's the other silly one? AWS, sorry, I'm a big Microsoft guy. But we code for both, so I'll have an architect from the cloud team, and then I'll have an architect - or an architect and a senior on the full stack section. So, if we can see this is going into more of a Django, because it's kind of prebuilt things, or they requested React, or they requested something else, I'll get the MVPs in our company to assist with the estimations.

[00:26:42] Jomiro: And what is the impact of having this step and doing it well? How does it actually either set your team up well later?

Herman: Yep, 100%.

[00:26:53] Jomiro: What sort of benefits does it have, and what do they look like?

Herman: So the benefits of this is, especially with the tech stack and time estimations, is let's say, for instance, we had a client that came in, Leah took this, estimated it at six months on React. Then we get the project. Everything is signed of, and we get to the scope of work. We kind of break down all the tasks and make sure that we get the project set up in Azure, all of those things. Then it's a thing of we think it might be better to do it in Django. That's fine, let's do it in Django. And then it loses its validity, because there might be a reason why the client wants to React, or there might be a reason they asked you something. And if the planning isn't done, and that discussion wasn't had, it's just going to be an absolute, absolute mess. The client is going to get something, and the first thing they're going to ask is, “What is this? Why have you changed the tech stack?” Or some really hard-hitting questions that scientists often ask if there's no planning involved or the setup isn't done correctly.

[00:28:17] Jomiro: So it sort of irons out the wrinkles that could turn into creases that mean you have to redo huge amounts of work later down the line.

Herman: Exactly, exactly.

[00:28:26] Jomiro: Cool, so it's really proactive and preemptive, yeah.

Herman: 100%, yeah, exactly what you said there.

Jomiro [00:28:33]: Sweet, so okay, so this is the sort of first proposal step. Okay, so what comes next? After a client has seen the proposal, and they're happy, what's your next course of action?

Herman: Then we go into the scope of work. So the scope of work is a detailed view of the agreed upon work to be done. So this one we'll break down, if it's a big project, we'll break it down into phases. And then a scope of work will be for a specific phase, so if they need a feature delivered or a couple of features delivered, we'll break that into a scope of work. So a scope of work is basically a textbook for a developer to go: “I have to do the following in order to satisfy the client's needs.”

So we break that own into iterations, and then the team or the seniors and architects involved would also assist in this, because they would know how to build a application from the ground up, lay the foundation, make sure authentication is there, make sure there's user permissions and that kind of build up before we get to the nice UX/UI, layout and design and all those kinds of stuff. So with the scope of work, the client also knows what to expect at the end of each sprint. So we would say to them, "Cool, so for the first two weeks, we'll be able to set up your Azure. We'll set up the project. We'll get everyone on board. We'll start off getting..." Maybe there's Kubernetes required, Kubernetes clusters and servers and all of those kind of things.

So then at the end of those two weeks, it's kind of a, “Hey, teacher, here is my homework.” So it's kind of the client knows what to expect, and within that two weeks, we'll have the Scrum methodology running. So if anything comes up, the client is the first to know. So if there's an issue with Azure or AWS or storage or something, the client is aware of it, and then that's where the discussion comes into, "Our sprint goal was this. Remember we had all of these little needs and wants that we can finish, but we took them out of the sprint. We added some other stuff. This is your new expectancy list. And then you know what?

From my experience, every single time we have a demo to a client, it's just an absolute pleasure, because they know what to expect. They don't ask questions they don't need to ask.

So they're not going to ask about “Why does that block look so weird?” It's not what the design looks like. The client is well aware that it’s the foundation and the functionality first. So it's the developers and their kind of way of doing things is in effect teaching the client to expect in a development kind of phase.

[00:31:41] Jomiro: And something that's just came to mind is, what I like about your ‘building squads according to the project’ is, by having all of that planning and setup and needs and wants outlined, you can actually build a squad that is better equipped, or is equipped with what they need for that specific project. So if, as you were talking about with Kubernetes, if you don't need Kubernetes, don't have an engineer that is highly advanced, whatever the case is, you can actually build teams and build squads. I think that's really cool.

When it comes to actually drilling down a scope of work, what are some of the considerations you have to make? So you're talking about Google auth user permissions, again, I think this is probably down to the specifics of a project - but how do you outline a scope of work? Is it like, okay, first we're going to build a features list, then we're going to plan what we do in each of the sprints? How do you sort of lay that out or set that up?

Herman: So for my teams and my guys as individuals, I have, through retrospectives and going through a couple of those, we've got an acceptance criteria. So each and every developer has got an acceptance criteria for his own work. So if anyone comes to him and say, "Listen, you need to build this feature, or we need to build this feature." He has to go through a predetermined checklist to say, "Cool, how many users are involved? What the environment that we're setting up? What the tech stack? What are the impediments? What are the assumptions, all of those things?" And with all those questions asked in the scope of work, the client will literally answer hopefully 90% of it. Any inconsistency or items that are not defined that well will obviously lose priority.

So everything we know is exactly like the checklist or the acceptance criteria for each of my guys, if that is checked, then we put that into the sprint, which works the same way as with the scope of work.

If we don't know all the details about a certain item, it won't go into the scope of work, because that's kind of just setting yourself or your team up for failure, because you never put something in that's not defined.

Yes, there are assumptions. Yes, there are limitations to stuff, but hardball things, I want to use a login, and that's it. That's not acceptable. My guys would never go okay, cool, we'll put in that. They'll always ask, "How many user types are there? Are there any parents? Are there any children?" Whatever they ask, they'll go through the whole list.

[00:34:39] Jomiro: And do you get clients to answer those sort of acceptance criteria questions in the scope of work, or is that stuff you do in the proposal step just before?

Herman: Some of it would be in the proposal step, so the high level technical team will ask the set of questions based on previous projects or just even personal experience. That's why they are senior, or that's why they are an architect. They know the industry. They know the shortfalls on certain projects. They will ask those questions, and then once those are answered, we'll have the frame of what the product is going to be built on. And then the scope of work is then a drill down on each and every pillar of a foundation to the project or feature.

[00:35:32] Jomiro: Cool. And out of your experience, what has made setting up a scope of work really effective? If someone is trying to do the same, what sort of lessons can you share from your experience with that?

Herman: I would say go through a couple of iterations, like a couple of sprints. Gauge on what the team is capable of. If you feel comfortable on how good your team is or the individuals, that comes as a second nature. Also for a scope of work: There's no such thing as a stupid or unwarranted question in a scope of work. Ask absolutely everything. The more questions you ask, the more answers you will get, and then the more fleshed out a scope of work would be. Think of it as literally an instruction manual on getting something done. You don't get a car manual that is halfway there and that doesn't have all the information in it.

The more information you can put into something like that, the better it is. And because it's small, little iterations, it sounds like we're going and drilling down to the ends of the earth. But in fact, it's just those two weeks.

It's just that little feature that needs to be produced, so ask all the questions around it and get all the answers that you need in order to produce the feature or sprint goal that's required.

[00:37:16] Jomiro: And once you've sort of done the scope of work, you mentioned earlier you also demo it to the client, right?

Herman: Yes.

[00:37:24] Jomiro: What sort of format do you present a scope of work? Is it like a Google doc? Because obviously you need to... It's a combination, if I'm understanding correctly, it's a combination of writing down your process and still asking questions where you need clarification for those acceptance criteria.

Herman: 100%.

[00:37:40] Jomiro: So how do you package that, and I guess what does that demo look like?

Herman: So let's go through the first part. So the scope of work is a document that we present to the client, that they also review. This is now after the workshop and everything has been done. Let's say for instance in this case we are developing an MVP for a very, very large product or project. So we would take that scope of work, make sure that everything is addressed within the MVP and then kind of break it down into deliverables. So in our world or the way that I like to run things [or suggest people to run things] is after every sprint there has to be - and this is kind of a rule: There has to be a deliverable item. There has to be a functioning piece of software that, if the client on that day goes, “I love it”, you press publish, and it goes to production. That's it.

So that also needs to be taken into account when you design and when you lay out your scope of work. You can't just break everything down into, let's say, six sprints here, go for it. It's a thought up process on how the project is going to be developed.

That takes away all the anxiety and uncertainty a client would have in a normal project. If you just stop at the proposal stage, and they give you the money, and now they're going to wait for six months, at the end of that day, it's not going to look as what they thought. So in my opinion, it's just the scope of work and the clarification it provides to the client and the team.

[00:39:43] Jomiro: And I think it must also help with team motivation. I'm just speaking from personal experience. The minute I stop actually producing and shipping things regularly, it's easy to feel board and like you're not getting anywhere. So having a clear deliverable at the end of every sprint gives you that sense of I am making progress on this project.

Herman: Exactly, exactly, and with the - I probably said Scrum like a million times already - but with the burn-down chart with each iteration, I didn't intentionally do this, but the teams are competing on what the burn-down looks like. So they would say they're closer to the average burn-down, or they've exceeded and all that kind of stuff. So it becomes a motivation to see that little burn-down chart ticking down each and every day. And that for me is great, but then you just always need to remind them that, great, you're burning down items. Just make sure that you acceptance criteria has been followed, that the definition of done has been followed, and we give the client a working piece of software at the end of this.

[00:41:00] Jomiro: So cool, scope of work, important things are to make sure that you've got your acceptance criteria answered, the client knows exactly what's expected, what they can expect, and you've got clear deliverables sort of stipulated for all the sprints that you're going to have. Okay, so then do you do the demo. What happens after that? Is that when you start going into - because now you've picked your team as well, the squad that's going to work on it. Is this the now project development execution phase?

Herman: Yeah, 100%. So if scope of work, everything is signed, and everyone is happy with it, then we start with the resource allocation. So first of all we have a brilliant talent management team at Tangent, and they would then look into capacity and all of those kinds of things. So I'll kind of put... and this is the project proposal stage. You would say, "Okay, so this looks 90% signed off. Hey, talent team, these are the guys I'm looking for." And then they'll scour the floor and make sure that the guys coming on the team are dedicated to that project for however long.

And that also assists, the scope of work also assists in telling the talent management team to say, "I will need a guy for six months." And then they can start planning five months down the line, wait to place this resource for another project. So it's a well oiled little machine that's going, and these processes just enable more than just the development side.

[00:42:47] Jomiro: So you actually pick - this is maybe a dumb question - but you pick people not only who are already in your team but also what new hires you need to make for a particular project.

Herman: 100%, yep.

[00:42:59] Jomiro: Super cool. And I guess those are a mixture of permanent and contract based.

Herman: Yeah, exactly.

[00:43:05] Jomiro: Interesting, okay, so resource allocation is actual human capacity?

Herman: Yes.

[00:43:17] Jomiro: Do you have any advice on this particular thing? I know you don't necessarily do it yourself, but what's a good way to think about resource allocation, if you have any ideas?

Herman: Look, there's always an issue with resource allocation because of time and even if you hire someone. On average it takes like two months for a person to get there from hey, we are very interested in you to welcome to Tangent. It takes quite a while. For me it's just that resource allocation, if it's not in shop, to manage the client's expectations. But then again with the process that we follow and the scope of work and having the start date and all of that in there, we would then exactly tell them, "We will start in June." And then why in June? And then it's a conversation like a human conversation at the time stating the fact that it's just resources. It's part of the conversation that you have with your clients, transparency.

[00:44:35] Jomiro: And I think again, another benefit of having it so early on or having those discussions so early on is you can already flag where you might need to make a new hire, which makes resource allocation down the line a lot less reactive. You don't need to say, "I need someone next week." You can look way down the like. Yeah, that makes a lot of sense.

Herman: And remember, from proposal stage and accepting that to the scope of work, there is some time lapse in there. So if they signed off their proposal, that's when the resource team will get the resources for the project.

[00:45:12] Jomiro: Cool. And after resource allocation, what's the sort of next step in your process?

Herman: Then once a team has been put together, then it is the development team and the client briefing session. So this is something I feel very passionate about, is to give the client the opportunity to meet the people that they will be working with every single day. Within this development team, then we set up the roles and responsibilities for the team. So we'll have a Scrum master, we'll have a product owner, and then we'll have the development team. So the product owner is a representative or a subject matter expert on the client side. So yes, we deliver this project to a massive company, but we only answer to one person. We only have that one contact, which is also something very important but not discussed yet, is having that single point of entry when it comes to client requirements.

[00:46:22] Jomiro: I mean maybe just out of interest, what does that help with? Has it been a case of that's not always the way you've done it, and this is a solution to a problem you've had before?

Herman: Definitely, so if you engage with a group of stakeholders or a group of product owners, there's always going to be a trash either on their side that gets dripped over to us, or there is a miscommunication or a break in communication, where you ask a question, and then the one person on the client side is expecting someone else to answer, and that just goes on forever. But the fact that you make a client responsible is ... And you won't believe the positive reinforcement that actually has on a client's perspective, having that one person asking all the questions, getting all the answers. It's CEOs and everybody going to that one single person to make sure that the product is delivered.

[00:47:29] Jomiro: And who do you pick as a product owner? Can it be the CEO of the company, or could it be someone - you said subject matter expert, right?

Herman: Yeah, so in my opinion, a CEO or a high-level person is not... They don't make the best product owners. A product owner is a person that is dedicated to the project at hand, the requirements as well as the assistance thereof. So it is usually a business architect or a person that has created the idea around what the product should be. And like I said, a person that is personally invested in a product or a feature, those definitely make the best product owners.

[00:48:19] Jomiro: Okay, so in this workshop, betting to meet the client is one super important outcome. The other is obviously the roles and responsibilities. Is there anything else that you're trying to get out or sort of checkpoints you're trying to reach in those?

Herman: And then the certain final thing we do in a session like this is we discuss what Scrum is. So this is my opportunity or the team's opportunity to actually teach the client and the newly appointed product owner on how we're going about delivering this process. So we're going through backlog grooming and backlog items and stuff like that, so we kind of teach the client how we are working and then conform their thinking to fit our methodology. And once again, knowledge is power. I think it's something that's been overused, but I don't think people listen to it. As soon as they know what is expected of them, even a client, even a CEO or a CTO, financial officers, whoever, as soon as they know what responsibilities are, they will action it, and that's the best thing.

[00:49:33] Jomiro: And what have you learnt about what works when it comes to communicating Scrum to companies who haven't worked with it before? What are some techniques you use?

Herman: So I don't really think I use a specific technique to kind of do it. If you want to call it a technique, it might be a forceful one.

[00:49:55] Jomiro: Tie them down and -

Herman: No, it's basically hey, here's our rules. Let's play. That's kind of how we approach it, but we do provide documentation and reference and everything. And that comes from 42 Agile. Those guys are also assisting on getting clients on board to Scrum.

[00:50:21] Jomiro: And do you actually touch, in these workshops, do you touch any of the scope of work planning with your clients, or is this sort of now where you've decided that that's the way it's going to be, and after this workshop you can actually go straight into execution?

Herman: 100%, so after this, yeah. So after this workshop, we go straight into the product backlog. So that's literally sitting with the product owner, going through. This is the scope of work. You have signed it already. This is our deliverable for the first week. Let's get the items in there. Once we do the backlog for it or for the entire scope of work, we'll then minimise or condense that into the first set of deliverables. Then the team and the product owner sit together where the product owner is the guide on what the business priority is. And then they development team has the opportunity to guide the product owner into what the development priority is. We don't tell the client what to do. It's just from fundamental ground-up building and application, this is kind of the best way to do it. And that's a back and forth conversation with the product owner, and then out of that we'll then have the sprint backlog, which is all the items that is required and agreed upon by the product owner, the team themselves for the demo two weeks down the line.

[00:53:57] Jomiro: And what criteria do you use when it comes to prioritising a backlog with a product owner? How do you think about A) how you prioritise a backlog when it comes to things there? But also, B) how you communicate what's important? Because I think a product owner who's maybe not a developer thinks that this is really important but may not actually be the most important thing.

Herman: That's where the guidance from the Scrum master and the development team comes into play. Then we go back to the basic questions that we asked the product owner as to what would you like and what do you need. So if we ask that “What do you need?” question, and remind them at the end of these two weeks, we need to give you a deliverable item, a physical item that can work, that we can put into the market, that is usable. That automatically changes their thought process as well.

They were thinking about nice graphics and pictures and all of that, but then when you go and kind of remind them on “What can make you money?”, then they kind of change there. And funny enough, most of... I have three projects running at the moment, and all three product owners would then ask first, "What do you guys think? So the stakeholders want this feature. They want these added. What do you guys think about it? What can we do to get back to the stakeholders?" So it's literally that personal connection that you still have with the client in being able to persuade a group of stakeholders to the developer's way of developing or even thinking and keeping in mind at the end of the two weeks, they can get something substantial.

[00:53:57] Jomiro: I can still imagine people might argue, "No, but I need pretty graphics, otherwise people won't use my app." How do you communicate that that's maybe not what they need? What is ‘need’ in your mind?

[00:54:12] Herman: So look, graphics is ... How can I put this? So if a client comes to you and says, "Look, hardball now, this is the features that we wanted. This is how we would like to do it," then there's going to be a trade off to ... I can give you the functionality, but we won't be able to work on the look and feel up until we have the second release of the application or the platform. Then it's a ... We can accept that within the two weeks, because we have a kind of an estimation on the velocity of the team. So once you have that, then it becomes easy to say to the client, "Okay, great. You want graphics in there. Let's say it'll take two days out of the sprint to get that done and dusted. But then what do we functionally take out to make up for that time?" So once you have that conversation of, "Yes, 100% we'll put that in, but that caps us, so we can't put the following functions in it."

And then they would start thinking and saying, "Rather do functionality over form." And that's kind of the way I approach clients as well, rather have them do functionality over form for the first couple of iterations.

[00:55:47] Jomiro: So what I'm getting out of that, actually having that delivery time or the amount of capacity it takes to push out a feature in a backlog makes it a lot easier to say, "Okay, if you want this feature, it's going to take X amount of time, and we're going to need to move one of the ones that are higher up down." And then they can actually be like, "Okay, if I want a pretty logo to appear here, I may have to give up user login, which maybe is not what I want to do right now. So let's prioritise it differently."

And having that means you don't actually have to tell them, "Look, this is a dumb idea." You can just be like, "Do you want to make this trade off?" And then it's a lot easier for them to deselect themselves from that idea.

Herman: 100%, and it still gives them to the power to do that or to make that decision. If they want form over functionality, that's kind of what we give them. So the scope of the work is an active document and then the sign off. After each delivery, we have a sing-off document that states, "Look, we've delivered these following items. Are you happy with it? Have you seen it? Have you tested it?" Great, and then that’s fine. So it gets tracked, and it gets communicated with clients as much as possible. And going back to the old way of working, how would you have done this with a waterfall project? So them literally giving you a budget, giving you a spec which is probably halfway not done, and at the end they'll get something that doesn't seem like what they expected.

[00:57:34] Jomiro: So this backlog prioritisation or laundry listing, I guess you can call it, at this point am I right in saying you haven't actually written any formal code yet, you haven't built anything necessary? This is all still the setup of the thing, right?

Herman: Yep.

[00:57:51] Jomiro: Cool. After you've done the backlog prioritisation with the client, and it seems like there are two or three, if I understood correctly. What's the next thing?

Herman: After the backlog and everything has been sorted out with the clients, and the team is happy with what is coming up, then we jump into the project setup. So that's either getting my guys onto their environment, making sure that they have the correct access or creating it in Azure from our side.

[00:58:25] Jomiro: And that's just, I guess, making sure that you can work with your client seamlessly so that they can't be like I don't have access, I can't do this.

Herman: Exactly, so that's also setting up the environments, making sure code coverage is there, cloud is installed and that we have... What else do we do? Well obviously the board is set up. Everything has been created. We've got the CICD, so that's literally the base of everything everyone knows, getting the repos up and running and enabling everyone to literally start with the sprint.

[00:59:12] Jomiro: And do you have a central visibility for project progress with the client? Is it like do you use Trello or Asana or some other ...

Herman: That's funny, no. We actually use something that works.

[00:59:28] Jomiro: Ouch!

Herman: No, I'm just teasing. I've worked in Trello and Jira and all those things, and -

[00:59:39] Jomiro: Okay, just to be fair, I don't use Trello. I just threw it out there.

Herman: Sure! But yeah, so we use Azure devops, and within Azure devops there's a feature called Azure boards. And everything that we discussed, all the backlog items, all the tasks, all the repos, everything gets managed and tracked through that.

[01:00:04] Jomiro: And what about Azure do you prefer over something like a Trello or a Jira? What's the thing that makes that the best for you?

Herman: So Azure boards in my opinion, it is a platform that can cater for everything to anything, but the main focus is scale. So you can have a small team with three people in it manage a website, and it's perfect for it. And then you can have a bank setup, environments with Kubernetes clusters and running everything on it. So the scalability of it is absolutely insane. We use teams in the office, and we invite our clients into teams as well, which we hook up all the progress, all the tasks. Everything that is managed on the board is then sent to teams as little messages coming in if there a pull request or something like that. So the client is always aware of what is happening and if intervention or assistance is needed.

[01:01:20] Jomiro: And I guess scalability is important for you, because you never know what size project is going to come in.

Herman: Exactly, and because we try to do the iteration production or execution of projects, we like to go MVP and grow it from there, have that relationship with the client and the capability to scale to whatever they want. If there's something in the market that happens, we can adjust, and we can literally get back to it or get on it as soon as we can.

[01:01:55] Jomiro: Cool, so you've set up your team for access. What else happens in the project setup?

Herman: Then it is one of the most important things is then the definition of done and started. The reason why I say started is the definition of done in my opinion is something that develops over time, especially with a project. So you can't, from the beginning, say, "We are done once we have done the following." Yes, those items are in there, but there might be one or two items that needs to be addressed before we can say definition of that. The product owner might say the CEO has to look at this first. He is a super technical guy, or your code coverage needs to be above 75 or 80. Those small, little things can be added to the definition of done. And then obviously the CICB and alternate the pipelines for, well, plugged into the repos. So you'll build pipelines and release pipelines and stuff like that.

[01:03:12] Jomiro: And from there you pretty much jump into execution.

Herman: That's it.

[01:03:15] Jomiro: Super cool. Yeah, I mean that seems like a really thorough, thorough process to follow. Like I said earlier, I do like that by doing a lot of the stuff that you're doing, you're preempting ... It's almost like a pre-mortem. I don't know if you've heard that before, that idea of basically saying, "What could break this thing at some point?" And tackling all of those things early on, before you've started executing. It's that idea of ... Does the amount of time you spend on planning now warrant how much time you save by working on unexpected things later?

Herman: Exactly, and then also a focus of the planning, in my opinion, is just getting the industry standard there. Following industry standards is one of the most important things.

[01:03:53] Jomiro: And I'm interested to know if you have, just as a closing, how do you know if you're spending too much time in this planning phase? Do you have certain triggers, or how do you judge?

Herman: Sure, the proposal and discovery work kind of planning is... They don't involve developers as such, so they don't take away from actual hours spent not coding. The planning for sprints is also a part of that, and that's also very important. So we've got the formula of if you're on a two-week sprint. You have a four-hour planning session, and that's it.

[01:04:50] Jomiro: And that's your sort of baseline to judge whether you're spending too much.

Herman: Yeah.

[01:04:54] Jomiro: Okay, cool, that makes a lot of sense, and that four-hour planning is sort of from the workshop and the backlog generation.

Herman: Yeah, so that's from taking items from the backlog into the sprint and converting those items into actual ... So you're taking the user stories and adding tasks to it in order to execute.

[01:05:17] Jomiro: Super interesting, cool. Yeah, is there any sort of other major lessons you've learned about planning or something that we haven't spoken about yet?

Herman: No, I think we touched on the biggest thing, which is Agile is... There's misconception on Agile. Agile does not mean no planning. And it's just all about transparency and communication with the client. Having the client part of the team is the most valuable thing you can have.

[01:05:52] Jomiro: Yeah, and I think again, planning doesn't mean sitting in endless meetings. Even your process has definitive checkpoints and progress. It's like you need to have a proposal in order to have the sort of scope of work, which you need in order to create a backlog, which you need in order to create the sprint. So there is like a progressive thing, and it's different kind of work. It's not necessarily not getting to work. And like I said, the trade off of time spent in the beginning actually saves you a lot in the end.