My team and I are in the midst of a transition into Agile-scrum. It has been advertised to the rest of the company, and our executive management is pushing for it.
Thus far, we haven’t received any official process or reorganization to align with the vision, so we don’t have product owners, demo’s, retro’s, or discovery meetings. We still do old-school waterfall requirements documents (which by the way, everyone wants to change just now while we’re firming up testing). We joke that we’re in this purgatory of “water-scrum-fall”.
“That team has scrum meetings, so they must be Agile, right?”
I thought “water-scrum-fall” was a word we simply made up. Turns out, it’s a real thing!
I recently watched a dev talk about scaling Agile and how to properly integrate Agile-scrum in the enterprise. Sure enough, at 2:10:
It’s a real thing!!!
Wow. To see our current project structure in this diagram blew me away. I wasn’t crazy! As a younger dev, I once got reprimanded for asking about requirements documents. I now understand. BDUP (big design up front) is basically a failure from the outset. Without a product owner to be the primary gate of prioritizing work, everyone and their mother has input on what the feature “should look like”.
What this results in is a never-ending cycle of “sprints” (I use the term loosely in this context), with the work of sprint 5 modifying or undoing the work of sprint 2, so on and so forth. Without a feature-driven delivery date and rapid push to production, water-scrum-fall is less productive than either scrum or waterfall. If I chose a camp, I could just decide to never deviate from requirements, and save myself the time of a scrum meeting (which ends up evolving into just another 1-hour meeting where 12 people show up). Or perhaps I would lock stakeholders into a meeting room and refuse to let them out until they’ve prioritized a backlog for the team to accomplish a deliverable feature.
Being in the middle, as the diagram shows, I actually find less productive than going all in on either methodology.
Jez mentions value stream mapping, and that is a critical skill that any Six Sigma belt will have, but that businesses outside of manufacturing generally don’t utilize. Sure, they can define it, but they miss the point. You need to understand who your customers are, internal and external, and what their inputs are. This will be also different at a team level, so it’s important for all members to understand these concepts, just as they would be expected to understand a user story.
As he says, the lead time on a certain process may be perceived as 9 months, and people have become accustomed to ignoring it. If that’s where 80% of the delay is, focus all of your energy and cutting the red tape and getting straight to value! When you have centralized project management settings software deadlines from an armchair, you will absolutely get incorrect estimates and budget overage. Agile software is improved bit by bit, constantly re-evaluated and measured. This is also akin to how Six Sigma belts seek to achieve change in their organizations. They never aim for a massive change in one fell swoop. They expect a domino effect of smaller changes. Instinctively, they understand that impactful change happens over time, incrementally. One day you realize, “I don’t even need to do <task/feature/process> because of all the smaller improvements we’ve made to <other tasks/features/processes>.
Where then, do you begin with your improvements? The answer: low hanging fruit.
You may have heard of the 80/20 rule. This is a staple in Six Sigma. Understand that 80% of X may be caused by 20% of Y, or that 20% of your problems are impacting 80% of your performance hits. It changes the way that you use data to drive action and continuous improvement. I wouldn’t micro-optimize code without justification for a real benefit, so why would you think that having scrum meetings and calling your project phases ‘sprints’ will magically speed up development?
I hope it goes without saying that with my lean background and love of automated testing, I absolutely prefer an Agile scrum methodology, with a heavy focus on automated testability against a robust backend. If you’re a team lead or scrum master who has some power and say over how you execute your agile processes, definitely give that video a watch.