?? Mastering SDLC in Small Scattered Teams! ??? [Consultancy Case]

Hey there! ?? Today, I want to walk you through the Software Development Life Cycle (SDLC) – how to manage it and what is essential when you are very limited with all possible resources! ??

Let's imagine you approach a typical small to mid-size outsourcing vendor. This is a great example since there are always many tiny projects, tight schedules, and customers with limited budgets. A typical manager handles 2-5 projects, some requiring only a few hours a week to keep them moving with a distributed team and unstable time allocation. There is no Agile framework, Kanban, or any structured methodology. Hopefully, requirements are documented and not just in someone's mind! ??

If you’ve been there, you know these projects are hard to kick off, maintain, and keep moving. I start by learning the existing SDLC or agreeing upon one that will be clear for all parties and consider the team configuration. ??

A Concrete Challenge

• Project Status: The project was postponed due to an overdue bill and needs to be restarted. ?
• Requirements: As usual, requirements are scattered and vague. ???
• Team Composition: You have two developers (one full stack and one back-end) and a manual QA engineer previously on the team. ??
• Time Allocation: Developers are allocated 16 hours a week each, the QA 8 hours a week, and a PM 4 hours a week. ?

Steps to Take

1. Discuss Terms and Expectations: Gather current expectations regarding the project status from the customer. ??
2. Re-onboard the Team: Negotiate the team's needs, requirements, and communication framework with the customer. ??
3. Agree on SDLC: Establish a clear and agreed-upon SDLC. ??
4. Set Up Regular Events: Schedule team sync meetings, ongoing calls with the customer, and demo calls. ??

Building a Stable SDLC

• Requirements Refinement Flow: Schedule calls with the customer to create ticket descriptions and approve ETAs. ??
• Backlog Management: Maintain a board with backlog and statuses up to date in a bug tracker. ??
• Task Movement Definitions: Clearly define the criteria for moving a task (story, ticket) from one status to another. ???
• Demo Preparation Meetings: Regularly prepare for demos to showcase progress. ???

Self Check

• Definition of Ready (DoR): Ensure each task has a clear definition or what needs to be clarified with the customer in the next refinement call. This policy should encompass all necessary details to ensure that a task is ready to be started and successfully completed. DoR check could be covered either by the PM, BA, or any team member. ?
• Maintaining Statuses: Build the process like a relay race, enabling your distributed, part-time team to work asynchronously and avoid known obstacles. ??
• Definition of Status: Add checklists for moving a ticket from one status to another, describing the steps needed before marking a task as ‘ready for QA’ or ‘ready for demo’ (for example). The last one ensures all tickets are done, tested, and nothing is broken on production or on a production-like environment. ??
• Demo Preparation Meetings: These are crucial in the early stages, and you will determine if they need to continue regularly. ??

Conclusion

As you can see, there is no rocket science involved. Start with sync calls, agree on project rules and attitude, make the SDLC clear to all parties, and help the process flow like a relay race. If every team member understands the whole process, the interconnections between each other, and respects others' time by preparing their work for the next stage, the project will work like clockwork. Tick-tock. ??

Refine -> Develop -> Test -> Deploy and repeat... ??

I hope this was helpful. ??

P.S. I know there are sometimes challenges with the team, people, customers, requirements, and many other things. Stay tuned; I will tell you about them soon! ??