The Process Is Not the Product. The New Agile Anti-Manifesto

Jira. Please stop crapping on it. It&#x27;s a tool that&#x27;s too flexible so many people can&#x27;t resist abusing it. It&#x27;s you, not it.<p>For us, it&#x27;s primarily a documentation tool. It has great integrations. If someone makes a complex pull request, the text that tells me what it does is the Jira issue. Yes, it could be the PR description, but Jira is much easier to link to, search, etc. 2 years later when someone looks at the git commit, they can go to Jira and read through the whole context, who created it, who commented on it, etc.<p>Just use the damn thing to solve problems you actually have.<p>Jira, Java, Windows, JavaScript, Kubernetes, etc. can be used in various ways, and because most people aren&#x27;t excellent at what they do, flexible tools will result in lot of crappy output just because so many people can use them.<p>If Jira&#x2F;etc. destroys your project then it&#x27;s absolutely your fault.

<p><pre><code> I have to push back against the &#x27;process&#x27; too often to care to count. The idea of the self managed team shatters against the rocks of: there is no card on the board for this so I can&#x27;t do it, which produces boards filled with cards that have no user value in them. We twist ourselves in knots explaining that &#x27;yeah, implementing the CI&#x2F;CD pipeline brings value to the user because we are faster at delivering software&#x27;. It boils down to the idea that the &#x27;user stories&#x27; are just metric collection tools, so if you haven&#x27;t delivered a story, you implicitly have done nothing. And the &#x27;placeholders for a conversation&#x27; have become mini requirement docs, because we don&#x27;t trust our development team to pick up a card and investigate, communicate and plan their work. So refinement meetings become long debates on the minutia of the story, litanies of acceptance criteria that read like contract agreements of years past. You begin to see hierarchical structure form in supposed teams of peers, where someone will casually ask: &quot;Hey X - can you put a story on the board with this?&quot; &quot;Agile&quot; is no longer a adjective of how our practices are, but a label on a set of processes that some board has certified as such. PS: Can anyone tell me why when I write in my iPad all my comments look like code blocks? I know it&#x27;s annoying too others, but not as much as it is to me!</code></pre>

My main issue is with Scrum. The problem is that there is no balance.<p>Scrum started off as a way for software consultancies to make sure that the their clients could not ask for new features without repercussions. In other words, story points helped to make sure that if they wanted changes, and more stuff, then they would need to <i>pay</i> for it.<p>You do not have this balance within a company, because there is constant pressure to increase velocity. This is why there is so much burnout within the industry. There is <i>constant</i> pressure to do more and to do it faster.<p>To the OP&#x27;s point, there are so many scam Agile coaches out there, who can&#x27;t write a fizzbuzz function. I&#x27;ve met many of them. You know what the worst part is? They <i>think</i> they&#x27;re adding value by just pushing people constantly.

Eh, jira can be fine so long as you keep it simple and just use it to track pieces of work in progress, bugs etc.<p>By the time you&#x27;re hiring a jira specialist and talking about workflows and restricted state transitions, something has probably gone very wrong though.<p>Also worth remembering, as we rail against this stuff - <i>good</i> people don&#x27;t need to be encumbered by that much process to produce good things, especially in small groups. But not everyone is that good, and groups don&#x27;t always stay small. Not that that means that adding process is always right, but it is another factor to keep in mind.

Project management is fine, needed even, you don&#x27;t need and probably don&#x27;t want to be in the countless client meeting where everything is bickering and bike shedding, and you don&#x27;t want engineering to be the one coordinating the countless administrative task and being generally distracted by paperwork<p>Management is fine as long as it&#x27;s a cog in the production chain; you can generally know if your management is healthy if the IT&#x2F;Dev budget comes from the IT&#x2F;Dev leads and if the contracting work requires IT&#x2F;Dev signoff.<p>I get it, most places around see management as the steering committee, and quickly become disfunctional as their focus shifts in justifying their own budget, but that&#x27;s because IT&#x2F;Devs are a century behind in establishing their profession as specialists like lawyers and doctors and often find themselves in blue collar type positions, not from a specific property of having &quot;management&quot;<p>Just look at hospitals and lawyer firms, you&#x27;ll find seniors doctors and lawyers at the top, and accountants in their own dept, and not the other way around.

This reminds me of what they say about democracy, that it&#x27;s the worst form of government besides all the other ones.<p>Or programming languages. There&#x27;s the ones people complain about and the ones nobody users.<p>Process isn&#x27;t fun, and yes there are times when it gets in the way. But if you don&#x27;t have one, you still do. It&#x27;s just not formalized and probably powered by force of personality instead of the needs of the business. Hopefully those are aligned.<p>The powerful think everything is working great, and for them, it is. As long as the business is aligned with their needs, this works. But it doesn&#x27;t scale to when you have many different stakeholders with conflicting needs.

I used to think Jira was the problem, then at my current (small) company I became the Jira admin. Excellent, I thought. I will finally get to use this tool properly, set it up sensibly, and put to rest all the horrible experiences that are too common.<p>I&#x27;ve been deep in the bowels, custom issue types, custom workflows, if it was accessible I&#x27;ve been in there.<p>After six months of trying I believe it is unsalvageable. Adherents seem to suffer from a form of Stockholm-syndrome.<p>* We have a small team, &lt; 30 people, probably &lt; 2000 issues. It is unacceptably slow. Performance is a joke and it keeps getting worse. No we don&#x27;t have a dozen integrations.<p>* Next-gen projects. Think Python2-&gt;3 confusion but for your entire company&#x2F;workflow. Madness, short-sighted, and ultimately solely for the benefit of Atlassian, not the users.<p>* &quot;Premium&quot; mode required to provide features that should be basic. Twice the price. No option to enable &quot;Premium&quot; on a per-user basis. So thousands of dollars for one PM to use a Gantt chart.<p>* Pricing. I don&#x27;t want to pay a full seat&#x2F;month to allow a marketing person to put a ticket on an engineering backlog. Yes, they could go via a person but if you&#x27;re going to mandate human mediation then why do we have the damn tool in the first place? This makes it exclusionary.<p>* UI Design keeps getting worse. Necessary information is hidden at every possible opportunity. It&#x27;s like they saw the Google whitespace focused redesigns from a few years back and felt personally threatened.<p>* I refuse to accept that the cost of switching tools is too high, I&#x27;ve switched my teams over to Basecamp and we not longer feel like we are fighting our tools to do our jobs.<p>* If you work somewhere where this level of process is required (medicine, military...) then Jira is not the right tool. If you don&#x27;t need this level of process, then Jira is not the right tool. It is simply not the right tool.

His third point - “Dialog, not Dictation” - I agree with, but the other two are false dichotomies. Process (or at least the service levels enabled by process) is part of the whole product. Management and leadership are two sides of the same coin - one without the other is empty.<p>I get the frustration. Imposed process smells of poor management. But process and management can’t just be wished away.

I sympathize with the anti-management sentiment overall, but I’ve yet to see anyone address alternatives to designating someone, new hire or otherwise, as a “manager”.<p>This article doesn’t really touch on it other than to say “do a bunch of things right and folks can self-manage”, which is a retort to a narrow use-case for management. Not all managers are intended to be people managers, nor do they want to be.<p>I can’t help but think the management vs non-management paradigm is 50% due to anti-management stereotype, and 50% due to actually toxic management practices. And I imagine half or less of that latter 50% are toxic because of a bad manager. Everything else is likely due to overbearing leadership, poor company goals, a bad process that management would too like to change but can’t, etc etc.<p>Generally, I agree with the article’s sentiment. Don’t force a process, find what works for your employees. Get company buy-in. Set clear rules and goals. Hold folks accountable, and tell them to hold you accountable too.

Everyone loves these rants about bad process. I do too. But they always sound childish when they don’t explain how we’re supposed to set direction and coordinate work across 12 teams all working on the same product. And most of us work in enterprise-y environments where this is unavoidable.

A lot of other professions build complex things, even sometimes involving large teams across different departments. Do they all have their different industry frameworks&#x2F;methodologies (like Agile), or is that unique to software?

&quot;The process is not the product&quot;<p>I found it more interesting and productive to provoke discussions around another perspective: &quot;The product is not the business&quot;.<p>It&#x27;s so common to see people think that just because their product sounds nice and compelling to its intended market&#x2F;niche, it doesn&#x27;t mean the same team would be able to sell it and maintain it in an ongoing basis, let alone evolve it.<p>The reality of business operations is too cruel.

Agile works but where companies fail miserably is the implementation. Especially many of those that go with Scrum (or its flavors). They treat Scrum Master as a person instead of a role within the team. So they assign a non-engineer to an engineering team permanently that has some influence on the way of working without ever guiding the team to be self managed agile team.

Well, you mean those?<p>&gt; Individuals and interactions over processes and tools<p>&gt; Customer collaboration over contract negotiation

&gt; Informing everyone, right down to the janitors (and all respect to janitors) where we are going and why.<p>But it isn’t a coincidence that you chose to single out the janitors as those who are “down”.

I could take this more seriously as a new agile manifesto if it wasn’t published on Medium.<p>These kind of things have to stand on their own.

<a href="https:&#x2F;&#x2F;archive.fo&#x2F;lJlrY" rel="nofollow">https:&#x2F;&#x2F;archive.fo&#x2F;lJlrY</a>

Recently I had a client obsessed with the &quot;Jira&quot; version of the world, ignoring the real world. E.g. product wasn&#x27;t meeting a spec but the spec was irrelevant. But they committed to it in writing&#x2F;database so we obsessed to improve that useless spec at great cost to customer needs...<p>To be fair, not just the tool&#x27;s fault, but the tool does influence perception by looking &quot;official,&quot; having &quot;permissions,&quot; and inducing sunk cost fallacy by foregrounding how long things are taking. E.g. &quot;We can&#x27;t admit this spec is useless now... we&#x27;ve put so much time into it, just look at Jira!&quot;

Nah.

Thanks, I hate it.