Thought Leadership

December 2, 2020

Choosing the Right Software Development Methodology for the Project

Software Development methodology: We will discuss several of the most common methodologies like scrum software development or agile software development.

Executive Summary

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:

  • Description of the Common Methodologies
  • Which Methodology to Use and When?

Common Software Development Methodologies

Agile Methodologies

Today’s Agile Software Development methodologies base their foundations on culmination of several concepts and practices:

  1. Early Methodologies from the 1950’s, which were very similar to today’s Agile:  XP (Extreme Programming)
  2. Lean Manufacturing Practices - started by Toyota
  3. Iterative Software Development Techniques, which began in the 1970’s and began to take root in the 1990’s.

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.

SCRUM

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.


Agile: Kanban

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:

  • Limit the Number of Tasks / Items that each Person can have in their Queue at any one time.  This can vary, but is often somewhere around 3 to 5 Items.
  • Once this Limit is reached, everyone stops sending this Team Member New Work
  • Once they have “Free Space”, then you can give them a New Item.
  • Use Software Points / Complexity Points and assign Every Team Member a set maximum number for their Kanban Square.
  • Person A - can normally complete 8 Points of work in a reasonable time frame. So, if they are already at their Max, then stop giving them more work.
  • Person B - who is more junior, may only be able to handle 3 Points of work.

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.


And here’s what you are trying to avoid:  “Let her rip boys!”


Lucy and Ethell already couldn’t keep up with the pace, hence the Bon-bons in their mouths and hats.

Agile: Scrumban

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:

  • Historical Patterns and Ratios
  • New Product Launches or Releases - where your Support items will definitely increase

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.

Agile: SAFe

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:

  • Implementation of PeopleSoft using SAFe
  • Team Size ~75  (combination of IT Staff, Tech Consultants & SME’s)
  • Results:  only a single month delay in our “Go Live” date from our original Plan
  • Complete Rewrite of a Custom Financial Aid Processing Application using SAFe
  • Firm Deadline set by the US Department of Education
  • At Risk:  ~$400 Million in annual revenue
  • Results:  Able to “Go Live” 3 months ahead of the Firm Deadline
  • In addition, we were able to provide feedback and advice to the US Department of Education, as well as other Universities

Planned / Traditional Methodologies

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…”


Traditional:  Waterfall (and Related)

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:

  1. Project Charter and Initiation
  2. Requirements Gathering and Specification Document
  3. Software Architecture and Design
  4. Coding and Software Development
  5. Quality Assurance Testing
  6. User Acceptance Testing / Pilot
  7. Deployment to Production or “Go Live”

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.

Which Methodology to Use and When?

Now let’s take a look at each Methodology and when and where to use them.

Agile:  SCRUM

Scope of Work Requirements:

  • Mostly Defined
  • Some Change is Expected
  • Discovery & Analysis
  • Able to Plan

Also applies to:

  • Accounting (monthly Sprints / Closing the Period)
  • Human Resources

Risks:

  • Low to High Risk

Innovation Objective:

  • New
  • Major Enhancements

Team Size:

  • 5 to 30
  • 1 to 3 Scrum Teams

Agile:  Kanban

Scope of Work Requirements:

  • Unknown
  • Support Team
  • Reactionary
  • Not Able to Plan Well

Also applies to:

  • Sales
  • Marketing

Risks:

  • Fairly low
  • Small Minor Defect Fixes
  • Small Minor Improvements

Innovation Objective:

  • Maintain
  • Keep the Lights On
  • Minor Enhancements

Team Size:

  • Varies

Agile:  Scrumban

Scope of Work Requirements:

  • Somewhat Defined
  • Many Changes are Expected
  • Discovery & Analysis
  • Can Partially Plan

Risks:

  • Low to Moderate risk

Innovation Objective:

  • New
  • Enhancements

Team Size:

  • 5 to 30
  • 1 to 3 Scrum Teams

Agile:  SAFe

Scope of Work Requirements:

  • Adds more “Process” to Agile
  • Mostly Defined
  • Some Change is still Expected
  • Change may occur frequently at the Team Level
  • Discovery & Analysis
  • Able to Plan

Risks:

  • Moderate to Very High Risk

Innovation Objective:

  • New
  • Enhancing Enterprise Systems
  • Often Includes a Maintenance (DevOps) Team

Team Size:

  • Large to Very Large
  • 30+
  • 4+ Scrum Teams
  • Scrum of Scrums
  • Traditional

Waterfall, et al.

Scope of Work Requirements:

  • Fixed
  • Formal Specification Document
  • Requires Formal Planning
  • Formal Sign-Off
  • Very Little Change

Risks:

  • Very High Risk
  • Life & Death

Innovation Objective:

  • New
  • Enhancing Enterprise Systems

Team Size:

  • Large to Very Large
  • 30+

Conclusion

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.

Case Study from Arkusnexus
David Annis
David is a VP and Agile Coach within ArkusNexus, having served in multiple CIO, VP of Software Development roles. He assists our Sales, Marketing, and Operations Teams on critical initiatives.
dannis@arkusnexus.com
RSS feed
Subscribe to our feed
Back to More ContentMore From this Author
HomeServicesAboutBlogJoin UsContact
Privacy Policy
San Diego:
3065 Beyer Blvd B-2 San Diego, California 92154 +1-619-900-1164

Los Angeles:
530 Technology Drive Suite 100 & 200 Irvine, California CA 92618