Mark works as a developer for a company that’s agile. It says so on their website, job ads, company blog, all the press announcements — they even have a poster of the agile cycle, right between the “There’s no I in Teamwork” and “True leaders don’t create followers” posters.
It all started a couple of months ago, when one of the executives (that happens to be Mark’s Productivity Chief Officer) talked to one of the developers on his team about Agile and then did some bedtime Wikipedia skimming.
Because project management texts tend to be vague and abstract, the only message he got was that agile is the silver bullet for all kinds of problems in software development: bad estimates, bugs, overdue tasks, overtime, ambiguous requirements, console errors, grumpy clients, Internet Explorer, global warming, etc.
“Stop the press! Imagine all the profit if we tried this new, exciting concept they call Agile”.
So the next day, everyone — including Mark, our young budding developer — gather for a big company announcement. A grand speech is made, visions are shared, and there’s a palpable excitement in the air. A new era is ahead and everyone will benefit.
All the managers are invited to a meeting and are told to embrace Agile software development. For more information, they were kindly asked to consult the internet. After an afternoon of some light reading (and searching images on Google), each manager gathered their team and shared their working understanding of the Agile concept.
Some focused on the continuous release part:
Let’s just divide our tasks into smaller chunks and ship every week. Imagine how delighted our clients will be when we make them update their entire system just so Janice from accounting can send an invoice in one less click.
Some focused on the listen and learn part:
Let’s visit our client and make them go through thousands of usability tests. Then, let’s look at all the data, laugh at how they can’t use our product, and advise them to focus on employee education. After all, our design is perfect, just look at our client list and our diplomas.
Some didn’t leave any wiggle room and opted for the best:
We’ll hire consultants, implement the Scaled Agile Framework® and a bunch of others certified tools and processes, buy a bookshelf (for all the books that we just ordered from Amazon), send everyone to a short but intense training, and do some re-engineering so we accomplish more with less. Then we’ll win an award and be rockstars.
The result — different teams with different aspirations in life, each employing one aspect of agile but not all because it’s just not in line with how they’re used to doing things. They’re used to doing things a certain way because it works, and you don’t ask why. It’s against the company culture.
Plus, who’s going to update all the document requirements, job assessment forms, policies, and regulations? It’s easier to make small tweaks and call it a day. This way you get the best of both worlds: you get to sound hip and use words like agile, and not waste time on actually changing anything. It’s a win-win.
Now Mark, our bright developer with a head full of dreams — he has developer friends. Developers talk among each other about things other than how DateTime class works in different languages. He hears how some companies don’t broadcast how they’re Agile, that not a single person has a certificate or formal training — and they still generate good profit and people are happy at their jobs.
They let Mark in on a dirty little secret — it’s not about the workflow, the process, or the latest trend — it’s about the client. Make sure you understand your client’s needs and solve them.
First, he thought to himself how those are just a bunch of empty platitudes, but then he considered the current situation at the office: no one really knows the clients. They are referred to as “the user”, “the accounting”, “the administration”, “the management”, or some other vague, unfortunate persona that has no choice but to use their custom made software.
So Mark races to the corporate headquarters to share his revelation. He’s received as a part of company’s open kimono policy and invited to take a seat in a lazy bag. The manager thanks Mark for reaching out and going the extra mile, then goes on something about blue skies and peeling the onion. Mark is not very good at metaphors so he skirts the subject and starts talking about how everyone focuses on the process, and not on solving problems for their clients.
The manager nods in agreement, but his one eye is on his smartwatch and the other on email while calculating the interest rate of his student loan in his head. He thanks Mark for his time and tell he’ll look into the matter.
The next day, Mark gets an assignment to work on writing the spec and no one hears of him ever again. Some say he went mad trying to fit the neverending, changing requirements into the existing architecture trying to preserve design’s purity; others say he just gave up as no one ever reads the spec, and decided to spend the rest of his life on the company’s rooftop, arguing whether developers should learn C.
