Case Study Review
This was a case study on a project that faced some classic SDLC challenges. I won’t go into them here, but rather focus on some of the takeaways that were most interesting to me.
- Be very strict on the brevity of stand-up. I thought this was a very subtle, but potentially huge point that was mentioned. The point of stand-up isn’t necessarily to give a status report to the project manager, but to make everyone on the team aware of what everyone else is doing. This is a very important distinction because the more people that are aware of the blockers and potential roadblocks of the team, I believe it automatically “escalates” the issue because it’s not something hidden and isolated to an individual team member. So I believe efficient stand-ups raise the awareness of the team on general progress within a sprint, potential blockers, and blockers that are beginning to take longer than they should to resolve. This could lead to better sprint planning in the future because the entire team can use this awareness to speak up and try to prevent this issue from hindering the sprint completion in the future. The alternative is that only the project manager is keeping track of these issues. A system with multiple points of failure is better than a system with one point of failure. This type of thing gets lost if stand-ups turn into marathons where you never really know what the rest of the team is working on. You may be the blocker and never quite understand that from standup that are filled with fluff.
- Make sure you’re really blocked. One example that was given was a developer saying they’re blocked on a story because they don’t have the assets from the design team. The mitigation strategy was, you can at least put a placeholder image in place with the expected dimensions so when the real assets are available you can do a simple swap. I thought this was brilliant! And I think there are a lot more instances like that where even if you are blocked, more can be done.
- The importance of a plan. Sounds simple, but this is often the cause of lots of hiccups in the SDLC. Trying to effectively run a software project without a prioritized backlog is like trying to build a home without a blueprint. You may get a few walls up and have windows, but it’s going to be a struggle to make them all work together. You may have built one too many windows, not enough walls…etc. It works the same way with software, where you could end up with components that don’t fit well with others, some components that don’t get used at all.