Traditional software development challenges

The traditional way of doing software website development was something that they coined in 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 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. 

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 to 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. 

Leave a Reply

Your email address will not be published. Required fields are marked *

You May Also Like