Bah this process is faulty, we use it at work and this means that a feature which has to manage N things is almost always split into 'manage 1 thing' then 'goes from 1 to N' even though it takes more work and the resulting code is much more ugly..

If your problem's complexity is big enough, you can't get good solutions without an explicit architecture step. I've seen quite a few bad ad-hoc architectures being created trying to break down epics that were too big. Your team needs a lot of discipline to come up with a good plan/architecture (per story/epic at least) first. Scrum did not help here, to me it seems it legalized hacking away the day... In some domains you can't pay back that kind of dept easily...

The article may have a clickbait headline, but „have an overview and use JIRA in addition to track the leafs of the work hierarchy“ is true.

What I found is that almost all projects try to organize as tree but they should organize as matrix, at least if there are many cross-cutting components.

If my team had that much discipline to begin with, they’d do just fine without Scrum.

There's many ways to split a story and oftentimes I would argue that creating a smaller version first makes the code better. Ie writing code that you _know_ will have to change not far off in the future.

https://agileforall.com/resources/how-to-split-a-user-story/

i've seen plenty of people that tried to tackle a big problem at once and the result was way more ugly than just split the problem up. at my work place my boss always writes down the complete issues/features and let the people do them however they like, but most of the time this is bad, because doing something at once without a certain structure will yield a way bigger mess than if the thing would've been splitted.

That's why you pay for experience. Doing it at once leads to better overall design provided the developer can produce proper structure on there own.

There are two primary styles of software development.

The first is “make the change/feature easy, then make the easy change/feature”. I call this Structure-Driven Development (SDD), because the features of the software are emergent properties of the structure of the system. This often concerns various “layers” of the system (HTTP, auth, validation, data access, error-handling, etc).

The second is “make the change that’s currently easiest”. I call this Feature-Driven Development (FDD), because the structure of the app is whatever emerges from feature development. This, naturally, concerns the various features of the software itself, spread across whatever primitive components are already available and usually copying structure from the first few features written.

IMO, successful agile product development involves a mix of these styles. SDD produces better structure at the expense of heavy up-front development costs. FDD helps you figure out where to apply SDD.

I like to start projects with SDD for the first few weeks of a project, then alternating styles every 2 weeks to test and refine structural assumptions (think of it like a REPL for architecture). This also helps keep teams from getting too stuck in either style as many do.

Get locked into SDD, end up not shipping a single feature for weeks. Especially prone to happening on single-developer projects. Especially unlikely with good project management + strong communication between engineers and stakeholders.

Get locked into FDD, code yourself into corners, gradually building a pile of mud that no-one fully understands. Far less likely (but still possible) on single-developer projects. Senior engineering oversight and adequate time budgeting are critical to preventing this.

Both styles have their tradeoffs, and like most things it takes experience/maturity and a dash of luck to navigate the balance successfully on a given project.

One indicator that your SDD is working is that you do much less of it after the first month or two of development, as the structure will be in place and effort can largely shift to features and polish.

EDIT: Cleaned this up into a post here https://medium.com/@hi_17592/software-development-styles-ebe...

there's also a blended style where you start with FDD then perform SDD in the refactoring. This way you're not performing blind architecture - you make the necessary change and you systematise the solution during refactoring, if it is a change in system behaviour. You can use this technique on an ongoing basis at a per-ticket scale and trust that you are 1. not violating YAGNI and 2. always in a state of minimum-viable-well-designed-architecture.

> That's why you pay for experience. Doing it at once leads to better overall design provided the developer can produce proper structure on there own.

that's not true. an experienced developer will actually structure the project in a good way, even if the problem is split into multiple issues.

Or it leads to dicking around forever while you change your mind five times about what the "proper structure" is because you're not comitting to anything and not getting any feedback. Experience has very little influence on that.

If someone is playing around trying to get a proper structure it really is a lack of experience.

If a person repeated the same project 5 times on the last attempt would require very little trying to find the proper structure. Experience has everything to do with that.

"Analysis paralysis" is a real thing, so I partly agree with you. Sometimes you have to take parts of a large concept and "dick around" with it to discover the unknown unknowns and how not to do it, then feed that back into analysis.

After a number of iterations of this, you converge on a baseline architecture that you try to support future change without being excessively focused on YAGNI. Over-focus on YAGNI often leads to architectures that are so inflexible that when you DO need it, you can't add it without a demolition crew[1].

People should also remember the context in which YAGNI came up: Kent Beck, Ward Cunningham, Smalltalk, and the C3 project. This particular combination of people, project, and process made YAGNI feasible. And the C3 project, which spawned XP, was not as successful as folklore would have it[2].

It's not always so. Imagine if YAGNI was the focus of Roy Fielding and the HTTP specification, which has lasted remarkably well because of allowance for future change in the architecture.

Scrum and other processes that claim adherence to the Agile Manifesto work best in certain contexts, where code turnaround can be fast, mistakes do not take the company down and fixes can be redeployed quickly and easily, the requirements are not well-understood and change rapidly, and the architecture is not overly complex.

Many other projects don't fit this model, and people seem to think that so-called "Agile" (which even the creators of the Manifesto complain is not a noun), and mostly Scrum, is the sole exemplar of productivity.

The fact is that there are many hybrid development processes, described by Steve McConnell[3] long before the word "agile" became a synonym for "success", that may be more suitable to projects that have different dynamics.

An example of such a project could be one that does have well-defined requirements (e.g. implementing something based on an international standard) and will suffer from a pure "User Story" approach.

Let's be much more flexible about how we decide to develop, and accept that you need to tailor the approach to the nature of the project, based on risk factors, longevity, and other factors, and not on dogma.

And let's not underplay the extreme importance of a well-thought out architecture in all but the most trivial of projects.

[1]: https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

[2]: https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...

[3]: https://www.amazon.com/Rapid-Development-Taming-Software-Sch...

Still, there's no blaming JIRA. That's a methodology issue, not a tool issue.

Mature empowered teams will also discuss the cost/benefit to determine if the feature is really worth the effort entailed in light of the thousand other priorities in the backlog. Sometimes this leads to alternate, more efficient approaches to addressing the need or at least a healthy discussion on the true MVP of the feature.

Indeed the main point to provide context in the scrum process is the refinement meeting.

I completely agree, the refinement meeting is the key.

We've just spent a year interviewing 200+ product owners about the problem that the article are describing. For most teams, JIRA works great for monitoring progress on closely defined tasks, but context "above story level" is a real problem. The better teams do already use another tool than JIRA to write such documents, typically at "epic level", and typically using Google Docs and/or Confluence.

But almost all struggle with writing this document, where common problems include: * duplication of work and manual updating between the document and JIRA * unclear handover of the source of truth, since things that are written in the document are "true until stated otherwise in JIRA or a JIRA comment.. or somewhere on Slack" * lots on input/questions/decisions from refinement meetings not captured in either the document or in JIRA

I think the solution is to think of this document less as a "requirements document" (many label this doc a "PRD"), and more as a "refinement document". This "refinement document" should * try to capture the conversation that happens in refinement meetings * involve also the developers to cover not only "why" and "what", but also a bit of "how" * evolve and be updated all the way through development as new insights are gained * be the source of truth and available to the developer working on the JIRA issue

We have made a tool specifically to support working this way with "refinement documents". One dedicated place to refine features. Structure, collaborate, keep track of questions and capture not only decisions, but also conversations. Seamlessy transform your work into crystal clear Jira epics and stories. When you turn notes into Jira issues, you can see all the details via our Jira plugin. Happy to hear your thoughts, please do check it out at https://www.delibr.com/

JIRA could work better in this situation if it allowed for deeper nesting of tickets. You could still capture the larger user story and then subdivide below that level into smaller stories and then features with tasks.

It does. My team uses Epics -> Stories -> Sub Tasks all the time.

That’s not enough to represent large, complex projects. And sub-tasks are implemented in this weird, dystopian way that makes them unreasonably hard to work with in the system.

Agreed, the few times we've tried moving from separate linked tickets to sub-tasks have been disasters. It doesn't jive with any of the tooling in Jira to try to have tickets be like 'mini-Epics'.

You should check out the Structure add-on. Does unlimited hierarchies in a very intuitive way. Only for on-premise.

That is not enough! I regularly want to create sub tasks to subtasks, but it is not possible.

You could also link to other tickets or Epics with "relates to" or "blocked by".

And at that point why not Bugzilla?

Because "Oh, come on!". Just because you can implement any process in a list of text files and grep it does not mean you should. Jira has features that Bugzilla does not or needs plugins for. Should you just throw all of that away?

The complaint is that Jira's "features" are not much better. It's completely manual and only works if you strictly enforce conventions.

You also can have something bigger than epic - you could use Portfolio and create initiatives there.

"Capture the larger user story". Why should I disintegrate information among many Jira task names and descriptions instead of writing readable and organized high-quality documents?

I'm used to use Jira only for timesheet purposes: hierarchical decomposition (project X, activity Y, often also employee Z) allows stress-free accurate accounting.

It doesn't but the beauty of it is that there are plugins like Structure, that do

Yes but the developers are incentivized to get it done as quickly as possible and if they start to present multiple steps their managers will be likely to acuse them of overengineering the system so they just try to do it all at once.

This sounds like a trust issue, not a Jira problem

Jira encourages this kind of trust problem by framing the world in terms of ticket-closing velocity.

Just take the 3 weeks to implement it. Process doesn’t exist to hold us hostage.

Sounds like there's more overhead than work there.

Yes, let's move fast and break things. Things like the architecture, the framework and team communication. Then once the tech debt avalanche rolls in move fast to a different company to break things there. Thus good hiring processes to to keep prototype programmers at bay.

I'd rather break things than linger around in some obscured purgatory where a straightforward task is spread out across a dozen subtasks that ultimately end up being rewritten anyway because something changed during the month it took to get halfway there.

Yeah - blame the developers. 90% of the “bad” code i have written was forced by the manager/company. The proper / structured way considered too expensive.