SDLC tools in methodologies

5 min read

There are plenty of practices which were tried in different types of projects and came from the vast experience of engineers working on them. Examine your problems and find a tool which fits your work; don't believe all the marketing around it. Below is a list of practices with my opinion from my experience, hope it will be useful.

Agile vs Waterfall

Agile was born as a reaction to disconnection inside projects, and there are a lot of different methodologies and flavours which companies will try to sell. But the core is this document - Agile manifesto. In times of confusion always come back to this one.

Gantt diagram

Famous: Waterfall

Representing waterfall. Has a reputation because of issues between managers and engineers. Often estimations from engineers are baked into the plan and immediately transform into commitments. Another issue is that such diagrams are passed on to higher management, and many details are lost. Some tasks on high-level diagrams may look similar, but in fact may share only the name. And from a management point of view, such tasks should be easily transferred and similar tasks should have exactly the same estimations, which is not what happens in real life.

Opinion: great tool if kept in sync on all levels of management.

UML

Famous: RUP (Rational Unified Process)

Introduced a process with a lot of formal diagrams. I've never seen such a process fully implemented anywhere, but we still have a lot of diagrams around, and sometimes they follow the style.

Opinion: out of style, but you can still find pieces of such diagrams useful.

Kanban board

Famous: Kanban

Came from industrial practices, where every machine is a place and can perform a specific function. Say you have one machine that can produce 2 handles per hour. And the next machine in line can produce 1 hammer per hour, assembling a handle and a head. But such a machine will be working slower, accumulating unused handles, and at some point the handle machine should be stopped. Now we do a mental leap and change machines to team members, such as developers and engineers. Now you have the same problem: how to keep the flow through the system to have proper throughput.

Opinion: great tool if the team is specialized or you can group tasks.

Stand up meetings

Famous: Scrum, XP

Working with code requires concentration, so by design a lot of us are sitting and looking at monitors. Each person is in flow with a problem, and sometimes you lose a sense of how long you've been trying to solve it. And sometimes sharing it with others may bring up the fact that somebody has already solved such a problem, or that it's unsolvable and needs to be escalated. A lot of devs complain that it turns into a meaningless chore, so it needs some effort to keep it useful.

Opinion: use with new teams or if communications are unstable.

Pair programming

Famous: Extreme Programming

The most radical part of Extreme Programming. If you've tried it, you know that sitting next to a typing developer and looking at a monitor is a painful experience, as you feel that it could be moving faster. A waste of time for scaffolding work, but may be beneficial for complex tasks. Nowadays it survives mostly as whiteboarding activities, but still it's easy to jump on a teleconference to see with your own eyes what the bottleneck is.

Opinion: use for hard tasks only or sync on the task.

Planning poker

Famous: Scrum

There is a cognitive bias: once anybody mentions an estimation of a task, there is no need to think about it anymore. Hence with planning poker, everybody opens their estimation at the same time. If numbers are different, it may uncover a lot of interesting things: different developers may have different architecture in mind, or they forgot some big pieces or roadblocks. It also encourages quiet members to speak more. There are cards, or you can find a tool online (for example https://planning-poker.teamretro.com/, not an advertisement).

Opinion: use as an ice breaker with mixed teams.

Sprints

Famous: Scrum

Unlike in Kanban, the measured artifact is not a person, but a team, and team production (velocity) is measured over equal time intervals. A known trick is also to use abstract velocity points (such as story points or t-shirt sizes), to disconnect from hard task estimations and comparison between teams. Once a sprint is started, in an ideal process no new tasks arrive and managers can track team performance by looking at a burndown chart. Or a burn up chart.

Opinion: backbone for building communication and demonstrating pace outside of a team.

Minimum Viable Products

Famous: Lean

Another famous issue with Waterfall is that for a big project high level tasks may look like design -> development -> testing. But for higher-ups it may be tempting to hire a BA team for a year, then hire a DEV team for a year, and so on. From history we know that such attempts fail loudly, as complex software systems are quite intricate and fluid, and it's not easy to predict everything. Here is the idea to build smaller pieces and test all the issues connected to them, but a piece should be reasonably big enough to prove that the concept or technology works. Quite a popular thing.

Opinion: useful on projects with high uncertainty.

Betting

Famous: Shape Up

Shape Up accepts that requirements in products only guess the outcome. The idea here is that enough evidence should be collected beforehand to understand which feature may bring more value, and the team bets on this feature.

Opinion: a tool for people who make decisions, which allows them to state risk upfront.

Conclusion

You can see a lot of tools here, and a lot of the projects I've seen mix and match them, as there are a lot of process and technical specifics in software products depending on domain and organization. Don't hesitate to build your own if needed. Thanks!

Links