Partners
Have you ever started a project only to realize half-way in that it is much more complicated than what you originally thought? And that it would take twice as long? And that it would need collaboration from 3 different teams because it touches their codebase as well? You’re not alone!
Software engineers across various organizations have run into this same issue - but what’s the solution? Is it Big Design Up Front? Is it to be “agile” and let these things happen? OR ....... is there a better way, by which you can do *some* upfront work and save yourself a lot of thrash and a future headache. This process is usually called a spike, wherein the engineer(s) leading a project dive deep into figuring out the unknowns of a project before it begins. In this talk, I’ll go over what a spike is, how to successfully spike a project, and lessons that I’ve learned from leading several technically complex projects, across 3 different companies, and various different teams.
Key Takeaways:
- How to evaluate whether you need a spike or not.
- How to come up with the right assumptions you could validate/invalidate before writing the tech spec.
- How to find the technical scope of a project (Teams, Services, Key Stakeholders) that’d need to be involved.
.png)
 (1).png)
.png)
.png)
