 Which is which actually just got published today morning. So Jim Benson is the main publisher I don't know how many of you know Jim Benson and There are a bunch of contributors as well so It's right now out for Kindle and the print version is coming out in April So if you go to amazon.to slash beyond agile, that's the book And like I said before We also make products. So this is some screenshots of our product. So I Came across this really nice quote by David Rocco a couple of days back. So how many of you know David Rocco? He's a cook he's a chef So I don't know how many of you watch all those food shows on TV But he's got this Italian show on TV and he come to Chennai A few days back last week. He's shooting for a new show Right and someone asked him in the one of the reporters right in the press conference. They asked him You did Italian food you did Indian food and obviously both these countries have a lot of food culture in them And what do you think is the key ingredient in this food culture thing? And so he kind of came up with this quote which I thought was pretty neat So I put it in the last minute and he says that in all these countries where you have a big food culture, right? recipes are not written down and Formalized and everyone does everything the same way But instead they get passed down People make their own changes and as time goes on you have many different varieties of the same recipe the Thing which you cook might be completely different from the way your neighbor cooks it And it can be completely different from the way Someone cooks it in another city the same dish, right? So if you take sambar in Chennai it's Quite different from sambar in Bangalore and even the one which my wife makes is different from the one which the neighbor makes So there's no There are like People have developed that way of Matching the recipe to what they feel is their personal taste and what they feel suits them the best So process is something similar to that You can't just go and say this is a process right and these are the steps And this is the one and only way to do it and many times we tend to search for that one true process That tell me that these are the steps and I'm just going to follow that exactly and that's the answer to my problems Right, but then in reality, there's no such thing Instead there are many different processes. There are mix and matches of processes the whole lot of things and The real skill is not in following a process But figuring out how to adapt it to what you want or what you need, right? So with that What I'm going to describe now is not a Kanban for startups, right? There's no such thing as this is the way to do anything But rather what I'm going to discuss is some of the things factors which influence What kind of process you start out with it? So we're going to start out basically from the ground level and see what are the elements that we need to put in which Make the process work better Like so with that I just want to say something. Okay Kanban for startups What do you think of Kanban when I say Kanban? What is it that comes to your head? What do you think Kanban is? Anybody want to take a shot at it? What do you feel when someone says Kanban? What is it? Sorry visual dashboard Signaling sorry It's a methodology Anything else? Okay, a tool to manage your process so well This is kind of like a trick question because there's no right answer, right? It is all these it is signaling its visualization It is a methodology and it's all that it so but what we are going to start off with I mean I guess the the visualization is the most it's kind of becoming popular and Lean startup is built on this work of customer development Which was done by a professor in the US of many years ago and he's still doing it so the idea with customer development is We don't know what we want. We don't know what we're going to build. We don't know how The product is going to be in the final form so What we need to do is apart from product development, which is making the product you also have to do customer development which is meeting with customers Trying to figure out what they want having them use our prototypes and getting feedback That kind of stuff so it's not that someone gives you a spec and you build a product That's not the way it works, right? And the second part is systems thinking So what kind of what ideas can we use from systems thinking to build into our process the way we develop it? so The first part is that requirements are nothing but assumptions so in many places requirements are like Cast in stone right someone gives requirements we develop to the requirements So there's no discussion about whether those requirements are the right requirements or the wrong requirements or anything like that And in the case of when you're building your own product It may be like someone from the marketing side or maybe the one of the founders or whoever Might argue yourself might decide that these are the requirements This is exactly what we want and then once you decide okay Then the next step is to figure out how to build The problem with that is in their life requirements are actually just assumptions They are not some kind of You know commandments that this is the way So What you'll find is many times you build something and then find out that your requirements were wrong in the first place If you thought that this is going to be the requirement, but actually for something else So you may decide we're making a product that okay, we're gonna charge monthly subscription fees. It's going to be cloud-based Etc. Etc. But after you build your first prototype and you go and start adding to some customers You might find that some of the customers say no, we want any yearly payments and some of the customers will say And some of the customers might say that we don't Our company policy doesn't allow So these kind of things can happen and they will happen and then what you thought was the initial requirement gets completely blown out of the water So initially you might have thought we'll make a sales product charge monthly Maybe you saw some other companies following the channel model But then they thought you find out that all those requirements were like wrong And what you thought was the requirement is actually cloud-based and you have to rebuild your product for something So the biggest mistake is assuming that your requirements are perfect and then figuring out how do you build the requirements Instead you need to assume that your requirements are all Assumptions How do we verify that they're doing the right thing? It's so there was a panel earlier in the morning Where there was a discussion is a child only on building things right but not on building the right thing so it's a similar concept where The biggest challenges are we building the right thing? That's the first step and then are we building it right? So our first and most important thing is how do we validate these assumptions? How do we know that customers wanted that they're going to pay for it and That the target market we decided once it and while validating these assumptions You might find that some assumptions are true some assumptions are false some assumptions We may have to completely change and do it all over again so if you look at what we want to do is we come we have this opportunity Which we think there's an opportunity there and we need to verify all the assumptions and Then we exploit the opportunity at this point. We've got a product We've got with our software is built and it's having value for our customer But to get from here to there we have to verify all these assumptions And the total time taken from getting here to there is the total lead time of how long it's going to take for us to exploit this opportunity and this whole thing It's I can be broken down into stages. So if we have our ten features of the team features Right each of those features is basically an assumption that the customer wants it. We don't know it so each time we deploy a feature and We make customers use it and we get their feedback at that point We know whether that assumption for that feature is right or it's wrong or where we stand So till the user actually gets it uses it and gives feedback We don't anything We don't know whether we're doing the right way at all And the whole process is how can we make this cycle as fast as possible? Now how do we reduce this lead time? That's the key question The faster we can get our features into the hands of the user and get feedback back and Feedback can be either in terms of people willing to pay for it or people actually just didn't feel bad Until we can do that how fast can we do that how often can we do that? That is the key thing which determines whether we build the right thing and whether we build it right Yes, so if you look at traditional software development like what a fall You may have an idea you may have into requirement spec Respectively a huge spec And then finally it goes into the hands of the customer and then they say whether they like it or they don't like it and Let's say it takes like one year to do this whole thing So I decide on the product in January by the time we do this by build it, etc Release it to the customer And then they say I know your idea these parts of your idea are crap but then it's taken already months or years and That's too long a time or time and I think everyone agrees that This is not the way to do it But when you look at agile a lot of agile if you look at some for example It's building in two-week sprints. It's so What are we doing in those two-week sprints? We're taking some things from the backlog We're building it testing it all that stuff at the end of this print. We have a release which May may or may not be deployed Right, so but when you look at the bigger picture what actually happens is something like this Right, so if you look at my end-to-end What needs to be done? So we've got some stuff here on new features We've got development. We've got deployment. We've got to do more things You have to basically get users to use the stuff somehow and get feedback and Only when we get feedback from the users, we know whether we're going in the right direction or not And many teams do agile just for development like this right, so This part is making a backlog Then over here all we are doing is splitting the backlog into sprints and bringing small small pieces But these pieces are not going into the hands of the users in many cases Like they may be just kept internally sometimes they may be deployed once in a while and It so all this is being batched up. We are not deploying each feature We're not getting feedback on each feature as we build it. It's so we are doing this Alternatively, but then the whole thing batches up and we may end up marketing it Only when the whole product is done or maybe like halfway through the product So if you look at the lead time from the time you thought of the idea till the time when you get the feedback It's still many months even though they're doing agile in the middle They're doing two weeks sprints But it's still many months before you actually get it into the hands of the customer in the end-to-end Right, so the first thing is that how can we make the lead time of the end-to-end as Fast as possible. So we're not talking just about development We're talking from getting an idea till getting it into the hands of the user to getting feedback How can we make that as fast as possible? In other words, you want to look at the whole workflow Not just the development part of it and ensure that we optimize the whole thing Because just optimizing this part alone is not enough right, so In order to do this, for example, we may come up with a strategy like Can we have in-house users who can use it and get feedback or can we have early access Customers like we are customers to whom we can release incomplete product and get feedback It can can I select before even starting? Can I shut this from my target market say five companies or five users? Who are going to sit with every release and give feedback immediately? It's a both of the kind of strategies. We need to come across In order to shorten this whole end-to-end thing So we look at traditional of process, right? There are a lot of proxies in the middle Like suppose you bring services your start-up services for someone else Like your client may be like a business user in the client's company So that person may not be the end user that person is proxying for the end user The end user may be someone else altogether, right? So if someone is making for example the website for car owners, and they decided to also support you So they are guessing what the car owners will want And you are guessing what they will want, right? So they are your product owners They come up with some kind of backdrop based on their assumption and that is their assumption, right? Many times we treat it as if they know what they're doing actually it's just their assumption, right? And then we are taking that and making it or trying to guess what their assumption is and trying to discuss on that And so what happens is suppose I make a release to them after two weeks And they are making releases every two weeks to them but they are not releasing it to the car owners And getting their feedback back into the loop Then what happens is something like this All your releases to them are getting batched up And you are not getting the real feedback from the end user Maybe like after you finish doing all your 10 sprints or whatever They may decide, okay now we are ready for launch And they will find out that, hey, you know the car owners are saying that they don't want to pay this way or they want to do something else And then your feedback is coming too late So at every step we need to see whether we can cut the proxy in the middle If we know what their target customers can make their access to the end user, the actual user Before hand for giving feedback on this whole cycle The second thing is on queues So let's say you got a backlog Now typically what will happen is at the start of the project you make a big backlog These are all the features that I want And then we start developing on it But what happens if let's say you have a new feature which you want to put in And you have a queue like this So a backlog is a queue, there are many types of queues But backlog is one type of queue I don't mean a backlog that is waiting When you take stuff from the top of the backlog and you start executing on it That's when you are actually being productive on the feature Otherwise the feature is just sitting in the backlog and it's waiting Now let's assume I've got 10 features in the backlog And assume all of them are similar, they all take one week Exactly one week to develop So this feature takes one week to develop This second feature is waiting for one week while this one is being developed And then it takes one week to develop So it takes two weeks from the time we thought of the feature to the time when it's deployed So this tenth feature over here which is at the back of the backlog It spends nine weeks waiting while these nine features before getting developed And then one week actually getting developed So if you look at the lead time When we decided that we want to implement this feature It's one day And then when we got the feature in the product It's ten weeks later So out of the ten weeks for developing this feature Nine weeks is spent waiting in the backlog Only the actual time to make the feature is only one week But the remaining nine weeks is just waiting around in the backlog Or in other words only ten percent of the time is actual execution And the remaining ninety percent is waiting around in queues So queues can come in many places So whenever you have queues you have this kind of issue So the thing is we need to look at how can we eliminate queues as much as possible So if you look at productivity Let's say that we can reduce the execution time For one of these features from one week to half a week Then the overall lead time for this feature becomes from ten weeks to nine and a half weeks But if you can just cut the queue time So then let's say in the backlog at any point of time only two features are there Only after I finish one feature I can put another feature into the backlog Assume that we work that way, we limit the length of the backlog So if we first finish one feature then only the next feature can come in Then what happens is that the maximum queue time for the last element in the backlog is just two weeks So we condemn the lead time just by cutting short the backlog And that goes through for any queue So if you have a sequence like this There are queues, queues, queues, queues All these queues So this may be your backlog Where just before you start developing After you develop there may be some batching before it goes to deployment So you may have another queue there And then maybe you have to deploy X number of features And then only your marketing is going to start marketing So then you have another queue there And similarly your queues here Basically wherever you have handouts you have queues somewhere over there And all these queues will end up eating into your lead time So assume that each element spends Each feature spends like four weeks in a queue And one week in execution So you end up spending only five weeks making the feature But then you are going to spend twenty weeks just waiting in queue So if I decide on a new feature I am going to take twenty five weeks Before it lands on the manager or customer After the twenty five weeks only five weeks is actually working on the feature The remaining time is just waiting around all over the place So the best way to break queues is to prevent handouts So I will give an example here So in one of my previous company I was working previously We had a situation where critical components need to be co-reviewed by a senior person So once someone develops a feature Some other senior guy has to co-review it And then only go into testing Only for certain critical components Which have very complex logic and stuff So what just happened is someone would Let's say someone finished working on that And now it needs to be co-reviewed But let's say the senior guy in left team is busy doing something else Like he is working on some other feature For some reason he is not co-reviewed And he co-reviews it only after one week And the actual co-review may take only one hour The co-review may not take a long time It may take one hour And then if there are any changes to be done Then it goes back to this guy And then it has to be co-reviewed again So it may take another week again Here is the end of situation So the co-review which actually takes only one hour of work Will end up getting done only after one week Because it's waiting for that person to become free to do the co-review But after a work we changed it such that Anyone working on these critical components Pairs with the senior developer So they sit together and work on it concurrently And if one of these features takes like a day to finish And they are both sitting together And there is no co-review needed It can go into testing immediately So previously one used to take one week before it can go into testing Or if there are some changes to be done It may take two weeks before it goes to testing Now after one day it immediately goes to testing Because all the queue time where it's just waiting Waiting for a co-review that queue is eliminated So pairing is one way of terminating queues Basically how can we get rid of handouts Similarly pairing with testers Or devops is basically getting operations and developers together So that you can make faster deployments I'm going to talk about pairing The co-review time is also important So if there is a re-co-review for a co-review Even pairing may not happen at the same time But how many times do you want to re-co-review Or if you're co-reviewed at a new step And depend on the pair of the co-review So when you are, you don't pair There's no need to do a co-review Because the senior guy is sitting there And co-review together So it's already reviewed So pairing is like a review at that time itself So there's no need to do a separate review It's like a continuous review happening During the development of that future And so when you do that You don't need to do a co-review Is there a, this pair is actually Coaching you would call as a pair programming Because the senior guy is only going to Review the co-review with the other person Is writing They work it together But the idea is So you can do many things Pairing is just one solution I'm not saying it's the other solution There are many other things you can do The main thing is breaking the queue Because if you didn't do pairing And let's say you have co-reviews And let's say a company says Every Monday they have co-reviews And some guy finishes the future of Tuesday It has to wait till next Monday Before it gets reviewed So for one week That thing is sitting in a queue That thing is happening to their future So same way if I finish developing And it's waiting for testing And for some reason it takes You know Three weeks before the test For those three weeks It's just sitting in the queue And so it's the same concept throughout All these things So will it not be the same case Even in testing Because once even say pairing happens And goes for the test queue And starts working on something else Then if there is something which is Going to cause rework Then maybe is he going to put this Existing task on board Exactly right So from development to testing If there's a handoff You have the same problem So you're creating a queue over there So let's say I developed something And it's not being tested And the tester will batch up 4, 5 teachers and test it Then there's a queue being created Over there I'm not saying handoffs Even if the tester immediately answers The code review When it is available in the source code system For testing Are you suggesting that the tester And the developer work together And complete the testing So that it doesn't have any queue So that is one solution If the tester and developer work together It breaks the queue Now whether that is a good idea Generally it's a good idea But in some cases It may not be possible In a startup Generally there's no excuse for not doing it Because a lot of these things Have to do with the Culture And the departments And a lot of things which are entrenched In big companies But in startups we have the opportunity To break all that For a startup team Which is maybe 10 people But startups working in one office Or two offices You don't have like 100 people In many locations with their own departments And they have issues breaking the culture So in a startup It's generally very easy For a tester and developer to pair There's no cultural issues There's no guidance on that So if it's possible You should do it Because it breaks the queue If the developer and tester If you can get I mentioned earlier about Getting customers in If you can get customers in Before release It's better It breaks the queue time To the customer senior And all these queues end up creating Work in progress More queues, more work If you have a backlog with 10 items It's a whip of 10 Even though you may be working on some Whip from here to there So we're not just taking whip From startup to finish But whip from the time You thought of the idea Till the time between your customers The concept, the cash So To sum up that part The main thing is How fast you can validate assumptions Which means from the time I have an idea To the time it gets into A user's hand Shorten the lead time The code idea which you're working on And to decrease the lead time You need to optimize across the value scheme Which means it's not enough Only if development is agile But then all the releases Which you're making Are not going into the hands of the end customer And you're not getting lead back Then it doesn't make much of a difference As far as the end current lead time is concerned So it's better to focus On making the whole value scheme A little better Make a super optimized agile team And ignore the rest of the value scheme And to decrease lead time Queue time is very important The actual productivity In doing the work Is actually usually just a fraction Of how much time that item Is just idling in queues So if you can illuminate queues You can factor lead time Even with the same productivity Without changing the way That it's actually developed And the less work in progress you have The less lead time you have So if you have a smaller backlog That's what I'm talking about The other approach is in many times Even in mission critical systems It's actually possible to do it Like for example many trading systems Have multiple deployments a day Even though mission critical Is high volume finance So it can be done But it's just a matter of There are companies who do it So it's not impossible It's more of a psychological thing Than a technical thing So when we look at building the features So we are going to build features One by one And get it into deployment There are two concepts Which we are going to look at Minimum viable product Minimum marketable feature So minimum viable product Is the minimum thing It may not be the whole product It may not be the final product So what it says is Just build the smallest amount So that you can start releasing it And getting the feedback So two words minimum and viable Minimum means it has to be as small As possible And viable means it should be viable It cannot be just one feature Which nobody can use So for example if I'm building An email system Let's say I'm building Gmail And receive mail There are so many other features Like HTML, mails, attachments Filters, labels, blah blah blah Those are not minimum An email system is viable If I can send mail and receive mail But if I do only send mail It's not so viable If I can't receive mail And if I can do only receive mail It's not so viable if I can't send mail So the idea is to implement That minimum viable So if I'm making an email system So my first two features Which I'm going to implement Are going to be Sending mail and receiving mail At that point I will start sending it out to my customers To start testing that functionality And getting their feedback While I build other things Like maybe the next thing I'll build Is a login In the first release I may not even have a login I might have my beta customers I will tell them That this is going to be a way For a new user to register In the very first version Because I know those guys I will create the accounts manually For them and tell them to register And use the system And give me feedback Because that's the core thing Which I want to test Then I might implement A few things like attachments Blah blah blah And before going for a public launch I might implement a registration feature To register But if I have beta customers They may not need a way to register The second thing is Minimum marketable feature So this again is a feature Which is slightly higher than A user story concept So in the user story concept It's very fine grained So for example Let's say I want a feature which will mark Mails as important Google has this feature Three steps to this feature One user story may be On my email list Another one may be That the user has a way To turn this feature on and off And another user story may be That what algorithm I'm going to use for calculating this So I need all three user stories To do this feature I cannot just go to the customer And say I finished one user story You can turn it on and off And both are not implemented Algorithm for this thing It's useless What is the user going to turn on and off And the actual algorithm is not there And same way There's no use going to the feature Customer saying We have implemented the algorithm But we have not yet deployed the story Which shows on your email list Which is important or not That's also useless So there are user stories But by itself All three user stories are there And then I can say Okay we implemented a feature For automatically classifying important emails And then the user can test their new feature So this combination of three user stories Is what we call as a minimum marketable feature So generally we are looking at Generally when we get an idea For a feature It's usually a minimum marketable feature Which may have many user stories I'm not sure But you mentioned about minimum marketable product And minimum marketable product Because even if it is a minimum marketable product It needs to have those functionalities So a minimum marketable feature Is one single feature A minimum marketable product Is a combination of Minimum marketable features For the initial release So initial sending email Can be an MMM Receiving email can be an MMM Both of them Have many different user stories And the combination of both is a MVP So first we build the MVP And on top of that we build the MMMs So you get something like this This may be the MVP Which is consisting of certain core MMMs And on top of that we add MMMs On top of it So your product is basically starting with the MVP And then building more and more MMMs on top of it And it's not just building more MMMs It may be also changing existing ones Like the user may say this feature is useless They may remove it Or they may say that I want this thing changed They may change it And so the reason why we like to have a short backlog Many times it's cyclical Just because the user may say it's crap And then you may have to come back to the beginning And do something else So when you have a short backlog You can focus on getting these features right Without worrying about having a big backlog Over there So not by itself Not by getting to work upon Q But then this backlog is also piling up So we are really not aware that Q is there The product backlog or the roadmap It is piling up So the thing with the roadmap Is when there is so much uncertainty On the initial features itself The roadmap It's impossible to say where we are going to be Six months down the line When we don't even know whether our first two features Are right or not So if we are building an email client We know that so many features are there But we don't create a backlog of all the features We just say our backlog has two features Two every month One is sending email or receiving email First we will make those proper So we tell about those Or get it into the hands of the user Get the validation Once that is validated Then we will say ok what's the next thing we can do Even in a time of strong modeling Rather than in the end Even there this is possible And I can do this validation First stop two items And then the sequence Yeah sure What is the plastic difference Of handling? Yeah so the main difference So this is just It's a concept right So like I said right at the beginning We are dealing more with concepts So the concept is Have a short backlog And focus on the lead type So that's a concept which comes from And then the other concept is Optimize across the entire thing About development alone So it has to go into the hands of the user And they have to do feedback And give it back So yeah sure you can Do scrum and make sure it lands In the hands of the user That's totally fine But the concept of optimizing The whole value stream Is one which comes from Kanban It's a system thinking approach Whereas Kanban is more development You would say rather in Kanban This is more explicit It is more explicit So like I said There are many different ways Of getting the same recipe Of doing the same recipe The idea is we want to minimize The lead type And that kind of focus Is more of a Kanban focus But it doesn't matter Whether you call it Kanban Or scrum is not the point So yeah you can do it in scrum So if you start from So if you look at it So ideally we want to get our flow like this Right Let's say you are working on four items at a time We just have an idea We deploy it We test it And it's validated At the same time We are doing the same thing for four others So we are working with four With four four Only after this thing is finished And validated To work on it So the idea is to go from Idea to validation MMS by MMS To work And this can happen in fabulous way So in scrum you are starting And ending time boxes Whenever this finishes We just pick up the next one And the same thing here So that's what we are We are kind of Come to fix With number here We are going to fix together MMS of marketable and PNG So this is just an illustration It's not that it has to be four Or two or ten It's the lower the better At the same time You may want to do two, three things In parallel if you know that You can do two, three things in parallel You may not want to put your whole team With just one So you might do two, three The idea is not You shouldn't be programming many features Without getting any kind of feedback That's fast I was wondering You mentioned about Switching on, switching off the algorithm So all of them together Really makes a food store So I thought A way of looking at your How many will go together For a validation So each of these is one MMS Is how MMS is a combination of stories In the case of that Algorithm example Three stories make up that MMS So stories are generally very fine-grained Not necessary that They are good facilities MMS is really more high level So we want to be flowing those MMS to At the development point of view That MMS may become three stories Get developed So what we want to do Is something like this As much as possible So let's talk about four topics So first is prioritization So a lot of teams have this idea We'll make a full backlog Prioritize it And then figure out Which is the top element Implemented So a better way That I feel is a better way Is using selection In other words Is the backlog Just know what is the next thing Which you are going to work on Apart from that Everything else is irrelevant So how do you select the next thing So it could be There are many factors to check on One is Is it a differentiating feature Maybe you are building a product One feature may differentiate Your product from your competitor In which case that feature becomes very important So you may want to do that in the early on To validate it and test it properly Because if that thing doesn't work Or you may need to do many iterations Usually that feature is something very innovative Where you have to do a lot of iterations So second thing is risk Risk is in terms of Will customers want it There is a question mark Certain features you know that they want it Some features Or some MMS I don't know So there may be a risk of Will people want it So you may want to do that higher up So that you can test it early on And same way This technical risk Which is Do we have the technical knowledge To do this feature So in case of algorithms Do we have the technical knowledge To actually write an algorithm Like this Which will analyze and categorize The capabilities The other thing is So there are many models How do you select features There is something called as KNO model There is this Risk based model And there is differentiators And stuff like that But is it not prioritization Because you have one of the factors To prioritize it One such is risk So what we do is Instead of prioritizing This side It's assuming that we have All these features in a bold It's not prioritized We just look at the bold And say this is the one Which we are going to do next So that is selection Is this selection done by the team Or I think it is a product team It has to be done by someone So I am not going to get into Who is the product Or who is the team So So So we are talking about the concept level You may have a separate product owner Or it may be a person in the team Or it could be anyone But whoever understands the product You can call that person A product owner if you want So Let's call that guy as a product owner That guy who understands the product Understands the market So the reason I am being careful Is in many cases the product owner Is just a proxy Or the product owner Themselves don't understand The product or the market In many real life implementations So I am going to call that guy Who knows where the product is going As a product owner That person may serve And may not be one person It may be a group of people Or whatever So someone decides Okay this is the next most important So we finish the mail We finish the receive mail Next let's make a login Next let's Then we finish the login Okay next let's make this algorithm So in so prioritizing the whole thing We just pick out the next So if I understand correctly What you are saying is Instead of having a list of 10 You only have one at a time to go Yeah So that's what you have to mean by Selection Like I am typing your word But for this you are only saying Okay until and unless This MMF is complete You don't have any priority For everything else Exactly And it may be one, two, three Whatever But that's the idea So the idea is because Once you finish this MMF Based on the feedback Your What you think is important And the remaining may change So there is no point Prioritizing it Doing an MMF Then re-prioritizing it Doing an MMF Re-prioritizing it Instead we just pick out Which whichever we want to do next Okay When it comes to the Development part of it Things will change Things are going to change Dramatically Especially for start-ups Where the requirements are Highly volatile Whatever you talk Was your initial requirement At least 25-30% will be thrown out And changed It's not just minor tweaks You may completely change Your subscription model for example You may completely decide That some features are used That some features you want to do more And so You have to plan for that change So having a good Design is important Having a changeable design is important Because a lot of parts of it Are going to change a lot And at the same time Having some unit tests and stuff Is becoming important Because when there is so much change happening It has some amount of Check for the changes Which you are making Otherwise testing it becomes Really difficult Especially with a start-up Where you have a few people And if you want to minimize Your lead time You can't really afford to do One-week manual testing And stuff Testing generally shouldn't take More than a day or two For a moment Otherwise it's just too long As a lead time The third one is Testing So I just mentioned about testing Now there are three parts to it Validation, stability And lead time So right at the beginning When you are trying to validate something And this is purely my personal Power thing So it's slightly controversial But I don't write tests right at the beginning Because I don't even know Whether I'm going to keep this It's more like a hack or a prototype Just for testing Just for validation So if I want to Test a subscription model This will users pay monthly By credit card I may build that without Having unit tests I mean you will do manual tests Of course But without unit tests Because after my test I might find out That they would want this subscription model At all In which case I might just throw the whole code again And create a new one So it's not really You should be clear That this code I'm writing For testing a specific assumption And for that code As fast as I can test it The better I don't want to prove That that code is super stable That it doesn't have bugs All those things That comes later So after you cross that path There's a part about stability Where you know that This is something people want At that time I go and write lots of tests Automated tests Because later on There won't be more changes In this path Because of future stuff And that So that unit test Basically gives some amount of Feedback like Where I'm making changes I'm not breaking things And finally You come to lead time Which is how fast can I deploy And the more unit tests And the more automated tests Like even as a system of functional level The faster you can deploy Because you need to do less Manual testing So in an ideal case After a point Once a particular feature Area becomes more stable You wrap up the amount Of automated tests like a lot So that you don't have to spend more time Testing that again and again For every release Which means you can Make your releases faster And your lead time Becomes shorter overall Will it not increase the field time Because you're going to Activate all your unit tests Or automation speech frameworks In that time You are sure that This is what your customers want So till those frameworks Are available And you're sure It is working fine You're not going to So the thing is In the beginning Right So We need to have an idea Of what is a production system When you're starting with a new product I'm talking mostly From a startup point of view The initial part You'll be working with beta customers Who will know that It's not yet live So they will know That it's incomplete It may have bugs It may not work exactly And they are supposed to give Feedback on whether it works Well or not So at that point of time Stability is not the issue But validation is the bigger issue Once you go live So these guys are beta customers With whom you have an understanding already So you may be my beta customer I'll tell you This thing doesn't work But just check it out And tell me what you think Right So if it crashes You'll just tell me It crashes It's no big deal So that's the kind of thing But then you'll say It crashed but I really like the idea So that validates That may be What I'm looking for Then we go into the stability part Is Now let's say I open it out To some more people And they are going to get really mad If it crashes You may not get mad Because you're moving Or we have some arrangement So at that point of time Stability becomes important And I've already validated it With you So I know that they wanted For them validation is not Another point Stability becomes important So at that point I need to have a lot of tests And then when we go to lead time It's like Okay I've opened it To the public All that stuff How do I reduce the lead time Without crashing the system At this point Bugs become a big problem But at this point Bugs are less problem And validation is the bigger problem Okay and this is the final point Which is variable process And variable process means You do not have to Implement every feature Using the same process For example Some feature Like a login form Is a commodity Everyone knows What is a login form It's the same word thing You don't need A whole lot of validation On a login form You don't need A whole lot of feedback On a login form So a login form Is something You can just code And deploy Without having to Do a whole lot of feedback But if it's a differentiator For that feature I may do a different process I may get a usability guide To look at that feature But I may not get a usability guide To look at the login form I may get a early customer To use that But I may not get a early customer To test my login form Right So I may just follow Completely different process While working on A different shape of feature Whereas when working On a commodity feature There's no reason That we have to follow The exact same steps For all the features For different features We can actually do And develop it In a different way Right So That's basically A variable process And Kanban has been Called a class of service Which is basically I think Deploy Implementing Different features In different ways Right So if I have For example A production bug And my system is crashing Then I may Explanate the whole thing I might tell All the developers To like Stop what they're working Fix this Because it's Highly critical Whereas For another feature Which is just Another feature addition I may not tell them You stop what you're working And work on this Because it's not So critical As fixing the production So different Things which you have to do You can actually Use different processes For all of them There's no rule Which says You have to do The same thing For any process So that's So finally We come to the Kanban board Which is basically On everything That we discussed Right now So if you have Kanban board Which goes End to end From the beginning Still done And you can Put work in Process limits To limit How much work Has been done And each of these Yellow cards Is an MMM And There's no reason That every card Has to step Through everything Some ways Can call them Some may go Depending on What kind of Work it is Like Production issues Or Differentiate of features Commodity features So that just By looking at colors We know what is Being produced And if we can Make our Process such that We can get through This line As fast as possible By cutting cues Wherever we can So for example Ready for death Is a cube That's basically A background This may be a cube So Where all Can we cut these Cubes Then we get Fast lead type Kind of So Then we can Make Anymore questions You get that Yeah Okay So the systems Thinking part is Basically Things like Looking at The whole value The whole process And not Just one part of Just optimizing One part of it Doesn't impact The whole Thing You may get Just The whole Thing You may get Just look at the whole That's one The other thing In systems Is this notion of cues So many times When you have A full system With new cues In between The concept of Cutting out the cues And To reduce And lead them Across the entire system Those are the ideas Which you Want to get through It's also More of A real thinking Just in time Yeah So that's Right So the selection is Best clear But How do you use the main In the working Process Specialization When you're having My people Are Can be The main Yeah So you use A board link But how do you Make decision And it's curious to know I select In the For another man So You mean How do I Choose the limit So That is as low As you want You Usually if you are Like Or maybe like Three developers Or four developers You may set this Little less than that Maybe Two or three Or sometimes You may set it to One or two more Than a number of developers It's basically Experimentation There's no Scientific rule To get this Or Ideally You want to go To single piece flow Which is Getting one item Through The whole process Yeah It has to match Here Very What are some of the techniques Right In the context of So let's assume That translation is done By a third party Okay Who is outside the start Right So you Create the strings You give it to them They have to Translate and Use that So What I will do Is Create a column The Thing is As more and more strings Pile up In their batch We put a limit on it So we say Only like Or Say ten strings After that We have to get The translation Of the ten strings Right I'm just giving An example Maybe fifty Or whatever So What happens is Let's say You hit that limit Then Now you may have One or two guys Free Because they are not So what happens is Once this limit is hit Once the development Gets Complete Right This is full It kind of starts Piling back Right Because Something is gone So when it files back So let's say These two cars are Back And the developers are free And they can't take Any more cars Because it's already At limit So you might Tell them To follow up With the translation guys To Sometimes What happens is They may need Some follow up They may need Some work To follow up They may give you All the strings The next day For example So You can use them To unblock The cube That's one option The other option Is If you are someone In your team Who knows Some parts of it You don't Want them To be doing Translation But then Once they get Block Because Of Translation Let's say The guy who is German He can do All the German Translation Right now So those kinds of Things are possible Where If you are Machine skill guys You may not They may not be Very good With the secondary skill But they may be Good enough At a time When they are Blocked to Do that So the advantage Of doing this Is Instead of Then doing More and more Development Is And Then The And In In Co-operative Yeah Yeah Maybe I Why do I Not Something Is Working With So I Do Not Pilot So Yeah So if you Just You may be more with right and for example if you are just piling up and you are not finishing anything what is happening is actually that let's just go back to translation right let's say everything is piling up in translation for that reason you are not able to deploy it you are not able to get feedback in the meantime you are working on many other features without getting feedback so these few features and it may turn out that feedback when it comes will say all those features you are working on it need to be changed so all that you thought you are doing productive work but actually right now this is what I am actually doing yeah so the ideas you can utilize free cycles in other places the ideas of piling up with can be problematic when change happens then you have to drop all that stuff it becomes a big risk but usually in most cases in some cases completely out of your control right in which case you just not put a whip on that so let's say translations add zero control I can't do anything okay just make it unlimited which I mean you don't have a choice right it's not your first choice it's not an ideal situation but you don't have a choice then you have to do that but you have to keep in mind that it's not a great thing but I have to do it kind of thing is it also okay to channel some of those free cycles to some of the backlog items some automation yeah you can that's totally okay and in some cases you may have free cycles somewhere which allows for example let's say that you have a feature you want to develop you have two completing designs you don't know which one is going to be better you may use free cycles to develop both and as half your users that's possible that doesn't get in as an action it will not be a formality right okay thanks a lot thank you