Implementing Agile Project Management: (v) Slowly revealing layers of irony in order to help everyone contribute to creating something awesome
“We have to be ‘agile!'”
This seems to be a near-universal statement today, and one that’s easily agreed upon. However, changing corporate culture- that is, actually becoming “agile”- is difficult. On more than one occasion, I’ve seen goals such as “regular/monthly releases” misperceived and distilled into comments similar to: “so you’re saying the real problem is that we don’t have hard deadlines. You there! Give the developers more deadlines! Problem solved. Lunch?”
Remember: we’re putting cover sheets on all of our TPS reports now.
At our company, we stumbled through several examples of what you could refer to as “old-school management” in our attempt to fix our delivery problem. We had harder deadlines, more micro-management, and a long list of check-offs to put the “control” back in “Quality Control.” These are the kinds of ideas that originate from well intentioned people who’ve unfortunately never seen Office Space, and unwittingly fall into the “every other big company does this, and we want to be a big company someday, so we’ll do this! Ta-da!” trap. Somehow, a “big” company’s very lack of agility never entered into the equation.
It should be noted that all these attempts to fix our process were very well intentioned, however misguided. It’s important to remember that we all want the same adjectives: better, faster, and cheaper.
So we stumbled through several ideas until we found something that actually worked- and worked for everyone: developers, managers, and upstream & downstream partners.
We modeled our whole software delivery process using Kanban. But we’ll get to that.
Just before we began transitioning to Kanban, we had a flagship product that hadn’t seen a major release in over 2 years. The releases we did have (“‘Service packs” we called them,” in my best Grandpa Simpson voice) were terrible. Sure, we added a lot of bug fixes, and in one case, a key feature to aid a new industry requirement, but they always seemed to have some ticking time bomb that was usually performance related, and always detrimental to our customers, support department, and mental health of the organization in general- including and especially, our management- the very people initially trying to fix the problem.
We were caught in this ironic cycle of wanting “agility”: management continuing to profess “we must be agile!”, and developers trying to comply while having management shift their priorities on a sometimes daily basis. Looking back, we appeared to be doing everything we could to prevent ourselves from being “agile.”
And we’re not alone.
We did this out of what appears to have been blind faith in a few key myths I’ve seen repeated over and over….
Myth #1: Software is late because there are no deadlines or developers simply don’t respect them.
This one is tough to explain if you don’t live it day-to-day as a dev, so it may take a little faith. Developers do not randomly stop working on what they’ve started – what’s assigned to them- in order to spite management or “stick it to ‘The Man.'” In my experience, the task assigned has been shuffled yet again by someone or something out of their control, but since there’s so much going on day-to-day, it’s difficult to remember that we’ve re-prioritized a single developer multiple times- sometimes within the same week!
It’s a scientific fact that 83% of all developers working behind closed doors are asleep at their keyboards. -Barney Stinson
This used to happen to our organization regularly as business demands would change and stakeholders “forget” what R&D is working on. Outside of R&D, there can be a strong perception that developers are idle and at the ready simply waiting to take on the next business priority, when, in fact, they are still struggling to complete the last task that was assigned to them.
Developers themselves are not seeking out ways to do bring inefficiency to the development process. They do this work- putting in the late hours, obsessing over details- because they love what they do. We want to create something useful and helpful for others
Don’t over think it. You do not put yourself through 4 years of linked-lists and data structures, or teach yourself some foreign language an-hour-a-night, if you do not absolutely fawn over this stuff. It’s damn fun to be a programmer, and it’s even more fun when requirements, process, and success are clearly defined.
This myth is a defense mechanism by management who are unable or unwilling to accept that they haven’t fixed the problem. “Oh, it must be the dev’s fault- they’re just lazy.”
Myth #2: Developers are not producing code efficiently
“OK, we admit they can focus on their work if we let them, but how can we be certain that they are producing this work efficiently?”
I got this question the other day and I’ll admit, it threw me for a loop. My only response was, “I wish I had that problem! I wish my problems were so solved, that I had developers focused on one thing at a time, a visualized software delivery pipeline, and 100% code coverage, that I could simply obsess over how ‘efficient’ a developer was.”
My response was perhaps a bit melodramatic, but I wanted to illustrate a point. Inefficiency in team production is not a team problem.
It’s a management problem.
To examine this, I’ll set aside for a moment how we define “efficiency” in software development as this word is exclusively used by people who’ve never programmed.
Production Support Team photo taken for this blog post
In our shop, we have some of our developers share the responsibility of doing “Production Support.” You know the work, the type that takes saints to wade through hours of debug output over a series of days working one-on-one with that single customer that has that obscure window sizing problem on every 3rd Sunday with Windows XP but only when the extended language pack is installed.
We also expect these guys to deliver new features, because, as it turns out, they are pretty freaking talented, so we’d be wasting our resources not having them develop new features, right?
Well, sort of.
What ends up happening is that they get a few hours into Super-Cool-Feature-X, then get derailed for the rest of the day on a production problem. The next day begins, and the cycle repeats.
Developers need focus time for a several, really, well-documented, reasons. This is not news. Add to that a never-ending supply of ankle-biting, time sucking, research-intensive tasks with ever changing priorities and you’ve got yourself a recipe for inefficiency! Still, like many, I found myself answering more than my fair share of questions on why Super-Cool-Feature-X wasn’t done yet and this was my response every time:
Our problem is not inefficiency in the developer; it’s inefficiency in the process.
If you have the luxury of a perfect process with little to no waste, congratulations. Now stop patting yourself on the back; you’re either lying to yourself or stagnating. Just ask these guys.
You want developer efficiency? Start focusing on hiring and retaining really smart people who get things done. Period. An experienced and/or talented programmer is not slightly more productive than your average programmer, they’re dramatically more productive (read: more profitable!).
Your core product as a development team or an ISV is intellectual property. The more innovative and creative that IP, the better your company will be, the faster your time to market will be, and the lower your expenses will be, relative to your competition (cheaper!). Don’t over think it.
Myth #3: The process is broken because it’s not being actively managed
We lamented over our inability to be “agile” and at the quality of our bloated, shitty releases. Then a light bulb struck: the reason we weren’t releasing quality products was because no one was micromanaging the process! Left to their own devices, the thinking went, our team would naturally crank out sub-par features because they’re not being managed. The problem must be that management is not telling them to produce better code.
OK, to be fair, I am over-simplifying for effect, but this plays itself out in very real situations regularly. Our most recent example was the solution to quality….
Yeah? And what’ve we got on this thing? A CUISINART?!
We created a checklist. Our answer to “we want to be agile” was to create a checklist that barely fit on entire sheet of paper- for a team of about 6 people. Our justification for this was that it works for manufacturing and manufacturers have quality control that observes a check list, so since producing software is just like manufacturing a washing machine or a Cuisinart, we’ll create a checklist. If a washing machine producer can quantify every part that goes into a washing machine, then by-golly, we can quantify everything that needs to be done to QC shiny new code, voila! <image: checklist, reduced size>
A more pragmatic justification for the release checklist would probably be the studies that found that the single greatest contribution to flight safety was- any guesses? A pre-flight checklist.
Our process wasn’t broken for lack of management, it was broken for lack of process.
It’s at this point that I now sat, recently promoted to “development manager” to “fix” our product, improve communication between the R&D “black box” and management, and to make our process more agile. All things I had asked for, now it was time to put up or shut up.
If I can make this work, you can too.
More to come in Part 2… De-myth-tifying.