How do you know she’s a witch?

She looks like one! So begins one of my favourite skits in movie history, the witch scene from Monty Python and Holy Grail. The gist of it is: If she weighs the same as a duck then she’s made of wood and therefore… A witch! And what do we do with witches?  We teach them Agile!

What do witch hunts have to do with software development? Plenty.

How do you know you’re really “doing Agile” or following Scrum practices in your project? How do you know if you’re doing the right thing or not? How do you know when it’s done? How do you measure success? Why is the sky blue?

All of these questions come up when things start going sideways in the Agile sense, and you fall into the Scrummerfall way of doing things. Practicing traditional Waterfall management techniques but calling it Scrum. Tasks are assigned to people rather than claimed by owners. Customers are non-existent and uncommitted. And the team really doesn’t know what they’re delivering or why, they just keep doing stuff to stay busy because the PM tells them to.

Brad Wilson describes Scrummerfall as the way to ensure failure at a much faster rate than you had with Waterfall alone. There are some clear signs you’re on a slippery slope and if you see them, you should grab hold of something (preferably a pair of coconuts) and find yourself a swallow (African or European – your choice).

Three key things that you can bank on in Scrum:

• The practice regularly delivers business value
• The team is frequently aligned with the business requirements
• The business drives the project based on their needs and values

There are other elements of Scrum here but I like to highlight these ones as they’re not bogged down in techno-babble terms that nobody understands.

Delivering Business Value in a Predictable Way

A sure sign of Scrummerfall is having a schedule that follows some mythical Gantt chart or Waterfall-ish schedule that’s about delivering “phases” or “stages” of the product. Waterfall PMs will plaster these on the wall, attach them in monthly reports, and bring them to sprint reviews to show the customer “how well we’re doing”. How well you’re doing in an Agile project is measured by the business value you deliver and that can only be determined by your customer, not IT. Regular sprints of fixed lengths creates that predictability that is often missing in Waterfall projects where milestones keep slipping because of uncertainty with features that were estimated and planned months previously. If your team demonstrates value-added features at the end of your sprint and the business is on board to move to the next one, then you’re doing something right. And you’ll be hopefully able to more accurately predict the level of effort next time around.

The Business Requirement Alignment Shuffle

Requirements and business users change their minds. Especially after seeing results. It’s human nature. How many times have you brought that “perfect” tapestry home only to have your wife say “No, now that I see it on our castle wall it’s just not right. I want a shrubbery”. System solutions are the same thing and that’s fine. After a sprint ends, the business has every right; nay the privilege; to say what’s in or out next sprint. And heck they may even introduce brand new features as they see the system take hold and start dreaming up new stuff. This is *not* scope creep. It’s manageable expectations that are agreed upon by everyone once they understand the depth of the requirement.

The Scrummerfall bing-bong alarm will go off if you’re in your 3rd day of the sprint and the PM starts picking and choosing from “other items” in the product backlog, substituting them in because of impediments. Avoid this at all costs. Features are not interchangeable like Lego. Even stories with the same number of points doesn’t mean it’s the same size. In situations where you’re not using story points or any kind of measurement system of feature/story size you’re in Scrummerfall land and cannot, under any circumstances, play the shell game with yet-to-be-determined-features.

Business Driven

In Scrum, the business drives the project by prioritization and commitment in order to help the entire team achieve some business value (which down the road should equate to some ROI). In Scrummerfall, the business just says “you pick what you need to do, propeller-heads, we really don’t care and will do our thing, you do yours”. A customer who’s not committed to the process but demands the project succeeds is an impediment. I think the biggest success factors in any Agile project is a fluid customer involvement. If you’re not engaging your customer, for whatever reason, then correcting that is Step #1 to success. IT cannot make business decisions. I’ve been on projects where we did, against my advice but forced by the PM, and when the client finally crawled out of whatever rock they were under, they took one look at the assumptions we made and blew 2 weeks worth of a teams work out of the water. Again, the powers that be, who only read Scrummerfall monthly reports, will chalk this up to Agile failure and blame Scrum.

Engage the customer. They may not always be right, but, like any engagement, it’s a courtship and a democracy, not a dictatorship. There may need to be some hand holding at first and you might have to wade into the pool with them step by step, but it’s for the greater of the entire team and success of the project to do so. Or you could take the Scrummerfall approach and just push them off the cliff hoping they know how to swim (and maybe tossing them a life preserver if you’re really feeling generous).

Peter Schuh has a great article here on 7 simple steps to go Agile without going extreme. It’s more geared for the nerds and developers, but there’s a great tip in a section called “Identify and collaborate with your customer”. That’s what this is all about.

Know the Signs

Knowing is half the battle and if you sense you’re on the slippage towards Scrummerfall (or are already knee deep in it) it’s time to sink or swim. Step back and get everyone involved to help identify what’s not working. If need be, stop the project and regroup. It might be to get some level of understanding in the requirements (or even the problem that you’re trying to solve) or get resources on track or whatever. PMs and other manager-types around the world are saying “Warning, warning, danger Will Robinson. We can’t afford to stop this project”. Frankly, you can’t afford *not* to stop it for a few days or a week at most. The entire team won’t be running flat out during this time but when things get back on track, the team should be better off. Don’t let this technological terror manage you and keep driving down the road with nobody at the wheel just to satisfy some planned delivery date. While you can screw around for the next few months/years on the project (and hey, some firms have all the fun because of unlimited funds) there’s little value in just doing stuff to keep busy.

Adoption is a two way street and sometimes you’re going to face killer bunnies and sorcerers named Tim. It’s not pretty sometimes but Agile is about adaptability. Humans adapt well to their environment so should projects adapt well to theirs. If you’re setting out to change the world in one fell swoop, stop kidding yourself and be a little more pragmatic. If however you’re looking for a few small wins to move inches closer to an Agile approach to project delivery, it’s an attainable result given some realistic goals. Know your audience and your environment and play nice with the other kids.

Waterfall is still valid today. Document, design, test, are all still there in every project. Practicing Scrummers (is that a word?) just do it in a different sequence.

A bit of a side tangent. When I’m mentoring people on development, specifically refactoring, we do the refactoring manually and by the book. It’s painful in this day and age but it’s done for a reason, to help understand the meaning behind the refactoring and what each step of say an extract method is doing (and more importantly, why). After that, we can pull out the copy of ReSharper and accomplish the same refactorings with 1 or 2 keystrokes. I see Scrum the same way. Implement it by the book at least the first few times. Get into it, understand it and prove that it works. *Then* tweak it and massage it to better fit into your organization and how things may have been done in the past, perhaps grafting PMO processes, reports, and budget tracking into it.

I don’t believe for a second that any organization out there can say “We’re doing Scrum everyone, pack up your PMI certifications and get rid of those silly monthly reports, we’re *Agile* now!” and drop everything. Even after learning and practicing it, they come to an understanding of what works and what doesn’t. If the team is geographically divided (with some members in different time zones for example) it’s impractical to have 8:30 AM stand-ups every day with everyone. Adjust to what makes sense to everyone.

Agile is about adaptation and it can adjust itself quite well because it doesn’t follow strict rigorous policies that need to be approved by a committee and signed off by 15 heads of state before it can be followed. The Scrum approach is much like a morning brunch in a Dim Sum restaurant. You pick and choose what you like and ignore the chicken feet, no matter how appealing they may look like.

It’s about what works for the team and the team has to discover that with practice and experience. If you only implement one or two practices (say daily stand-ups and a product/sprint backlog) and they work for you not against you, then good for you! You’ve taken your first step. However it needs a fighting chance to start. Wedging Scrum (or any Agile practice) in where it doesn’t belong is a bad practice in anyone’s books and not the fault of the process but the person trying to force it in. Don’t blame Scrum for bad choices you make.

At the end of the day, whatever methodology, practice, or process you follow it needs to be backed by the new-but-old methodology, Common Sense. Agile is a powerful tool but not a religion. Scrum can be tailored for your needs, but you need to be able to identify those needs first before trying to apply any practice against them. Again, Common Sense reigns supreme here. There is no end-all methodology that will save any project from the depths of Hell. It’s the ability to identify, use, and adapt pieces of Agile that will help you to the end goal.