Episode Description

In this episode Thanasis and Dimitri talk about software development methodologies.

Episode Notes


Thanasis [00.00.10]: Are you an entrepreneur, a designer, a developer, never before has it been easier to get your new venture off the ground. Whether you’re just getting started or have already begun your journey, you’ve come to the right place. In each episode we will dive into a new challenge breaking it down into simple, digestible items. I’m Thanasis…

Dimitri [00.00.22]: …And I’m Dimitri.

Thanasis [00.00.26]: And you’re listening to Listen-Ship-Repeat, this is episode No.6. We will talk about “Four +1 development methodologies to choose from”


Dimitri [00.00.45]: How are you tonight Thanasis?

Thanasis [00.00.47]: I’m pretty good!

Dimitri [00.00.49]: What have you been up to? Something very interesting, I assume?

Thanasis [00.00.53]: Well not very, but I find it interesting, I managed to do some docker deployments on production and that really felt good. For our listeners, docker is a methodology to package your application into a container and ship it on the cloud. I mean, I had some doubts about production usage, as to using it live. However everything went smoothly and I;m very happy with the outcome.

Dimitri [00.01.26]: Very nice, I’m so glad to hear that! I’ve been traveling for work the past few days, went and caught up with my team, will do that know and again even though I work remotely. I catch up with them and that gives an opportunity to lay out some mini road map stuff about what we’re doing down the line, so this is really productive for me and I always enjoy the traveling experience.

Thanasis [00.01.54]: How many days?

Dimitri [00.01.54]: Just from the beginning of the weekend, I got back tonight, Thursday so a couple of days. Tonight we’ll give a comprehensive approach to our project management episode we’re talking about some practical steps for using a development methodology. So, as we talked about, project management is the application of processes, methods and knowledge skills in order to achieve your product and project objectives and there are certain ways to achieve that and this is where methodology comes in. Consider the methodology to be a collection of tools, best practices, a set of principles in order to find the best and more optimal way to achieve a set of goals. So your project management is your day to day task and your project methodology is finding the best way to achieve those set of tasks.

Thanasis [00.03.00]: So, what methodologies are there Dimitri?

Dimitri [00.03.03]: There are plenty and we’ve chosen a few of them for tonight, four plus 1 to be more specific. Probably we’re going to focus on what we’ve worked on in our own experience and have a look at certain ways, maybe some honorable mentions and also look at ways on how to combine these things. How about you begin, Thanasi?

Thanasis [00.03.33]: So, let’s start with the most classic methodology, “The Waterfall” and what the waterfall methodology is, it’s a very straight forward way of describing what you want and what the outcome needs to be. Consider that you are describing your product start to end with every little bit of detail, you put it down in a very large specification document, book size like 300 pages long, you give it to a developer or team of developers and you go on and build your application according to this paper. So, the idea of waterfall is what was used by default in software development and what is used up to today in embedded system developments, for instance IoT devices or anything that has to do with hardware. It has that benefit of allowing you to specify what you need start to end, but on the other end this also comes as a disadvantage when it is applied on the web industry where everything is moving so fast.

Dimitri [00.05.12]: Would it be safe to say that if you’re not experienced or if you’re not aware that these things exist then you’re doing waterfall without knowing it.

Thanasis [00.05.24]: Not quite, because waterfall requires a discipline of understanding on how to write a spec and what the meaning of a beginning is and what the meaning of an end is so you’re not basically doing anything, it doesn’t mean that you’re doing waterfall, you’re just going where the wind takes you.

Dimitri [00.05.51]: Fair enough, I was looking at it in terms of perhaps, I’m doing sequential tasks and each next task depends on the completion of the previous one and obviously if I don’t know what I’m doing, I don’t write detailed spec, that’s the way I meant it.

Thanasis [00.06.13]: So, what else is there Dimitri?

Dimitri [00.06.16]: Coming up next, “Scrum”. My personal favorite! I’ve had the opportunity to work with people early on and gain some in depth knowledge on it, even the great opportunity to join organisations at points of my own career and introduce it to organisations that adopted it, or not. However, more often than not they have adopted it. It’s an agile way to build products, it works excellently in the web world, the application world, the fast paced iterative building and constantly changing and improving your products and it’s a flexible way of building products too.

Thanasis [00.07.12]: So Dimitri, why are you calling Scrum and not agile?

Dimitri [00.07.16]: Because I’ll be going into scrum in particular. There’s a blog post that I wrote, it’s a Medium post, had moderate success and also had a few recommendations and it’s called “The practical Scrum overview”. While I was writing that my aim was to take my experience and kind of put it in a semi long post where at least somebody could take that and begin applying it straight away. So, it’s a very structured way of doing stuff and I acknowledge that it’s not for everybody in terms of the structure, but we’ll be looking at some derivatives of it after we’re done. So, what you’re doing is, you’re putting together a decentralised team of developers, a collection of individuals basically together, in order to deliver requested and committed to the product increments. So, these are small teams and if you’re a non tech founder and you just got your first developer and you’re getting started and you’re team is less that 5-7 people it’s great. This team is also responsible for translating product vision or backlog items into tasks, which we call sprint tasks. The way that you’d put this together is, you’d have your team, these are the people building stuff - developers , designers etc. - there’s also a product owner and they’re responsible for the product as a whole. So, if you’re putting together your startup and you’re a non tech founder as we’d like to refer to - you’ve probably noticed - it’ll be nice for you to get experience here. This will be nice for you in order to have a bird’s eye view of what you’re building in your startup operation. However, you’d like to have an in depth vision of your product, so if you’re putting together your startup then that’s a good starting point for you and requires you to be familiar with the industry trends and what the competition is doing and your product vision. So, practically what your role is, creating tasks in the form of using stories, assigning priorities to them and passing them onto your team. After that there’s a scrum master and the scrum master could be part of the team and I’d like to say that they’re job is to make sure the trains run on time and the development team isn’t distracted. By definition scrum teams are self managing and the scrum master works in accordance to that, but they’re also responsible for removing blocking issues that most likely will arise within your team’s collaboration. So, we’ve seen so far the product owner, the scrum master and the team, these are the three main roles you have. I mentioned user stories and tasks and these could be applied on plenty of methodologies. So, stories that could be multiple types of work, consider something that could be broken up into smaller parts and usually that would be something like, as a user I want to be able to log into the website, as a user I want some action or some achievement in order to whatever reason. So if you want to log into your website there are tons of work in that and you have to break that up into smaller tasks, design, views, logging mechanisms, backend etc.

Thanasis [00.11.22]: And that’s the estimation stage, right?

Dimitri [00.11.30]: Okay, but before we get to that, estimation obviously Thanasi, as you know plays a paramount role in scrum and it’s a very good selling point if you want to bring it to an organisation.

Thanasis [00.11.46]: I think that the reason why scrum was firstly introduced, was in order to smoothen out the relationship between products and engineering.

Dimitri [00.11.55]: So, firstly we talked about tasks and many user stories can form this epic huge tasks, it could be milestones of your product. So if you put all these together, you put them in a product backlog and at the beginning of a time period called sprint, which is two weeks you find which task you take from your product backlog to your sprint backlog and you estimate those with your team and ideally at the end of your sprint you will have to be able to say whether you have delivered on these items and you have implemented them. In order to do that at the very beginning of the sprint, the whole team gets together, the scrummaster, the product owner, the scrum team, they look at what they want to achieve, they break that up into tasks and they estimate those tasks.

Thanasis [00.12.50]: So Dimitri, are you doing are you doing single or two week sprints?

Dimitri [00.12.58]: At the moment, I’m doing two week sprints.

Thanasis [00.13.00]: Okay, just asking because everywhere I’ve worked it’s single.

Dimitri [00.13.04]: Okay, that’s interesting. I find it for example, let’s say you have a task to implement, you have to build it you have to test it, it’s probably going to go into some QA phase and there might be some back and forth there, so depending on the amount of work you want to undertake you chose accordingly. If you have a QA phase for example, I find that one week is pushing it, two weeks allows you to get a bird’s eye view of what you want to do, you can take a bigger chunk of work

Thanasis [00.13.37]: Is your whole team on a two week sprint?

Dimitri [00.13.40]: Yes, it’s an eight-people team at the moment, including product managers designers etc., what we refer to as the product team and two weeks allows us to give it the work it needs, you know as I said QA phase is very important for us, we prefer having it as a week. Probably it wouldn’t allow us to deliver the quality we wanted to if it was any other way.

Thanasis [00.14.07]: Yeah, I guess it’s a matter of team culture. I mean either ways is not that you don’t do QAs on week sprints, you can put it on another sprint.

Dimitri [00.14.26]: But one week’s it fine. If you have your sprint planning, maybe doing some sort of review meetings towards the end, maybe some sort of retrospective and daily stand ups and that’s actually time there…

Thanasis [00.14.39]: If you do that I agree that it needs some economy of scale to do that every two weeks.

Dimitri [00.14.45]: And maybe in the end it really depends on what you’re doing. Do you have an example of what you could be doing in one week?

Thanasis [00.14.55]: Yeah, I mean the deliverables don’t have to be deliverables that the product can conceive. You mentioned log in, log in can break up in so many different pieces and until the final piece falls in place that combines everything together, there won’t be anything visible out there, right? So, as you break it out into small tasks you prioritize into weekly sprints, you get done, this of course goes through the scrum master, who is part of the team, is an engineer and understands what’s going on and can appreciate and understand the small components you have delivered and the final delivery can span through multiple sprints, two or three or maybe more.

Dimitri [00.15.47]: Yes, definitely. It’s a never ending process. So, I think we’ve pretty much covered the basic stuff which is the roles and the sprints. However, I really invite you to have a look at the blog post and if you’d like, we have a facebook group, I’ll be very happy to answer anything that might come up and that’s pretty much it for scrum.

Thanasis [00.16.15]: So, again why scrum and not Agile?

Dimitri [00.16.20]: It’s really a matter of choice isn’t it? It’s not one or the other, I really just prefer this way because it really comes down to what type of person you are and your experiences that you’ve had using it to this point in your life and I just love Scrum pretty much.

Thanasis [00.16.45]: So, it’s not because the Agile term has been overhyped or overused?

Dimitri [00.16.51]: I wouldn’t say that. Even though you are right in terms of that’s been overused, but that’s conversation for another time, but “TL DR” is not a question of one or the other. My own experience brought me to this point and I really enjoy doing it.

Thanasis [00.17.16]: Alright, so let’s move on.

Dimitri [00.17.18]: Yeah, what else do we have?

Thanasis [00.17.20]: We have the “plus one”.

Dimitri [00.17.22]: Yeah, I really just wanted to say something about the “critical path method”. So, it’s a project modeling technique, really old, like 40’s or 50’s and you can use it in all types of projects and we could add some literature to the show notes regarding that. What that is, it’s a compiled list of tasks or activities that to need to be complete, definitely a sign of duration of each one make your dependencies quite clear between these items and calculate the path between those items from beginning to end that would take to the deliverable milestone, which will give you the shortest path possible.

Thanasis [00.18.18]: Who would use that today?

Dimitri [00.18.22]: They used a lot in the 50’s and I’m sure they went to the moon with this kind of stuff. I can’t really say who would use that today but scrum for example, it’s nuts, everybody is using it, big or small companies.

Thanasis [00.18.35]: I found that scrum is used, like the bigger the company the rigorous methodologies are enforced because of, like you said, all those little details and technicalities that you need to go through. So, scrum or agile shows its benefits in each scale. Would you agree with that?

Dimitri [00.19.07]: Absolute! If you had the smallest team possible, like one or two people, what would you recommend?

Thanasis [00.19.14]: We’ll get to that, I guess it’s our final methodology, we still have one more before the final one and that would be “KanBan”. KanBan is a methodology developed by Toyota I think, correct me if I’m wrong.

Dimitri [00.19.32]: Yeah, it’s a Japanese word.

Thanasis [00.19.36]: So, the idea is that you have lists, you basically have the lists of the things that you need to do. You have the list of the things that you’re actually doing today and you have the list of the things that have been done. That’s the minimum setup you can have in terms of KanBan, of course this may vary. The idea here, again you break out all the goals, whatever you want to accomplish into simple tasks and you assign them to people and you prioritise them. The best representation of Kanban today is Trello, which we’ve talked about it many times in the past.

Dimitri [00.20.40]: We use it too!

Thanasis [00.20.42]: Yeah, we use it in our day to day activities. So, in terms of lists what I’ve found to be the most convenient for me, in terms of what I do operationally is to have a list named “Backlog”, which holds all the items that have been specified. I also have a list of what is coming up next, which is your sprint.

Dimitri [00.21.17]: So pretty much, you have a product backlog and a sprint backlog, right?

Thanasis [00.21.22]: Yeah!

Dimitri [00.21.24]: Okay but, you don’t call it that, I just wanted to make it clear.

Thanasis [00.21.27]: Exactly, the differentiation comes on the next step where you have the “Doing” and the QA list, before you have the actual “Done” list. So, it’s a very distinct separate step of the tasks that are in the QA process.

Dimitri [00.21.44]: I like to use, in addition to what you said, quite similar, even before backlog where I just dump ideas in there.

Thanasis [00.21.56]: Yes, from then on you are free to create any type of list and the reason I didn’t mention that is because naming is a problem. Depending your particular case you might want to name them differently, so one is “Ideas for X” or “Ideas for Y” and if ideas are getting out of hand, then it would be a really good idea to get them to another board.

Dimitri [00.22.28]: True! It’s nice that you mentioned Trello and I’ve had this internal conversation, many times about having multiple boards and I’ve really come to the realisation that I can live with having only one board and just having this idea column at the very start which is huge because everything goes in there and maybe two or three weeks or so, I might come in there push stuff to the prior Backlog column. However, having multiple boards also with Trello, I can understand that.

Thanasis [00.23.12]: Definitely, I mean you need ideas columns, at least one. I wouldn’t put them in front, however. At the front I want to see what’s operational, what’s in front of me at the moment.

Dimitri [00.23.24]: Yes, can I ask you something? All this stuff relates to the product, what about for example unforeseen issues, like bugs, how to throw those in? Do you have a bug board, a bug column?

Thanasis [00.23.42]: The way we did it on a consumer application where a lot of bugs came out through a very rough period, was to have a bugs inbox, where anybody could create a card there and that’s important, because they could create a card there and only there, so those items in that list got verified, if they wouldn’t get verified they were sent back to the one reported it requiring a better use case. If they could be verified they were directly depending on the emergency, they were either put back on the backlog or to the next sprint or directly even to the current sprint depending on the priority. So between the backlog and the current sprint it’s also convenient to have a list which is the next sprint. You start to build your next sprint early on with items and by the moment the sprint finishes it’s pretty much closed and you’re on to the stuff on the next sprint.

Dimitri [00.24.55]: Well if I may, in spirit, which has to do with what you’re saying, in scrum it’s the backlog refinement meeting, also. So as you can see there are a lot of meetings that’s why I would do it every two weeks, because otherwise we wouldn’t get anything done. You might even put it to three weeks.

Thanasis [00.25.19]: You can do anything that fits your purpose.

Dimitri [00.25.24]: Exactly! It’s very important to narrow that down. There are rules and stuff…

Thanasis [00.25.31]: There’s reality as well.

Dimitri [00.25.34]: Exactly. It just steamrolls through your rules. I enjoy Kanban to be honest and I was in the process of writing about it a while back and I kind of stopped, but I will get back to it, because honestly between all the stuff we’re discussing here tonight, it looks like the best approach let’s say.

Thanasis [00.26.06] Yeah, Kanban is definitely the weapon of choice as a primary methodology, because the last one, that we are about to mention now, which is pretty obvious it is the “Mix and Match”, is what we are essentially doing.

Dimitri [00.26.28]: Well for Mix and Match, I think that all these systems and principles, kind of gravitate towards that at some point. So, maybe at some point you might be doing scrum, but I’ll find it absolutely reasonable if somebody would come to me and say, look I do my daily stand ups but I don’t do all these meetings, I don’t do retrospectives, I don’t do reviews, I do stand ups, which is catching up with the team everyday - I’ve cherry picked that from scrum and I’ve left all the other stuff aside - because I’ve decided that it’s better for my product that I’m building.

Thanasis [00.27.22]: Right, you Mix and Match.

Dimitri [00.27.23]: I do, but then as we’ve been discussing about that a while back, I’m for the way of thinking that if I am going to mix and match I’d like to be able to understand what I’m doing. As soon as I understand, at least to a point that I feel that I’ve accomplished something, therefore understand it and have experience in it, then I can mix and match better. You know, the people come up with these stuff, I assume that we get to read about it everywhere and we get to go to these organisations and companies that work with it, but the people that have developed these methods, I think that it incorporates years and years of experience and experimentation in order to be able to come up with all these stuff. So, as a private individual that’s the approach I’d like to make.

Thanasis [00.28.30]: I think that’s the prior way anyway. Methodology is number one and how you build it can be a very useful weapon or you can cut your hands off. So definitely before you mix and match you need a deep understanding and appreciation of the methodologies and how the work. You need to have actual work experience spanning from multiple years, before you can appreciate a minor change in the mix can bring out as an outcome.

Dimitri [00.29.12]: But it’s not an absolute requirement. You’ll be reading, you’ll be applying it, you’ll be working with it on a daily basis and feel free to pick what is better for you. What would you recommend based on our conversation to our audience.

Thanasis [00.29.30]: I would recommend whatever works for your specific use case, but definitely have someone in the mix that knows what they’re doing. Either you, or if it’s not you have someone that understands those things and can provide a pathway for you.

Dimitri [00.29.54]: And I think if you’ve picked the right tools, like Trello for example, I think that could be the case of you saying “I don’t know what I’m doing, but I’m using Trello and I’m moving stuff across columns so maybe I’m using some sort of methodology”.

Thanasis [00.30.13]: No, I disagree. All kinds of things can happen on Trello boards. I’ve seen that, I’ve been trying to convince people not to create a list that says “Maybe we should do that, but now today, but it is important and urgent”.

Dimitri [00.30.32]: I see what you mean, Doing and To Dos go before Done and QA. I know it’s crazy.

Thanasis [00.30.44]: You need to have some discipline there.

Dimitri [00.30.59]: Okay, so make sure that the developers you hire, especially now in 2016, should have that in their toolbox.

Thanasis [00.31.13]: Definitely, if you have professional experience what have you been working on.

Dimitri [00.31.18]: I mean, you could have gotten away with it back in the day, like early 2000’s.

Thanasis [00.31.26]: Yes, I cannot see it happening today, we’re talking about cutting edge technologies here right?

Dimitri [00.31.30]: Absolutely!

Thanasis [00.31.36]: Awesome! So let’s do a round up, four plus one development methodologies, Waterfall, Scrum, Kanban, Mix and Match and the plus one is the Critical Path which is the honorary mention. So, that’s it for today, please send us your questions or remarks by calling us on 8663705050 from anywhere or you can email us hello@listenshiprepeat.com, subscribe on iTunes by searching for our podcast, feel free to go in there and drop us some stars or a review if you want, this helps us climb up higher in our respective categories and helps us make more episodes. Our website www.listenshiprepeat.com and you can also find our transcrips there. So until next time, thank you for listening tonight and from both of us, Goodbye!

Dimitri [00.32.45]: See you next time, Ciao!