The dangers of a scrum environment

Scrum

To the uninitiated, scrum is an agile development model that focuses on short term development periods called sprints. If you can't fit a task within a sprint, then that task needs to be split up into subtasks so those may fit. You define what you're going to do each day and commit to it. After each sprint, you're supposed to have something deliverable. In software, that translates to a deliverable program at the end of every sprint with added features and bug fixes. A caveat to this is the adherence to using the items assigned each sprint as documentation.

Let me just say this as clearly as possible: any piece of software undocumented may as well not exist

Scrum provides a nice bubble to work in, and protects you from the outside world. It protects you from executives standing over your shoulder dictating what to do because there are established channels to go through to maintain a solid velocity. Oh, you might be traveling at a terrific velocity, but if you don't know where you're going in the end, you're most likely going in the wrong direction.

Scrum is supposed to take this into account. After every sprint, you are supposed to reassess, make corrections, and proceed to the end goal.

What if you don't know what the end goal is?

A practitioner shouldn't need worry about the end goal. A product owner who tells the developers what to do is supposed to know the end goal, but this isn't always the case. In an ideal situation, the owner will have this grand plan and gracefully navigates you there all the while making subtle fine tuning adjustments along the way. That's where the dangers show their little gremlin faces. What if the product owner doesn't completely understand what's the end goal?

I'll explain it in a slightly different way. I'm not referring to an incompetent product owner, but one that isn't the grand visionary that oversees everything start to finish. This can happen when an owner comes in mid-development, so it's a highly likely scenario for long-term projects. In the event an owner arrives late, how are they to catch up to speed on what's there? That's where documentation comes in. You should have something readily available that can bring anybody up to speed be it a new product owner, a new developer, a new customer support person, or even an executive.

Scrum doesn't force this documentation to be done because you're supposed to use the development history as your documentation. If anybody who's worked on a project where the issue tracker is the documentation can attest to, it's that it doesn't work. Rarely, do people actually write detailed descriptions of features they want that includes the headlights, chrome, and all the gadgets and gizmos with wiring diagrams included. What usually happens is somebody says, "I want to be able to do X, Y, Z" and that's it. They'll explain it a little bit, but not much more. After you finish that feature, you have bugs, then enhancements to the feature, then bugs for the enhancements, then bugs for the two working together, and you wind up with something that's a completely different from what was originally ordered. This happens everyday everywhere.

Perfect storm

I recently ran into the perfect storm of events that caused scrum to completely fracture. The project was to unify multiple applications together so the goal was to have a replication of the current system then the company was acquired, the executives transitioned out, the teams were in flux, the manager who oversaw all of the old system's development departed, the product owner changed hands, and we were tasked with continuing on with business as usual.

Normally, this would be good except for that pesky goal we're striving for. Scope is important, managers are supposed to have the long term direction, team leads a mid term direction, and developers the short term direction. Sometimes, when laying down track, you need to just know which way to point it, so you ask. When asked where are we going, nobody knew. It was a hot potato subject that everybody wanted to pass off. Most of the parts in the old system were trivially simple to understand, but custom calculations were another beast entirely.

Custom calculations

This product has two faces, a public one where clients enter prices for things, and an internal one used by the customer support center. The calculations seemed pretty simple because they were described by the former manager prior to their departure, and even somewhat implemented, but like everything, there was a bug. That bug was simple to track down, but left an unnerving feeling in the end. A custom calculation was being applied twice, but in different points in the pipeline. The fix is simple, figure out which is correct and go down that path. There was no documentation dictating expected behavior in the calculations. They were just magic boxes of fairy dust people shoot and got an answer out of. No developer knew the correct solution, and nobody that should have known did. When asked by the new product owner, they didn't know because they didn't know what the previous system did; there wasn't any documentation to help them. The solution was to reverse engineer the old system's way of doing things, but that left far too much up in the air. When examining the code, everything looked wrong. There looked like patch after patch after patch, and nothing functioned the way everybody thought it was to function. This was no longer a "pick a direction", but a question if the old system was even functioning correctly. So that leaves a sticky situation, and one that requires asking the people who use it for help.

What happens when the people who use something commonly use it for something else because it's broken? You wind up with an undocumented mess. I asked the customer support personnel for information on how the calculations work, and they responded with documentation, documentation that was wrong and horribly outdated. They didn't use the documentation because nothing worked as expected so had to rely on individual domain knowledge. When going through training, they were instructed to "ignore what it says and do this instead" so any documentation ever written was obsolete. The company outgrew its software and nobody really saw it because they were so focused on completing sprints and velocity to crank out new completion points that they never took a step back to look or slow down to document their changes. They just trudged ahead blindly to the world. As the former manager would say, "All we do is win, no matter what". Sadly, winning lead to losing dearly. The entire calculations system is having to be completely revamped and overhauled because of the shortsightedness, and it will be documented by both those who develop it and by those who use it.

Solution

Scrum isn't at fault so much as the abuse of the practice was. Scrum doesn't mean to not document. It is designed for continuous releases, and you need to include documentation with the development. If you create a feature, update the documentation explaining what it does. If you're enhancing a feature, include in the requirements for the enhancement to be declared complete to update the documentation. Your velocity may appear to slow down, but it avoids the tangled mess that a company would have to deal with later. It's the same reason to design and architect properly to avoid a tangled mess of spaghetti code for a program. It's better to quickly document early instead of have someone spend months trying to debug, decipher, and reverse engineer a broken product.