Beyond Scrum - Summary: The Cargo Cult of Scrum
Thursday, July 30, 2015 at 12:07PM 
During the war they saw airplanes land with lots of good materials, and they want the same thing to happen now. So they've arranged to imitate things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head like headphones and bars of bamboo sticking out like antennas—he's the controller—and they wait for the airplanes to land. They're doing everything right. The form is perfect. It looks exactly the way it looked before. But it doesn't work. No airplanes land. ~ Richard Feynman
Summing it Up
Scrum wasn't a bad thing when it started. The Internet was a new medium, Java, ASP/.Net were new platforms, and we had a long way to go and a short time to get there. I'd venture that nobody knew where software came from, and Agile arose in response to the death marches that so characterized "waterfall" development.
Well it's been 10 years and agile and Scrum have given us lots of software - all delivered but much of it staggeringly mediocre. Scrum is clearly a cult -- with certified scrum masters and the enduring belief that the software would suck less if only you could somehow have been more agile! The no true Scotsman rule applies: Scrum didn't fail you and your team -- your team failed Scrum...
Enough already. We can take the lessons that Scrum taught and evolve to a better way to deliver / offer / present not only functional but exquisite software. Let's wrap up the rest of the pieces.
The New Rules
The most basic rule of software development is that software projects are first-and-foremost projects, and the body of knowledge that we've gathered running all kinds of projects in all kinds of other disciplines needn't be left behind just because it's software. The Project Management Institute is way ahead of the curve on this, and doesn't waste words (or letters) in calling the Project Management Body of Knowledge the PMBOK. The principles here really are timeless, and while the PMI does love its own language the rest of the cult artifacts are kept at bay.
From that basis there are some other guidelines that we might follow to produce better software for this new millennium. Rather than try to spin up a new cult, let's look at the science underlying software development:- Time -- really is nature's way of keeping everything from happening all at once. If you try to give Time more meaning than that you are asking for trouble by bending the concrete to fit the abstract. The more you bend the worse-off you are, so all development is trying to focus on the smallest increments possible. The goal is then to come as nearly as possible to these ideals:
- Builds (per Spolsky) should be instantaneous at the press of a button.
- Deployment should be continuous (hello Jenkins!)
- Availability should be continuous. Stakeholders should be able to try and run "the latest" from a standard source at any point in the project.
- Checkpoints should match external milestones, not periods on the calendar. Once upon a time Sales Sonar was released by Innovadex at the American Coatings Show on a June 3. Our audience was assembled -- no other dates on the calendar mattered.
- Information -- should be universally available, subject to access and security constraints, and instantaneously available as it is needed. So:
- Software check-in happens when software passes tests and reviews -- not nightly or weekly, but continuously.
- Status and project information is available everywhere (thank you Yammer/Campfire/Basecamp/JIRA/Skype...) and updated continuously.
- Meetings take place virtually whenever they are needed -- for screen sharing, planning or status updates. Pair programming is the rule here -- the old rule of "one office per developer" may have been fine for reducing interruptions, but it's terrible for collaborative software review. Team meetings are great for human bonding and comradeship; using the morning Scrum status meeting as an attendance-check is idiotic.
- Product design updates happen continuously with requirements drafted and rolled into the project for specific checkpoints. There's no reason to try to cram Design solely into Scrum Sprint Planning meetings, and (perhaps unlike in the Chrysler Payroll days) Product Management is an organizational activity that happens continuously, not just on Sprint Planning Meeting day.
"The impossible missions are the only ones which succeed." ~ Jacques Cousteau
