Let’s take our definitions of waterfall-agile scrum workflows and incorporate them into the P2P process. Part 1 of “Defining Waterfall-Scrum Workflows for Your P2P Process” introduced one facet of the P2P process–invoice cost–and gave a brief overview of what each of the waterfall and agile (scrum) workflows were separately and how to think of them as a hybrid workflow that complements your chosen BPI solutions.
Workflow Change as a Complement to P2P Processes
FOCUS: Waterfall–Operating in a Sequential Silo
Waterfalls flow down. They can’t help themselves, they have to follow the law of gravity. The traditional waterfall workflow works the same way. You can’t go to the next phase unless you have an understanding of what must be accomplished in the current phase.
It’s like a math story problem: to find the answer, draw a picture of what you know and what you don’t know, design an equation or set of equations based on that knowledge. Do the math. Integrate the answers back into the original equations to test if the math is correct; and if so, consider the story problem solved.
Deploy the problem back to the teacher for the final yeah or nay. If you’re like many people, this process can take quite a while to accomplish. It can also be quite frustrating. If you have a P2P problem with a waterfall workflow, any iteration throws a wrench into the works costing manpower and money.
That’s waterfall in a nutshell. Any change must go through company procedure, signatures, documentation. It follows a sequence or a set of rules.
Waterfall workflows tend toward traditional project management. That project manager’s in charge of taking the project team from planning to execution on schedule, on budget, according to the project scope–most often operating in a silo. Scrum takes that set of rules and gears them toward product management.
FOCUS: Scrum–Managing Products That Segue Into Stories
Scrum is a subset of Agile principles, its manifesto. It’s a “gestell” or framework. It’s arguably the most popular framework within the Agile workflow. Here are four key values that differ scrum from waterfall:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Subjectivity feeds scrum. Requirements creep reprioritizes. It can be tough for those involved in the supply chain to understand how agile scrum can benefit their products.
So does scrum follow traditional project management principles like waterfall?
Both must be very organized from the get-go, just in different ways. Waterfall organization and communication doesn’t follow the path of least resistance. Scrum iterations follow the traditional discover, plan, build, review; however, each iteration follows who, what, where, why and how meetings guided by a scrum framework further guided by a scrum master and scrum product owner.
The team can change-up on a dime, restarting project iterations toward the final goal. Communication doesn’t operate in a silo like waterfall. Scrum operates in a principled, go-with-the-flow, change-what’s-needed-with-no-delay segue.
So Is There Workflow Compatibility?
Again, it seems at first glance that the disjointed paths of both workflows create oppositional methodologies that don’t immediately seem reconcilable–especially in a P2P environment that utilizes BPI solutions with their ERP.
This makes the assumption that the waterfall and scrum workflows aren’t compatible. Perhaps a new perspective’s in order. Instead of taking each at face value, ask yourself what value each type of workflow can add to your P2P process.
“Is scrum structured enough to be an asset to waterfall’s by-the-book workflow?”
“Can waterfall adapt to scrum’s flexibility enough not to frustrate scrum’s workflow?”
Let’s say that you have a “red flag” project–finding out why your long-time supplier has suddenly upped the price of a rare metal extracted from tungsten. Your job is to put together a team, based on discipline, that will quickly:
- Discern what the scope, schedule and budget of the project is. Remember that scrum scope won’t be as detailed or set in stone as waterfall. The details evolve within scrum iterations.
- Plan what workflow will best facilitate the project holistically. Do you need a project manager or a scrum master? It’s this planning phase that sets the tone for the coexistence of both workflows. It’s imperative that each team member understands the difference between the waterfall and the scrum workflows and each team member’s role in the project’s iterations. What individual or team members will take the lead in determining why the supplier pricing is suddenly skyrocketing?
- Scrum daily build meetings and sprint review meetings should be integrated into the waterfall workflow through to the next iteration. Adaptation within both workflows is key. Be a minimalist. Be flexible.
- Don’t let customers (suppliers) rule the roost. Train customers regarding scrum if needed and how it fits into traditional workflows. Move forward keeping customer quality and value number one.
It seems easier to integrate scrum into a waterfall context, rather than waterfall to scrum, making waterfall-scrum collaborations more agile than you might think. It’s worth a second glance, especially for small-to-medium sized projects. It doesn’t have to be a marathon or a sprint, either-or proposition.
Using BPI Solutions such as iBundle SRI (iApprove, iPurchase, iManagePOs and iVoucher) along with your chosen workflow saves time and money while breathing new life into old processes. Contact us for solutions that fit your workflow.
