61–70 of 78 posts
i would love to read more about these "superior development processes" without any issue tracking or activities log.
I think you should grow up. I mean, what’s your end game? Do you want to manage or own projects for the rest of your carrer, or do you want to move up and retire early? If the former, propose them a tool that you prefer and meets their requirements (maybe integrates with Jira?). If the latter, be the champion of Jira integration, get to know the new upper management who wants Jira in, explore how you can penetrate th…
No need to sling terms like "you should grow up". There's both a reason a big share of developers hate JIRA with a passion and also a reason business people like it. It's hard to find the fine line of it being useful for both parties and not just making the developers' lives harder and I've seen people having to spend an extra 30min per day just fighting the tool. This is not about whining to keep your independece, t…
If the motivation is to track what the teams are doing, even if you win the fight on not using Jira, something will be proposed. Maybe it's Rally, maybe it's some POS that was sold because their sales guys and your CxO had a golf game.
You're better off ensuring that you could do what you need to do with Jira than anything else.
As an aside, I take issue with the term dev team - many people use Jira as part of an "agile" process, but they only plan things around development, but not test, only to find out later that their one liner change from dev could cause the tester a week to setup the environment for an automated test....
We've got nothing similar to Jira in place and are dealing with things without any dedicated tools Are you not tracking issues at all? I very frequently look up years old tickets to know why something is the way it is, and I could not imagine working without it.
For normal work I simply don't allow my team to create tickets in JIRA unless there is at least a technical design document which contains at minimum a bullet-list describing the complete scope of work and some documentation or links to documentation regarding the specific requirements. For bugs I require the ticket created and put in our queue to be updated with the same material once the cause of error and the fix are identified.
Earlier quoted context omitted.
To add to your coment, depending on the company, moving a lot of $$$ to capex is incredibly important for management. If anything you should embrace Jira and look for ways to help get things classified as capex. Ask for a meeting with accounting/finance to fully understand it. Just think of it as learning a new skill. For the people saying to look for another solution, I would first figure out how much work they put…
> moving a lot of $$$ to capex is incredibly important for management A few questions: 1. Why is this the goal? 2. Why does it depend on the company? 3. How could you categorize development as capex? Isn't it obviously opex? 4. Why do they need JIRA for that? Why not GitHub issues? 5. Who's "management"? Engineering management? Executives? Someone else?
2. Likely because the bigger company has a much more complex balance sheet so applies more complex accounting to manage it.
3. It's not the development so much as what's being developed. You're essentially creating an asset rather than a consumable so the cost of that asset can (sometimes) be considered a capital expense.
4. Probably because that's how they're managing this for the rest of the firm. If all the activity is done consistently in one tool, it makes it a lot cheaper to manage than having to chase up multiple groups, massage the data, reconcile etc etc.
5. Depends on the org. It's finance who want this directly as will whatever levels care about their P&L.
It's also not inconceivable that there are standardised processes across the org so that engineering cares for engineering's sake. Though that doesn't sound like the reason in this case.
At the level of an individual team this may seem like a bad idea but, in an org with a lot of dev teams, fungibility of tooling and process can both be a big cost save as well as a big training save.
Management has a concrete problem they want to solve: "Their motivation is to be able to track what the dev team is doing and keep a log of the activities, with the end goal being to be able to qualify this work as Capex." So if you really don't want JIRA then offer an alternative that will meet those requirements. Management may still say "just use JIRA". Before pushing back on this have a think about the cost/benef…
To add to your coment, depending on the company, moving a lot of $$$ to capex is incredibly important for management. If anything you should embrace Jira and look for ways to help get things classified as capex. Ask for a meeting with accounting/finance to fully understand it. Just think of it as learning a new skill. For the people saying to look for another solution, I would first figure out how much work they put…
We used to write our own stories in Jira and they were mostly one liners. They have now implemented so many required fields to fill out. Filing out one story might take 30 minutes.
And the management has implemented a mix of waterfall and agile methodology.
It is combination of worst of both worlds. We are asked to plan our next 10 or more sprints. Assign points to each story. And then we are asked to justify points to management. It is a big mess. In a week, we might spend 20+ hours on planning and planning to plan bullshit.
I fought this as much as I could. But in the end, I realized that this is losing battle. All we can do is work with them and help them justify their jobs and our jobs.
We have stories for planning stories. We have stories for reading documentation. We have stories for breaks. Oh I want to cry.
But good thing is if you work with system and make your team look super busy, you will get big bonuses and pay raises. Kind of like in real world, you can write the cleanest code but if you don't write features that customer want and brag about your product, you will not get paid for it.
Based on my experience:
- Use the "Jira Agile" (formerly greenhopper) add-on so that you have sprint/kanban boards and reports to visualize planned and in-flight work. Enable the "Backlog View" for your boards to separate planned from in-progress work.
- Keep required fields to an absolute minimum (we only require Summary) so that you can quickly capture cards and flesh them out later.
- Avoid complex workflows - use the Software Simplified workflow if possible. Don't complicate it further without a really strong business case.
- Learn the keyboard shortcuts. C (create), E (edit), I (assign to self) "[" (hide sidebar) and "." (command palette) are your friends
- Confluence and Slack both have great integrations to let you publish and interact with your Jira issues
Those are just a few random thoughts on how we've kept Jira working for us and not against us.
Earlier quoted context omitted.
No need to sling terms like "you should grow up". There's both a reason a big share of developers hate JIRA with a passion and also a reason business people like it. It's hard to find the fine line of it being useful for both parties and not just making the developers' lives harder and I've seen people having to spend an extra 30min per day just fighting the tool. This is not about whining to keep your independece, t…
Indeed I could have spared the terms, but your comment is exactly what I am talking about: developers often place themselves agains business people, sometimes feel superiority, and are proud of it. But in fact it's wrong and immature – working in a company means cooperation, and both departments have experts in different skills. Another common pattern is to glorify tools and frameworks and be passionate about them. A…
And it's not the CFO's job to know/understand these effects; its the CTO's job to. And it's the CTO's job to fight back on it if necessary, because its interfering with his domain. It's also the CTO's job to know whether or not its actually interfering with his domain, and its his job to argue that position. And ofc, its the CEO's job to look at both offers, and decide whether or not the cost of interference to development is worth the benefits to the financials. With perhaps the CFO/CTO coming to an agreement independent of the CEO where trivial, as an optimization, but the ultimate responsibility is on the CEO's hands.
It is absolutely not about simple cooperation: its competitive cooperation. The goal is shared, but the steps to achieve it are not. And because of specialization, we cannot cooperate by simply knowing the global state of things, and determining the best course of action. We can only know the parts we know (a subset of the global state), and optimize our local interest in hopes that our local optimizations will take use closer to the global optimization. And everyone is doing that, with a local view. The only person who truly intends to chase after the global optimization directly is the CEO.
You should be protecting your domain from competing interests, because everyone wants to have a say in your domain, whenever they can derive even minor benefits. They don't know the cost to your domain, or the benefits to it: they know the cost to their domain, and the benefits to their domain. They may have some idea of it, but ultimately its your own job to know your own domain, and defend it as necessary.
Development does not, and should not, know whats best for finance, and the same is true vice-versa. It's not their position to. They specialize in their own domains, and thats fine. Obviously an overly-aggressive defense, or interference, can be harmful, but it'd be ultimately stupid, and likely harmful, to blindly follow the orders of people who do not know your domain, in the spirit of cooperation.
A friend of mine was at a company that was using JIRA, but they had no processes in place and ended up going back to using paper.
I think you really have to establish some simple processes to really get the benefit from these tools.
You can go overboard and try to require people to document every single detail every single day, but I think this is counterproductive. You have to find a balance.