Below is the transcript of the above video where you will learn more about a Development methodologies.
MELANIE FOXCROFT: Hello everyone, I’m Melanie Foxcroft from MF Consulting and I’m back with Maarten Kruger from Tech Genius. Today we will be discussing development methodologies and why proper planning is so important. Welcome Maarten.
MAARTEN KRUGER: Thanks Melanie.
MELANIE FOXCROFT: So, Maarten, can we please discuss the different development methodologies and how you go about?
MAARTEN KRUGER: Sure Melanie. So, basically the traditional way of doing software website development was something that they coined the Waterfall method. Now, it’s called the Waterfall method because it pretty much, it looks like a staircase going down. So, they’re pretty much a step that you do and then you have to do the next step and you have to do it in a specific order. So, what would typically happen – if I can compare it to a building project – what you would do is you would do all the planning. You would do all the technical planning. You would have a budget for the project. So, it’s quite a big thing, it’s a big development project and then the various phases would follow on each other. So, you would go through a very involved specification phase when you say what you’re going to do, what you’re not going to do, you provide the cost etc., provide a quote to the client. The client accepts the quote and then you would start development, and then you would do testing and then you would hand over the final product to the customer. Now, the criticism on waterfall is that it’s a very fixed process and because it’s such a big development process it’s very inflexible. So, what happens while you’re developing and the challenge is – the danger is – that the customer gets what the developers promised but when they actually see the end product it’s not what they wanted, and now you’ve spent this enormous amount of money. You’ve waited this enormous amount of time, you didn’t get what you wanted and the other thing is also while you’re developing and you may be giving feedback to your customer, the customer says: “No, stop. This is not what we wanted. We want it changed.” And the developers turned back and said, “Sorry, this is the specification and we quoted it.” Then we will deliver it as is and you just have to accept it. So, you can understand that because it’s big projects and big money involved, you know, it’s not a very happy place for the customer. So, this basically led to something which is called Agile development, which is now completely on the other side of the extreme. So, with Agile there’s very little focus on, you know, long-term planning and spending a lot of time on planning. What they’re basically doing is, you’re working in two-week sprints. So, you’re developing this thing little bit by bit. Now, in a perfect world it sounds great, because you know, the customer can change his mind. They’re seeing progress, you know, in little bits of chunks or whatever, but you know on that extreme you know it’s great for the developers because you know, we say we’re going to spend two weeks, this is the cost when we do it, we do what the customer told us to do, we show it to the customers and the customer says, “Okay, change it.” But now, how many cycles do you go through until you eventually get to the point where the customer is happy? Let’s say, you know, it takes you 10 cycles. Now, with proper planning that might have been five cycles. So, you know, you may have spent double your budget than if you did proper planning beforehand. So, that’s why we as Tech Genius, we’re not extreme Waterfall and we’re not extreme Agile. We are somewhere in the middle where we found a happy place where we believe in the value of planning – and proper planning – but we don’t just look at the short term completely. So, we plan far enough in advance but then we build in short little iterations that the customer can still change his mind and we find that’s a real happy place for us as well as our clients.
MELANIE FOXCROFT: And Maarten, I’ve heard about Scrum. That’s also a crucial part of development methodologies. Can you explain Scrum to me – that term?
MAARTEN KRUGER: Yes, it’s not rugby! But it can get a little bit confusing with all the terminology going around. So, Agile is pretty much a methodology of you know doing it, being agile, being responsive, being flexible. Scrum is a way of doing Agile. Now what Scrum in sort of pure form basically says, is that in an organization, you can have somebody that’s got a job title of whatever job title he has, but then you can take your organization and divide them into smaller teams. Now, in these teams there are basically three roles that comes into play. So, it means that, let’s say there are basically three roles, and the three rules is number one is a product owner, and you get a scrum master and then you get a development team that consists of development team members. Now, the product owner is pretty much the person who’s responsible. He’s the owner. He’s the middle man between – he represents the business towards the client and he makes a call on what work gets done which they actually, technically, call a backlog. So, he’s basically in control. Then the development team is not just developers. It could be developers, testers, it could be graphic designers. Whatever the team consists of two actually produce the end product and then you get something that’s called Scrum Master. Now the Scrum Master is pretty much, they describe it as a servant leader. So, it’s somebody that, pretty much, is the glue that’s keeping the team together. Making sure everything gets done. But it’s in a servant style of leadership. So, it’s not somebody that’s, you know, bulking out orders and whatever. Whatever needs to happen to glue this team together, they do that. So, this is pretty much what Scrum is all about. But, once again, in the real world you often see that scrum isn’t 100% pure and it doesn’t have to be. The point is to be Agile, you know, to be responsive and flexible.
And something that’s often added into the mix is something that’s called a Business Analyst. And a Business Analyst or a Systems Architect is somebody who sits with the client and basically writes up specifications, understands and needs etc. So, in practice you’ll find that the roles might differ slightly from the, you know, pure scrum, official literature on the topic.
MELANIE FOXCROFT: Thank you, Maarten. These are extreme terms and I’ve learned quite a lot today
and just a final word about why proper planning is so important?
MAARTEN KRUGER: Yes um, you know, if I can compare it to a building project again, nobody thinks it’s a great idea to build a house without official plans that were drawn up by an architect and was approved. Yet, for some reason people think it’s a brilliant idea to do software and web development projects of large scope in this way. So, if I can compare it to an architect. When you go to an architect you typically won’t go to an architect and say “Listen here, I want my house plans modified and what you need to do is, you need to put in a south facing room that’s four-by-four meters with a four-meter stack fold door and you must draw it that way. What you’ll do is you’ll sit with the architect and the architect will ask you questions. He will ask questions like, you know, what do you enjoy? What’s important to you? You might say, “Oh, family time and you know.” So, what do you want? What’s, what are the shortcomings of your house? “No, it’s actually cold you know, there’s not a place for the kids to play. It’s not a place for us to socialize and braai.” Now the architect will say okay all right so the technical requirements is you need more sunlight. So, it needs to be north facing and you want to let in as much light as possible. Oh, and you enjoy the garden so let’s make it a wide-open door that can open. A friend once told me, you know, the difference between an amateur and a professional is an amateur YOU need to tell what to do, a professional actually tells YOU what to do.
So, what is important when we sit with clients is, understanding their world. Understanding where they want to go to, what their heart is, where they want to take the business and what the shortcomings are, what the pain points are. And from that you can figure out okay, what’s the technical requirements? Does the client need a mobile, a progressive web app? Does he need a website? Does he need a mobile app? Does he need a spreadsheet system? What is the need over the short term? What is need over the long term? And all of this starts with our first free one-hour brainstorming session. It’s amazing what you can achieve just in an hour sitting with a client, just talking about these things. What are the needs? What are the pain points? Just trying to understand their world and that’s pretty much where it all starts.
MELANIE FOXCROFT: Thank you, Maarten. Very informative, as always. I always learn something from you (this time about development methodologies) and as always, stay safe, stay tuned and don’t forget to visit www.techgenuis.co.za.