TL;DR
- Fixing 2 major waterfall habits will greatly improve your Scrum success.
- Flexible contracts provide better outcomes for your business, employees, and customer.
- Iterative end-user delivery, or flexible requirements will pave the way to success.
When problems arise, I don’t want to just fix the aftermath of the problem, I strive to fix the root of it. With this in mind, I’ve seen 2 major systemic problems in Scrum adoption that force Scrum to fail. This often happens when Scrum is used as a thin veil over a waterfall setup. You’ve probably seen this happen, or are managing it now. Businesses choose to use only the events and artifacts of Scrum, while it’s truly guided by the waterfall. This is fine for a transition period, but offers little improvement over the long-term. The value earned is often the same employee burnout, lack of ability to handle change, and reduced ability to handle risk. Since you may now ask, "why adopt Scrum at all?" I’ll give a brief overview of benefits.
Proper Scrum setup provides...
- a graceful way to handle your customer/user’s changed needs over the project
- faster time to market, and real market validation
- stress reduction at all levels of the project
- higher skilled talent, and retention of talent
- adoption of discovered innovations/needs that would otherwise have been missed
- increased customer relationships and buy-in.
If you don’t need these things, then you don’t need Scrum. Beware that waterfall simply cannot provide these benefits in the graceful way that Scrum does. That said, here are 2 major systemic waterfall habits that must be fixed for your successful Scrum adoption.
The Root Cause May Be Your Contracts
When I see a project with an improper Scrum implementation, I immediately go back to the contract. Scrum handles change gracefully, but at the root, it must be supported by the contract. The bane of Scrum’s existence is the fixed price contract. If your contract has a firm budget, and a firm full-features date, you’ll fail to gain the benefits of Scrum.A non-fixed price contract will be the firmament upon which the Scrum framework needs to do its work properly. Although the idea can be a challenge for traditional businesses and customers to embrace, once they do, they find a completely different world of development based upon true accountability, trust, and quality of service.
What’s keeping your organization/customers from embracing Scrum and the non-fixed price contract? Most likely, what's needed is an exposure to, and an education of the way work can be done iteratively. Done well, Scrum will bring strong coupling between the business, customer, and end users, operating nearly as a single organ with a purpose. It just takes the right knowledge and guidance.
Contract Risk
Using contracts that aren’t fixed price can place risk on the seller. It may allow the customer to back out before the entire product is complete. However, many contracts already have a clause which allows a customer to pull out early if quality standards aren’t met. An iterative contract is not much different, and there are ways to structure a contract to reduce this risk, while also keeping the customer happy.Once you have teams that have worked on a project and know their velocity, there are opportunities to use fixed price contracts, but there are also caveats for the Scrum Master and Product Owner to consider, before doing this.
The Full-Feature Release Date
Secondly, successful Scrum adoption must have either a flexible feature list, or a flexible release date/release chain. Without one of these, Scrum won’t have the portability to become the most valuable, and mangeable product it can be.Your MVP is your MVP
When planning for a flexible feature set or iterative market delivery, know your minimum viable product (MVP). Minimum is the keyword here.- Contains a small feature set.
- Minimal (but stable) operable capability.
- Can be deployed with stability on all initial platforms.
- Preferably deployed by the Dev Team.
Plan for Iterative End User Release
When your end user’s release expectation matches your production process, this is ideal. Iterative delivery is also an industry standard now, with only a few industries still holding onto the release-all-at-once cycle. If you're in a large release industry, examine why large release cycles are still being held onto. Customer absorption and adoption of updates are concerns to take into consideration, but there are so many more benefits to an iterative release cycle.Build for the minimum viable product, and plan to add updates after launch. Launching early with fewer features is better for quality, too. You must release a stable, “bug free” product, but you can’t hire enough testers to find the type of issues that your end users will find. Releasing a smaller, fully tested product early makes unforeseen user reported bugs easier to triage (and re-release) than with a larger feature set that's full of dependencies to work around.
Flexible Final Feature Sets
Change happens in every project. If you have a firm date where all features must be released at once, work out a way to use a flexible feature set. Again, knowing your MVP (minimum viable product) is critical here. Prioritize your features in a way that leaves room for the least necessary features to fall off when unexpected changes, or better ideas occur.To be clear, there are many more reasons why Scrum adoption may not be working yet for a business, but a good Scrum Master will help identify, mitigate, and correct those issues. What I listed here are the 2 main waterfall habits that most businesses overlook, and how to navigate those waters for project success.
