Why I don’t use Jira and Confluence at all for my software development? Part 2

Continue from Part 1.

Solid evidence of “Jira and its alike is non-essential for Agile Software Development”

People would assume companies depend more on Jira or similar tools for working remotely(due to Covid). But Atlassian's share dropped 73% last year. Two other Jira alternatives performed even worse, Monday.com: 83%, and Asana: 77%.

This has at least shown that Jira had lost its steam, and this kind of tool is not essential to software development. I have seen ClickUp video ads that laughed/snubbed at Jira by listing dozens of specific issues.

This is not fair to Jira as ClickUp is not good either. ClickUp claims “Jira is over-complicated”, but I think ClickUp is no different. It’s an example of the Chinese idiom: Those Who Flee 50 Steps Laugh at Those Who Flee 100 Steps.

“As a software product owner, I want my team to spend absolutely minimal time, preferably none at all, on a project management tool such as Jira or ClickUp. It is wise to focus on our own app, not someone else’s. When you start focusing on Test Autumation, you will get a much better picture” — Zhimin Zhan

The solution is to get rid of digital versions of user stories, as Kent Beck (Father of Agile) suggested. Focus on the stuff that matters:

• Make user stories "Done, Done", covered by automated end-to-end (via GUI) tests
• Run the entire automated end-to-end test suite in a Continuous Testing server (like Facebook's Sandcastle or BuildWise, not Jenkins or Bamboo) multiple times daily as regression testing.

Why are those digital management tools like Jira spreading so fast like a virus?

I read one not-well-known quote (can't find it now) from Steve Jobs: "if salespeople get attention, the engineers are not important anymore". A basic question: "Who is mostly using Jira actively?" Managers, (fake) Agile coaches or (fake) Scrum Masters, and business analysts. Programmers and testers are forced to use it by reading user stories' content and their comments.

In a healthy agile team, managers/agile coaches/business analysts perform a support role (I am not saying it is not important) to help programmers and testers produce high-quality software builds in the pipeline. After all, the customers only care about the product, not whether the user stories were managed in Jira or Monday, nor developed in JavaScript or Ruby.

In non-engineering staff's minds, they know their work is unimportant. A natural intention is to make their work more complex and more relevant. Jira provides that.

Again, I am not belittling project management which, of course, has a lot of (sometimes critical) contributions to a successful software product. But a good manager must know what really matters in software development.

The best agile manager I met forbade team members from using Jira, and only he used Jira for his reporting. (I wrote a program to help him print the user stories to 6"x4" index cards). His successful management comes to a simple statement: "When you (programmer) complete a user story, bring your card and show me an execution of automated tests for it". He spends a lot of time playing golf-putting-set in the office, but he was a very good agile manager. For more, check out this article, Agile Coaches / Scrum Masters Shall be Technically Excellent or Understand the importance of Continuous Testing.

What about Confluence, then?

Confluence, without Jira, is just a Wiki. How many people are using Wiki nowadays (except Wikipedia, which is a totally different beast)?

Some people will ask, "How do I note down the guides to business operations, test data, deployment procedures, …, etc.?"

The answer is "Automated Test Scripts".

Before showing an example of automated test scripts, I show a quote from Kent Beck.

It is worth empathising, "except for code and tests, everything else is a waste". This applies to Jira, as well as Confluence.

OK, let's examine some common content on Confluence.

• Guides to use business features

Once the documentation is written on Confluence, it is static which means it will be out of date soon. Invalid documentation is often worse than no documentation.

• Test Data

The same applies to test data, e.g. test user logins. How often did you find the test data on Confluence invalid? Do you update them yourself?

The solution is to capture the above in automated test scripts. Here is an example test script for my WhenWise app: 'add membership':

If you are a business analyst or a customer who is familiar with business logic, you will understand the above layout. Test data is part of test scripts.

Unlike the dead document in Confluence, the information in automated test scripts is live. If a team does proper agile and runs the automated test suite regularly (multiple times a day), the information will always be valid!

--

The original article was published on my Medium Blog on 2022-11-24