The Stride Blog
Get the latest tips on agile software development so you can scale and embrace change.
Nearly every software development project starts with one question: "How much is this going to cost?" Perhaps it’s a stakeholder who asks the question: a CEO, Board member, VC, or boss. Maybe you’ve asked your team this question. Maybe you’ve asked it another way — How long will this take? Or: How many stories can we get into this next sprint? Or: What’s your velocity? Or: How many people do we need to hire to get this done? Or: How much money do I need to raise to launch an MVP for my startup?
Estimating. Can’t live with it, can’t live without it. Or can you?
Agile has been around for 13 years. That seems like enough time for companies to adapt to Agile processes and get the hang of writing Agile contracts. Yet, when it comes time for companies to enter into a contract about Agile work processes and deliverables, we're still seeing Waterfall language persist. Don’t believe me? Last week, I received a contract that had this exact phrase: “No changes will be effective unless and until memorialized in a written change order signed by both parties.” This is not an Agile-friendly statement, and these terms are not conducive to a true Agile process that would benefit both parties. So, there is clearly more work to be done from the contracting side of Agile software development. If we want to see Agile software development contracts that are truly aligned the interests of all parties involved, there are a few steps that we need to take.
Agile is often discussed as a methodology: a framework for developing software. At Stride, Agile isn’t just a process we apply to a software project; it’s how we approach both technology and business. It’s a way of thinking and behaving. It’s fundamental to what we do, both inside the code we write as well as inside all of our operational and strategic practices.
Your enterprise shouldn't just think like a startup. Act like one. Get our MVP launch guide to fix your MVP launch today.
Creating useful software is a craft. There is no black and white formula for success. Yet, there are certain Agile engineering practices that, if used thoughtfully, have shown to repeatedly add value to a business.