Re-visit Basics: SDLC Models Part 1

Hey LinkedIn family! Lately, I've been revisiting the fundamental concepts that shaped my impactful 8-year journey at Softserve. Why the trip down memory lane? Well, I'm currently ramping up hiring efforts and realized how essential it is to keep my skills sharp. Although I'm not hiring as intensively as I did in the bustling pre-pandemic outsourcing days, I've noticed that the knowledge that once sculpted my early career is starting to fade. Staying sharp is more crucial than ever!

This reflection has sparked an idea—why not turn these revisits into a series of posts? My aim? To structure info in an easy-to-grasp way and hopefully to make it useful for some of you. Let’s begin with something fundamental yet crucial: Software Development Life Cycle (SDLC) models.

Here’s a breakdown of the SDLC models I find most pivotal

1. Waterfall - The classic, linear approach. Perfect when your requirements are as clear as a sunny day!
2. Agile - For those who love flexibility and adapting on the go.
3. Scrum - Think Agile, but with a twist, organizing into sprints.
4. Scrumban - Kanban vs Scrum or visual flows vs. structured sprints. Why not both? Exactly that; the best of both worlds!
5. Lean - Do more with less, optimizing as you go.
6. XP (Extreme Programming) - For teams dedicated to continuous iteration and customer satisfaction.
7. Scaled Agile - Taking Agile to the enterprise level.
8. MS Security Development Lifecycle (SDL) - Security from the get-go? Yes, please!
9. Spotify Model - Agile on steroids with autonomy and culture at its core.
10. LeSS (Large Scale Scrum) - Scrum went big, yet kept it simple.
11. Scrum at Scale - Transforming organizations into agile networks.
12. Feature-Driven Development (FDD) - Breaking down projects into specific, client-valued features.
13. Dynamic Systems Development Method (DSDM) - An Agile framework that integrates best practices from previous models.
14. RAD (Rapid Application Development) - Speed is key. Ideal for projects needing quick development.
15. V-Model - Another extension of Waterfall that emphasizes quality through test planning.
16. Spiral - Combines iterative development with risk management, perfect for large, complex projects.

For sure there are more, but this article should be finite right? xD

Waterfall SDLC is like planning out a construction project from start to finish before you even pick up a hammer. You lay out everything you’re going to do in a sequence of steps, each one depending on the one before it. Imagine setting up dominoes in a line—once you knock the first one over, you can’t stop the rest from toppling in order.

Here’s the usual lineup:

1. Requirements: Figure out what exactly you need to build. This is like creating a blueprint before building a house.
2. Design: Plan how the software will be structured and how different parts will interact.
3. Implementation: Write the actual code based on the design.
4. Verification: Test the software to make sure it works as intended.
5. Maintenance: Keep the software running smoothly and fix any issues that pop up after it’s launched.

Agile is like building a Lego set without sticking strictly to the instructions. You have an idea of what you want to build, but you’re open to swapping pieces around and adjusting your plan as you go based on feedback and new ideas. It’s a more flexible and dynamic approach compared to the rigid steps of Waterfall.

Here’s how Agile typically rolls out:

1. Planning: Start with a basic plan of what needs to be built, but keep it loose and adaptable.
2. Iterations/Sprints: Break the work into short cycles, usually a few weeks long, where you create small, functional pieces of the software. After each sprint, you have something usable.
3. Daily Meetings: Have quick, daily check-ins (often called stand-ups) where team members discuss progress and any roadblocks.
4. Review and Retrospective: At the end of each sprint, review what was built and discuss what worked and what didn’t. This helps improve the next sprint.
5. Continuous Improvement: Keep refining and updating the product based on user feedback and changing requirements.

Scrum is a flavor of Agile SDLC that's all about teamwork, regular updates, and flexibility. It's like a rugby team (which is where it gets its name) passing the ball back and forth, adjusting to the field and opposition in real-time to reach the goal.

Here’s the play-by-play of Scrum:

1. Roles: There are three main roles. The Product Owner who knows what needs to be built and sets the priority, the Scrum Master who ensures the team works smoothly without obstacles, and the Development Team who do the actual work of building the product.
2. Product Backlog: This is the master list of everything that needs to be done on the project, sorted by priority. The Product Owner is in charge of this list.
3. Sprints: Work is divided into sprints, typically 2-4 weeks long, during which specific tasks (user stories) from the product backlog are tackled.
4. Sprint Planning: At the start of each sprint, the team selects a chunk of tasks from the product backlog that they believe they can complete by the end of the sprint.
5. Daily Scrum: Every day, the team has a short meeting (usually just 15 minutes) to share progress, discuss challenges, and plan the day's work.
6. Sprint Review: At the end of each sprint, the team presents what they’ve built. This is an informal meeting with the stakeholders to show off the new features.
7. Sprint Retrospective: After the review, the team discusses what went well and what could be improved for the next sprint. This is all about learning and getting better.

Scrumban is a hybrid project management methodology that blends the structure of Scrum with the flexibility of Kanban. It's like having the best of both worlds: you get the regular sprint planning and roles from Scrum, mixed with Kanban’s continuous flow and emphasis on visualizing work.

Here's how Scrumban usually works:

1. Roles and Meetings: Scrumban typically retains the roles from Scrum (like the Product Owner, Scrum Master, and Development Team) and some of the meetings, but these can be adjusted depending on the team’s needs. For instance, daily stand-ups might be kept, but sprint reviews could be less formal or structured.
2. Board and WIP Limits: Work is visualized on a Kanban board, and Work In Progress (WIP) limits are applied to ensure that team members don’t take on too much at once and can focus on finishing tasks before starting new ones. This helps improve flow and reduce bottlenecks.
3. Backlog and Planning: There is a product backlog, but planning is more flexible. Instead of fixed sprints, planning and task pull are based on the team's capacity and the urgency of tasks. New tasks can be added to the board anytime, and the team pulls work as they finish current tasks.
4. Iteration and Feedback: While Scrumban doesn’t necessarily follow the strict time-boxed sprints of Scrum, it still incorporates regular opportunities for feedback and iteration. This could be at the end of a set of tasks or when the team feels it's necessary to review progress.
5. Improvement and Adaptation: Continuous improvement is a key aspect of Scrumban. Teams regularly reflect on their processes and workflow to find efficiencies and make adjustments on the fly, rather than waiting for a retrospective at the end of a sprint.

Lean SDLC is a streamlined approach to software development that's all about cutting the fat and focusing on value. It's like running a tight ship—only keeping what's necessary and ditching everything else that might slow you down. The philosophy comes from Lean manufacturing principles, which aim to maximize customer value while minimizing waste.

Here's the gist of how Lean SDLC works:

1. Eliminate Waste: This is the heart of Lean. The idea is to get rid of anything that doesn’t add value to the customer. This could be redundant processes, unnecessary features, or even meetings that could be emails.
2. Amplify Learning: Instead of setting everything in stone from the start, Lean encourages ongoing testing and feedback. This helps the team learn quickly what works and what doesn’t, adapting the product as they go.
3. Decide as Late as Possible: By delaying decisions until the last responsible moment, you can make more informed choices with the most current data at hand. This flexibility allows for better outcomes.
4. Deliver as Fast as Possible: Speed is key. The quicker you can deliver iterations of your product, the quicker you get feedback, and the better you can refine it.
5. Empower the Team: Lean believes that the people doing the work have the best understanding of how things should be done. It encourages giving teams the authority to make decisions and suggests leadership acts more as facilitators.
6. Build Integrity In: Focus on creating a good product from the start. This includes coherent design, clear code, and considering both the user experience and the product’s broader impact.
7. See the Whole: Avoid sub-optimization (improving one part at the expense of the whole). Keep an eye on how all parts of the system fit together, ensuring they work harmoniously towards the final goal.

Extreme Programming (XP) is a software development method that's all about improving software quality and responsiveness to changing customer requirements. It's like putting your development process on turbo-charge, focusing heavily on customer satisfaction and team productivity.

Here's the quick scoop on XP:

1. Frequent Releases: XP emphasizes releasing updates in short cycles. This rapid feedback loop helps teams make adjustments quickly and keep the product aligned with customer needs.
2. Pair Programming: Two heads are better than one, right? In XP, developers work in pairs, sharing one computer. This not only improves code quality but also spreads knowledge across the team.
3. Test-Driven Development (TDD): Writing tests before you write the actual code might sound backwards, but it ensures your software is always ready to ship, with fewer bugs.
4. Customer Involvement: XP requires a representative from the customer to be an active part of the team, making decisions and providing feedback in real time.
5. Simplicity: The focus is on doing only what is needed today and not getting bogged down in features or designs that might not be necessary.
6. Continuous Feedback and Improvement: Regular reviews and adaptations of both the project and the practices ensure the team remains effective and the product meets expectations.

Scaled Agile, often referred to by its framework name "SAFe" (Scaled Agile Framework), is a way of scaling agile practices to larger organizations and more complex projects. It's like taking the principles that work well in a small team and amplifying them to work across multiple teams or even entire departments.

Here’s a quick rundown of how Scaled Agile works:

1. Alignment: SAFe emphasizes alignment across all levels of the organization. This means ensuring that everyone from top-level management to individual agile teams understands and works towards the same business goals.
2. Built-in Quality: Quality isn’t just an afterthought; it's integrated into every stage of development. This includes adopting practices like Test-Driven Development (TDD), continuous integration, and pair programming on a larger scale.
3. Transparency: By making work and progress visible to everyone (using tools like big room planning and Kanban boards), SAFe helps foster trust and clear communication among teams and stakeholders.
4. Program Execution: This is the heart of SAFe where the actual work happens. Multiple agile teams collaborate and deliver incrementally through set program increments (PIs), typically 8-12 weeks long. Each PI ends with a demo and a retrospective to reflect on what went well and what could be improved.
5. Lean-Agile Leadership: Leadership within a SAFe environment encourages a shift from traditional command-and-control tactics to more agile behaviors—leaders are expected to coach, facilitate, and lead by example to help foster an agile culture.
6. Innovation and Planning (IP) Iteration: This is a buffer iteration at the end of each PI that allows teams to address maintenance, fix bugs, innovate new solutions, and plan the next increment without the pressure of immediate deliverables.

The Spotify model is a people-driven, autonomous framework for scaling agile that emphasizes the importance of culture and network. It was developed by Spotify in an effort to maintain an agile and innovative environment as they grew rapidly. Unlike other scaling frameworks like SAFe, which are highly structured, the Spotify model is more of a flexible guideline that focuses on adapting to the unique needs of the organization.

Here’s a breakdown of the Spotify model:

1. Squads: These are the basic units of development, similar to Scrum teams. Each squad is self-organizing and has full autonomy to decide what to work on and how to do it. They are aligned to a clear mission, often a feature or a product area.
2. Tribes: Several squads that work in related areas are grouped into a tribe. The purpose of a tribe is to provide a home for squads with similar knowledge and skills. Tribes help facilitate larger-scale coordination and sharing of resources while maintaining a manageable size to keep communication efficient.
3. Chapters: These are groups of people with similar skills and specialties within the same tribe. For example, all the backend developers in a tribe might form a chapter. Chapters meet regularly to discuss their area of expertise, share knowledge, and work on improving their skills.
4. Guilds: These are more informal and cross-tribal groups for sharing knowledge, tools, code, and practices. Guilds connect people across the entire organization who want to share their knowledge or passion about a specific area (e.g., web technologies, leadership, testing).
5. Autonomy and Alignment: One of the key principles of the Spotify model is maintaining a balance between autonomy and alignment. Squads are given the freedom to make decisions and innovate, but they are also aligned to the company’s goals and missions through various alignment mechanisms like quarterly alignment sessions and company-wide betas.

The Microsoft Security Development Lifecycle is a software development process that Microsoft created to reduce software vulnerabilities and manage security risks during development. Think of it as a checklist or a roadmap that helps developers build safer software from the start.

Here’s a brief rundown of what the SDL involves:

1. Training: Before anything else, developers get trained in secure coding practices. It’s all about prepping the team with the knowledge they need to recognize and avoid security pitfalls.
2. Requirements: This stage involves defining what security measures are necessary for the project. Developers decide the security features that need to be included and set the security standards the software must meet.
3. Design: Here, the team designs the software with security in mind. This might involve threat modeling, where they identify potential threats and vulnerabilities and figure out how to mitigate them in the architecture of the software.
4. Implementation: During coding, developers use secure programming practices to minimize vulnerabilities. They also use tools to automatically check the code for security issues as they go.
5. Verification: This stage involves rigorous testing to catch any security issues that slipped through. This includes static and dynamic analysis, penetration testing, and other security reviews.
6. Release: When the software is ready to go live, it’s released with a plan in place for responding to security incidents quickly.
7. Response: After release, the focus shifts to monitoring the software for any security issues in the wild and responding to threats as they arise.

LeSS (Large-Scale Scrum) is an approach to scaling agile practices to larger organizations with multiple teams. It's essentially Scrum but super-sized, aiming to keep things as simple and lightweight as possible, even in a big setup. Think of it as Scrum with a megaphone, where the fundamental principles are amplified across many teams.

Here’s a quick rundown on LeSS:

1. Fewer Roles, More Scaling: LeSS tries to stick close to regular Scrum by minimizing additional roles and structures. You still have your Product Owner, Scrum Masters, and development teams, but now they operate on a scale that involves multiple teams working on the same product.
2. Whole Product Focus: Unlike some frameworks that manage complexity by breaking work into smaller, disconnected parts, LeSS focuses on the entire product. The idea is for every team to have a clear view of the big picture and how their work contributes to the overall goals.
3. Feature Teams: Teams in LeSS are cross-functional and focus on delivering complete features. This avoids silos and promotes better integration and coordination among teams.
4. Sprint Planning in Two Parts: To manage the interdependencies between teams, sprint planning is divided into two parts. The first part deals with what will be delivered, and the second part focuses on how it will be delivered, with teams coordinating their plans.
5. One Product Backlog: There’s only one product backlog for all teams, maintained by the Product Owner. This ensures a unified direction and priority setting across the product development.
6. Regular Retrospectives and Reviews: Like Scrum, LeSS emphasizes the importance of retrospectives for continuous improvement. In LeSS, there are team retrospectives and an overall retrospective to address issues affecting multiple teams.

Hey, it seems crafting this cheat sheet is taking more time than expected—it's already 3:40 AM and we're still in the thick of it! Let’s pause here and continue with a Part 2 soon. Looking forward to sharing more insights and engaging in further discussions. See you there!

#SDLC #SoftwareDevelopment #Agile #Scrum #TechTalk #SoftwareEngineering #LateNightThoughts #Part2ComingSoon