Several years ago, I wrote an article entitled “The 7 Silent Project Killers”. Over the years, I’ve had several people comment, email, and request that I also provide potential solutions. I’ve generally, tongue in cheek, commented that I save those for my clients. However, in today’s post, we’ll explore a few potential solutions to several silent project killers. (If you don’t recall what they are, you can review them here).
Solutions for Scope Creep
A problem that I see many teams struggle with is scope creep. A product starts with X features, and it’s 10X features by the end! To get rid of scope creep, you have to recognize that you’ll never get rid of scope creep! Scope creep, to some degree, is good. The customers, product owners, or whoever have new and useful features that they want to be added to the product that makes it better. That’s good, but the problem comes in because of how scope creep is handled.
Teams will often lose discipline with scope creep and bounce around from one feature to another. The result is scope creep that prevents core product features from being completed or deployed. Potential solutions to this can be simple:
- Focus on completing the minimum viable product features first. If the minimum features aren’t there, you don’t have a sellable product! So all the nice to haves can be ignored.
- When new features are requested, they need to be prioritized and placed in the backlog. If the feature isn’t a priority or a core feature, implementation is delayed until higher priority features are completed. Yes, that means the feature may never be completed! (But hopefully, the product will).
- Don’t jump from feature to feature. Instead, start a feature and implement it to completion. By doing this, you’ll have product features that can be immediately deployed at the end of each of your sprints. There will be no such thing as an incomplete feature or product. Instead, a core feature is completed, which is the product. That product is then enhanced one feature at a time. It is always complete, though, at the end of each sprint.
Solutions for Poorly Architected Software
The software architecture is the blueprint for what a software product will become. Unfortunately, I’ve been finding more and more that embedded teams that have adopted Agile methodologies often have the worst software architectures. I’ve concluded that the reason for this is that Agile teams often believe that if they design their architecture upfront, they aren’t following Agile. Nothing could be further from the truth.
The first solution to poor architecture is to spend time upfront designing an architecture. A good architecture won’t magically fall into place as you bang out code. The architecture may evolve as new information is found, but the core architectural solution to the product will generally stay the same.
Next, developers need to define their goals for the architecture. You’ll discover that architecture can’t be everything! There will be trade-offs between scalability, reuse, and so forth. Teams need to define their primary goals and then build feedback into their development cycle to ensure that those goals are being met.
Another solution is for developers to adhere to SOLID design principles and explore modern software architectures. I see many teams adopt modern languages, architect a great solution, then implement a giant ball of mud. The implementation doesn’t follow the architecture! I’ve seen architectural solutions with glue thrown in, global variables and objects with no owner, and other nasty things.
Architect a good solution upfront, educate the team on the architectural principles, evolve the architecture as new information is learned, and adhere to your design principles. This will at least get you pointed in the right direction.
Solutions for Team Turnover
For any business, some level of employee turnover is expected. Team members can work at a company for a while and decide they need a change. Maybe more money, maybe a new experience, or a change of pace. Ultimately, the goal is to keep your team for as long as possible. Hiring and training are expensive, time-consuming, and can delay projects. So, what can teams do to minimize turnover? There are certainly a few immediate solutions that come to mind:
- Development teams can adopt pair programming to ensure that knowledge is not lost about a system. Pair programming can instill the software knowledge in two developers’ minds while also acting as a code review. As a result, code is not just more robust, but if one developer leaves, someone else has knowledge about those modules and can then share it will the remaining developers.
- Employees often aren’t leaving a job so much as they are leaving their boss! I can’t tell you how many people I’ve spoken with leave their jobs because their boss doesn’t provide feedback, doesn’t communicate well, lacks a vision, or is generally MIA. Sure great wages and benefits can help keep people, but turnover can be minimized by great communication and building a good company culture.
- Augment your team with consultants and contractors. This sounds a bit self-serving coming from a consultant, but hear me out. I’ve had several teams that I’ve worked with where I have mentored, trained, and advised the team. My involvement often leaves me with the knowledge that is retained, and if a team member leaves, I’m also able to help fill the knowledge gaps or pick up additional slack while new team members are brought on. It can be an interesting stopgap; after all, even the best companies and teams will have some amount of turnover.
Conclusions
The success or failure of an embedded project can be dependent on whether the silent project killers are present or absent. To be successful, we want to make sure that we minimize their presence and impact. This post explores a few potential solutions for the most prevalent project killers. The exact solutions will depend on the team and the circumstances, but I hope these help give you an idea of how to prevent them and increase your chances for success.
