In this Blog Article we will discuss several of the most common Software Development Lifecycle Methodologies in use in modern software development teams. This is not meant to be an extensive list, as literally there are hundreds of different methodologies that have been used over the years. We’re only going to focus on the most prevalent Agile and Traditional methodologies in common use today.
We will cover:
Today’s Agile Software Development methodologies base their foundations on culmination of several concepts and practices:
It is important to note that “Agile” or Lean SDLC are really an umbrella of a wide variety of individual methodologies, which share similar traits. I’ve only picked the most common ones in use today, but there are well over a 100 different flavors.
The whole concept of Scrum is to break down the Software Development Manufacturing process into short increments called Sprints (most often 2 weeks), with a set number of team members, that produce working software at the end of that period, which can potentially be released into Production.
It is very team oriented and the objective of the entire team is to help each other accomplish the goals that they set out to accomplish during the Sprint. What is being worked on during the course of the Sprint can change, and if a new 5 Point Story is brought in, then the business must decide what 5 Points worth of Stories is taken out of the Sprint.
Kanban comes originally from the Toyota Lean Manufacturing Principles. And originally was a square that was taped on a worker’s table or workspace. This square contained what the worker is supposed to work on. If it was Full, then the worker before them in the manufacturing line stopped working. And once the Kanban Square had room, then they would continue and send more items to the next worker.
This fundamentally changed the flow of Work In Progress items and turned it into a “Pull Manufacturing” process. Now the entire line looked for bottlenecks in the process and no longer just tried to “Throw things over the Wall”.
Today, we have adapted the concept of a Kanban Square into a Kanban Board, where everyone involved in a process can see at what Step an Item is in, and easily move it to the step once it is complete. This also allows Management or Project Managers to control the flow through each step. This can be done in two different ways:
Regardless of how you measure the Size of the Kanban Square, it will vary from Employee to Employee. More junior staff need a smaller Square, while typically more senior staff can have a larger Square - so long as they don’t have other duties within the Organization.
Transforming your “Production Line” from a Push to a Pull process normally will have huge productivity benefits. While it may not seem intuitive at first, in most cases you will see anywhere from a 10% to 30% productivity jump.
Lucy and Ethell already couldn’t keep up with the pace, hence the Bon-bons in their mouths and hats.
This is simply a combination of both Scrum and Kanban put together for a single Team or a small group of Teams working on a Larger Project. Items that can be Planned, are handled in more of a Scrum process. Items that are more random in nature, like Support Tickets, are handled in a Kanban mode.
Even if you only have a single team, during a given Sprint you may assign some team members to the Planned Work, while others are assigned to the Variable or Unplanned Work that comes in.
Typically, the Project Manager / Scrum Master would set aside a certain amount of Team Capacity to handle the Unplanned Work that comes in, based on:
For example, if a Team of say 14 can normally complete 100 Points of Software per 2 week Sprint, you may allocate 8 to New Feature Development (Planned), and the other 6 to Unplanned Work (Kanban).
Alternatively, you can have all of the Team Members switch back and forth during the course of the Sprint. This way, individuals get the experience of working on both aspects of the project. However, it is true that some people will gravitate to one or the other, based on their personality.
SAFe or the Scalable Agile Framework is one of the more popular methods to Scale Agile techniques to larger organizations, teams and projects. This is normally required when you need to start applying more processes or governance to the entire process. Typically, you will start with having Daily Scrum-Of-Scrums, after all of the individual Team Meet. This is critical because as the Executive, you want to know as quickly as you can what problems or impediments each team has, and how to solve them.
And in some cases, you may have to move resources from one team to another temporarily to solve an issue. Naturally, this is always a balancing act. But the sooner you know, the sooner you can react, and solve the issue, whatever it is.
I have used these techniques personally on several medium to large scale Projects and Teams:
As with Agile Software Development Lifecycle methodologies, there are numerous Planned or Traditional project management methodologies. Most of these methodologies came originally from large scale engineering or construction projects. If you are building a Battleship, and you’ve already laid down the keel and hull, it becomes nearly impossible to suddenly say we need an extra 16” gun turret in the front. Or, if you are building a skyscraper and already have 10 floors done, and suddenly say… “Oh we need to move the entire elevator shaft from here to there.”
For all of these reasons and more, with these types of projects you must plan out as much as you can in advance, before starting the next step in the process. Otherwise, you can end up with extremely costly changes or worse a Ship that will sink in bad weather, or a building that can’t be used as intended.
Everyone who has ever been involved in a major Construction project has their own stories of the “Stairwell to Nowhere”, or a “Door that opens to the Sky with a 4 Story drop”, etc. This is why Planning is so critical for these types of projects.
However, in most cases, this level of Planning is not as critical within Software Projects, as we can relatively speaking change things quickly and in most cases at a relatively low cost. So, if you want to move this Screen from this location to over here, in Software we can do that. At the same time, there are times when making a fundamental change will be hugely expensive, doesn’t make sense from a technical standpoint, or involves a project where you are dealing with an extremely high quality threash-hold like 99.99% or even 99.9999% reliability.
TRUE STORY: one time I was giving a presentation to our Board of Directors, when two Board Members asked why we were still using MS SQL Server hosted on AWS for our core system, instead of a “more modern” database - which they had just read about. Our debate went on for some 30 minutes, until I said, “Gentlemen, our core MS SQL Server instance on AWS costs us around $450 per month, we’ve spent more in terms of our time than that just discussing this today. And if you want us to rip it out and replace it, then we’ll easily need an additional CapEx budget of at least a half million dollars. And it won’t significantly improve our business or operations. Is that really what the Board wants us to do?”
Silence... “Ok, for our next topic on the Agenda…”
The Traditional Waterfall methodology is actually the easiest to understand for anyone who has not been previously training in Lean Manufacturing or Agile Techniques. After all it is a very simplistic concept. You complete each step in order, before moving on to the next step.
In Software Development, for a Project using this methodology, this means:
However, as Dr. Royce in 1970 pointed out in his IEEE paper on the Waterfall methodology, it is a flawed model for Developing Software, because there are little if any feedback loops. Each step tries to work as fast as they can, and simply throw it over the wall once they are finished.
The other problem comes about when the Internal or External Client changes their mind in terms of what they want the software to do, or perform. Even minor changes can cause project delays or costs overruns; because the whole idea of a “Planned” project is that you know all of the Requirements up front and the Scope is Fixed. Which in most cases, is simply not realistic. Often the Client doesn’t really know what they want. At the same time, there are very specific projects where you want to use a more heavyweight and structured methodology.
Now let’s take a look at each Methodology and when and where to use them.
Scope of Work Requirements:
Also applies to:
Risks:
Innovation Objective:
Team Size:
Scope of Work Requirements:
Also applies to:
Risks:
Innovation Objective:
Team Size:
Scope of Work Requirements:
Risks:
Innovation Objective:
Team Size:
Scope of Work Requirements:
Risks:
Innovation Objective:
Team Size:
Scope of Work Requirements:
Risks:
Innovation Objective:
Team Size:
The bottom line is that every SDLC Methodology is a tool in your Toolbox. Determine what type of Project you have (or Operation), and then pick the right Tool for the right Job.
For example, if you are Managing a Sales Organization, it probably doesn’t make any sense to use a Traditional Waterfall model to manage your leads and opportunities through the Sales process, as things change constantly. However, a Kanban approach might make a lot of sense - which is also why many of your modern CRM Systems have Kanban Boards for you to use.
Likewise if you are implementing a very large ERP system with say 100+ staff, you will probably want to break the project into multiple Teams and use something like SAFe to manage the overall effort. This way you can still react to new changes fairly quickly, while also having enough structure and governance to accomplish the Project in a reasonable time frame. I would avoid using a more Traditional / Waterfall approach, because even in an ERP implementation - things change, the Client “just remembered something”, and the business needs may change over the course of the implementation.
We hope that you have enjoyed this Blog Article and found it useful.
Thank you, David Annis.
