Fucking hell, where do I begin?
I had an interview a while back with the head of the company's IT department, really nice guy. At one point he asked what I meant when I said that I had recently worked in an Agile hybrid team. So I explained what a hybrid team is… pretty straightforward, it’s a team that (follow me on this) is a hybrid between traditional and Agile methodologies. It’s a hard fucking concept to understand, I know.
“That’s not Agile,” he says.
“Correct, it’s Agile hybrid.”
He didn’t appreciate the response. You see, he teaches Agile and Scrum courses at the local IT bootcamp center.
I continue, “although, if we are being honest, no one is true Agile. Everyone is going to alter the methodology to fit their needs, it’s how project management works.”
“Ok," he says, "what other methodologies are there other than Agile, that you used?”
I decided to poke the bear, just to piss him off. At this point, I’ve concluded that I don’t want the job. Dude turned strangely combative over simply saying I worked in a hybrid environment.
“Well, whenever I hear someone say that they are an Agile house, my first question to them is what flavor of Agile are you following? There are multiple types of Agile, that aren’t necessarily the same thing, so when you say that your company is Agile, what flavor are you using? It might help to better inform you of what I mean when I say that we were a hybrid.”
That afternoon I received an email letting me know that they would not move me to the next step of the process.
I tend to shit on Agile a lot, and it’s not because it’s a bad methodology, it’s because I see it as a cult (there is a fantastic article on Medium that covers the points of why it feels like a cult). Much more deserving of my ire, however, is Agile has become synonymous with what I call a processless process.
The “Joys” of the Processless Process
Are sarcasm quotes still a thing, or have they become so overused that they don’t mean anything? Regardless.
The thing to know about a processless process is that there is typically a thing that is called a process, but is so incredibly nebulous that the process serves no purpose, other than frustrating people. The argument for the loosely defined process? “It allows us to be Agile…”
If your process is so loosely defined that someone can say, and make a valid argument that something isn’t their job, even if it should be, you have a serious process problem.
When your product owners don’t own the product or the decisions on how it will be shaped, the project managers are nothing more than a glorified secretaries, taking dictation from the team in the form of daily scrum meetings, your business analysts don’t analyze anything related to the business needs, and your architects are just very opinionated developers, you have a processless process. It doesn’t even matter what you think your process is.
This lack of definition of what each role is responsible for is a headache for everyone involved and can lead to things such as employee conflict, deviant behavior, and loss of organizational commitment.
But! But! Muh-Agile! Ambiguity in the roles on a project team allows for everyone to fill in where they are needed so that the team can succeed together!
The following is an actual conversation that occurred at a reader’s organization:
Comms Manager: Why don’t we have any documentation on the happy path flow?
BA: We don’t know the happy path.
CM: Why not?
BA: we weren’t told
QA: We’ve been trying to get it for months now
PM: Who is supposed to manage this documentation?
BA: We figured it what the CM team since you are the one who gathers all the required documents as part of the request
CM: not us
BA: What do you do exactly?
CM: We talk with everyone involved before giving it to the project team
PM: Ok, why don’t you know the happy path?
CM: that’s not our job, that’s someone in the project team
QA: You guys get all of the documentation from InfoSec and Legal, why are you not capturing the workflows from the managers when you prioritize the requests?
CM: We don’t work with InfoSec or Legal, that’s the project teams’ job as well.
(It’s been over a year now, and there still isn’t any documentation on what the typical happy path is)
When I asked him what the roles were, I received a very disappointing response:
The PM handles pulling tickets into the sprint, and running standup, the BA creates the epic/story/tasks, and QA does regression testing. All documentation is in the Jira tickets/comments. No one has a clue what the CM does.
I’ll cut all you fuckers who bombard us with hate off before you start; no, this isn’t a unique thing that only affects some teams. If your team doesn’t have well-defined roles, you are experiencing this to some degree. You might explain away things that aren’t getting done by saying that “it’s not a big deal,” “we don’t need to do x,” or “doesn’t matter, our team still gets things done.”
Ask yourself, how much time do you waste trying to track down things, answer questions, or just get through the most basic of tasks because responsibilities are ambiguous? How much time could be saved? How frustrated are people when they are trying to get pertinent information, but don’t know who to go to?
The excuse that role ambiguity is more Agile than role clarity is only causing undue stress on your team. It’s affecting morale, even if you don’t see it directly.
Stop Hiding Behind Agile
Part of what makes Agile a fucking cult is the insistence that if it isn’t working, your just not Agilling hard enough. Here’s the thing, Agile is not the be all end all solution to methodologies. All of your projects are extremely typical, things you’ve done multiple times before, everything has been figured out, and there are very few unknowns? Agile probably isn’t your thing. A traditional waterfall methodology is probably more appropriate.
Have a more complex project? Yeah, you might benefit from Agile. Have an extremely complex project? Uh, you might want to think about what works for your organization, because Agile might not work, regardless of how hard you push it.
But these issues are never discussed or uncovered in process discussions. Instead, Agile is used as a shield spell, but unless your Tech-Bard is multiclassed as a cleric, you are not allowed to use shield in Monday morning review meetings.
Shielding yourself from criticism by hiding behind Agile is amusing, because it actually only refocuses the blame on the project team, but not in a productive way.
It’s true that you can point to these billion and trillion-dollar tech companies and argue that they are successful with Agile, therefore your small project team should also be successful with it. Now let’s think about this. You’re comparing your project team with the team that works for a company that can afford to hire the absolute best of the fucking best, and you think that what works for them is going to work for you?
Pretty fucking wild to make that assumption. You’re both project organizations, so you’re the same, right? No, you’re comparing apples to armadillos, they are not the same thing (although they would both fuck up your windscreen if they hit it while you’re doing 80 mph on the I-10 passing through Las Cruces.
I can understand the desire to cosplay as one of the big-tech companies. They are successful, they are practically printing money, and the shit they do almost seems like magic. Here’s the thing, the heads of these tech companies that you are lapping at their freak-box and drooling over, are all fucking idiots. Yeah, they grew a multi-billion dollar company, but they are only there because they have a stable of developers that are fucking world-class. You have O’Doyle, who failed out of Bob’s Coding Bootcamp and Transmission Shop. It’s like watching Ramsay’s Kitchen Nightmares to get inspiration on how to better prepare your fucking frozen pizza rolls.
Your pizza rolls aren’t shit because your décor is outdated and drab or because you forgot the lamb sauce, they are shit because they are frozen pizza rolls. They are meant to be eaten while drunk, high, in college (or younger), or forgot to go shopping and found a bag pushed all the way in the back of the freezer so you figure, why not. Likewise, your project team doesn’t suck because you didn’t follow the proper scrum ceremonies, missed a standup, or forgot the fucking lamb sauce; it sucks because it doesn’t work for your organization. This isn’t a failure, it’s an opportunity to get better.
Stop Defending Shitty Behavior
“We’re just trying some things, and we’re seeing what works and what doesn’t, but you have to give the process time to shake out” – The CIO of a long-established company.
I love process improvement. I love companies that are always looking to improve. I can appreciate how difficult the process of improving a process can be. The problem is the reluctance to accept when something didn’t work and change it immediately. I can go into the concept of cognitive dissonance, and why the unconscious defense that one experiences when they need to protect their fragile ego, but that is for another article. Instead, I will say that being wrong sucks. It’s embarrassing, especially when you are supposed to be in charge. When things aren’t working, though, things need to change.
When the CIO told us all that our complaints didn’t mean anything since we just needed to give the process time to work, what he was actually saying was that he couldn’t be arsed to admit he was wrong. He defended the shitty process, by saying you just needed to give it time.
The same goes for the grotesque lack of role definition. “It allows us to be more Agile,” translates as “ugh, definitions are for dictionaries, and only nerds read dictionaries.” You are using Agile as an excuse for the shitty process.
Start admitting that the process sucked and move the fuck on.
Now We Can Start to Heal
How do we start to fix your shitty processes? Step one, admit you have a problem. Not in the 12-step program way, like, you don’t have to admit you’re powerless or profess to a higher power or anything. Instead, begin looking at what the problems are, and admit to them. Requirements are slow to come in? Let’s figure out why that is. Documentation is missing? Let’s figure out who is responsible for the documentation.
The first thing that needs to be done, once you’ve identified the problems, is to explore the problems further. Don’t look for a solution (not yet at least), but really explore the problem. Frame the problem in as many ways as you can think of. If your problem is the work doesn’t meet the client’s needs, don’t only ask why some tickets are not fully meeting the acceptance criteria, reframe that so you can get a full understanding of the problem. Try:
Why are tickets not meeting AC?
Why is the deliverable not to the client's expectations?
Why are some tickets meeting expectations?
Where are there breakdowns in quality checks for tickets?
For the tickets not meeting client expectations vs the tickets that are
Are there breakdowns in quality for the tickets that do meet expectations?
Once we’ve looked at the problem framed in different ways, now we can start to look at further questions (still not solutions, but we’re getting there). We are trying to elaborate on the aspects of the process that might be causing the problems.
Based on the previous points, try:
Do we have a quality control system in place?
Who is responsible for quality control?
Do we have regular check-ins with the devs to ensure that they are meeting the AC
Do they understand the AC?
Who is responsible for that?
Is there a training issue with certain developers?
Same question, but with BAs, PMs, QAs, POs, etc.
Do we have a system to manage client expectations?
Who is responsible for that?
With all these questions asked, we can begin to look at solutions.
The above discussion and questions were actually pulled from a client that I advised. The problem ended up being an issue of role definition. It was assumed that QA would be managing quality (it is in their title after all), but QA didn’t become involved until after the work had been completed. We created a quality control system, that included regular check-ins with the developers, and a robust communication mechanism with their clients. This fell on the BAs, as they were the most familiar with all involved.
It should be noted that fixing a single problem doesn’t fix the whole problem. So, yes, creating a functioning project team is going to take time, and, yes, you will need to see how things shake out. So rather than faking it until it works, it’s important to understand a few basics when it comes to creating a project team.
*****
This marks the last entry in the “Why Your Project Team Sucks” series. We are looking to continue this topic, developing a process for your project team further. Starting in a couple of weeks we will be kicking off the series “Beyond Agile.” The goal is to move beyond the “we’re an Agile house” and into a deeper understanding of what is needed for a project team to function, including role definitions and project control systems. It is our hope that your organization can build a project team that works for you, and not one that is trying to copy the fucking idiots running tech companies into the ground because they are fucking children.
Commentaires