ASAP Driven Development

Today, I want to talk about the term we made up in times when we believed that it described the way we work: ASAP Driven Development (ASAPDD). Sadly the term As Soon As Possible is abused. It should mean that "whenever you have free resources", but it's commonly misinterpreted as "now".

If I'd to place it in the context of Agile, I would derive it from Kanban with one slight modification: the task you're working on is only important until the next task's priority doesn't exceed the current one's. In extreme cases where business is completely aware of what the costs of switching tasks without finishing them are, it might work. But in cases which I've seen, the stakeholders didn't even know that this is happening. Even more, the task switch didn't mean that you don't have to finish the one you just put behind. That's still top priority, but the new one is even more important. It took me quite a lot of time to truly understand what is going on, I'll drive you through my observations.

Symptoms:

If I had to describe the symptoms in one word, I'd say: pain. What hurts in ASAPDD gone terribly wrong? As a developer, you never know how much time you have before you're forced to work on something else. If you don't know how much time you have, you have to finish as soon as possible - meaning the simplest and fastest possible way, while ignoring all professional needs - in order to flag something finished. If you can't finish before you receive a new task, then you'll have 2 tasks on you to finish ASAP, and so on, and so on. Of course you can say no to a new task, but that would leave you without a job. Given this situation if you know that you most likely have to put your style, cleanness and reputation aside to do your everyday job, it hurts and undermines your motivation ... if you care about such things of course.
But what about managers? I had the luck to be a manager in such environment too. You're told by your superior that the stakeholders do not care, and you can't communicate negative things towards them. You're told that whatever they want, is to be done. Given this, you have to promise that you'll get the task done, and you must tell the same to the developers resulting in a new 'top priority issue'. You'll say that this is even more urgent than the others. If not, the other tasks then must be completed by yesterday in order to get work done on the new one. What happens when the programmers raise their flags about a task and you tend to agree with them? You'll end up as a messenger between sides, but you can't be truly honest with the product side, and you'll have to convince the team to be passive-aggressive and do as they are told. You can try to defend your team against insane requirements, but say hello to bonuses and appreciation. You'll be the guy who always says no and argues, while there's the other ones who understand the tasks and get them done. This is a true enemy to creativity and innovation. As you might guessed, the side-effect of such "pain" is fluctuation. People get under-motivated, fed up, exhausted, laid off or they just simply quit.

Cause:

I tired really hard to understand what's going on, so that I could do things to fix it in my own circle of influence. Clearly there was a crack in the flow of communication. But why? Whenever top management or the product team came up with something, they were hardly told that it can't be done, or can't be done in a week, or simply that they should come up with smaller chunks of functionality. They believed that when they feed the development team any input, they get the output they wanted in a short period of time without any further interactions. Nobody said truly no to them in order to properly schedule or break apart a task. Nobody communicated the need to finalize, stabilize previous features. If they were demoable, they were done. Even if someone did say no, then the top management came and pushed the feature into development regardless the raised flags. Inspecting the pain from the bottom, I saw that even if we told our managers that we can't do something or that we think it wouldn't be any good to the product at all, they pushed it on us without defending our professional opinion. Even if our managers did try to defend us, their superiors denied help. Even if the superiors tried to help, the CTO wanted to impress the CEO so much, that he didn't help. Even if the CTO was convinced, the CEO was the one who seemed to have no common sense. Finally if even he thought that we're in trouble, the solution was to "hire more resources", 'cause the feature is so important, that it must be done. So as the previous ones. I couldn't blame the CEO though, he was hardly ever aware of the fact that we're having hard times completing tasks. Why should he even think that hiring more people isn't the cure? He thought, that everything is going smoothly and that our throughput is influenced by the number of people working. I'd say he wasn't respected enough, and he was constantly lied to.
Anyways, how could a feature be so important that it needs instant development? Well, the sales made an insane promise and the money's already spent on shiny new golf clubs? Or did a newsflash somehow got public weeks before planned describing nice new features which didn't even get into development? Or simply nobody knew that we were not remotely ready with our current work. Whatever the reason is, the managers and the developers had to fix someone else's mistake. Mostly.

Cure:

Why mostly? Because we as developers should have stood up for ourselves and defend our own beliefs, profession and credibility. We were too afraid that we could lose our jobs. So what could have been done? Honesty, respect, professionalism and metrics. Clearly it's much easier said than done, but let's see what we could have done from both sides.
We should have increased transparency by radiating the metrics of our codebase. Telling everyone from top to bottom, that our codebase is rotting, and if we won't have time to properly code a feature, the time we'll spend on each following task will exponentially increase. We could have told our superiors, that if they want to keep a sustainable development, we should start caring about the health of our product. If we could get our product and top management team to hear us out and try to accept that we must re-calibrate our workflow, we might end up in an adaptive system such as Kanban, so that they could re-prioritize the upcoming tasks until the very last minute. If instead of staying quiet we would respect our co-workers by telling the truth and giving honest feedback, we would give our managers / leaders the ability to think of a solution instead of leaving them in a belief that everything is fine. I'm sure that they would try to make their own company work at any cost... if they knew what to fix. Maybe we could have even helped them by providing various solutions they could choose from? Ranting never helps without providing a possible solution to the problem.
What's to be done with the sales / marketing guru who constantly screws up and ignites new ASAP developments? Help him out! Find out why he's doing such stupid things. Does he even know he's not doing well? Does he get any feedback, or just the premium after each deal? I even know that the product team sometimes needs to test an idea and see if it's viable or not. They can use the main development team to rapidly build things, but instead of burning tons of $ on coding man-hour, try to do a paper mockup and invite a control group. It's less expensive, and gets you much closer to your customers. What happens when a rapidly developed idea doesn't work out? The programmers have to revert weeks/months of work. No matter what methodology you follow, that always introduces motivation loss.
To wrap it all up, I don't say you need to change organizational structure to avoid ASAPDD. Just be honest and make sure people would want to be honest with you. Accept feedback even if it's negative, and think of it as a candidate to making things better. You won't get a negative feedback unless the one who provides it doesn't believe that you can do something about it.

Literature and help

• [book] Agile Retrospectives: Making Good Teams Great
• [book] Management 3.0: Leading Agile Developers, Developing Agile Leaders
• [book] Kanban and Scrum - making the most of both
• [book] User Stories Applied: For Agile Software Development
• [book] Kanban: Successful Evolutionary Change for Your Technology Business
• [book] The Clean Coder: A Code of Conduct for Professional Programmers
• [google group] Lonely Coaches Sodality