Tag: next-gen

I’ll admit that I didn’t expect to like next-gen projects, Atlassian’s answer to making Jira more simple, and creating self-contained projects that won’t impact the performance of your entire Jira instance. First off, I felt vaguely resentful of the timing – just as I’m finally figuring out the complexities of Jira, they come out with a “Dummies” version.  Second, I’m not a drag-and-drop type of person. I learn through language, by hearing and reading. I tend to find tools built for visual learners to be imprecise and a bit annoying. But I decided to put my reservations aside and create a next-gen project. Here’s what I found.

The Great Things About Jira Next-Gen Projects

Set up was fast and easy.  I had mapped out my project on paper so it was pretty quick to set up the issue types I wanted.  I added and ordered the fields I needed right there as I was creating the issue types, creating custom fields and adding choices to my dropdowns – all on one easy screen and with no schemes to worry about. 

I set up my screens at the same time that I created my first issues. Again, it was simple and intuitive. I simply clicked on Configure Fields on the Issue Create screen and now all of the fields I wanted are there.

These are two big advantages of next-gen projects. Set-up was simple and it’s really, really nice to know that I can create a project specific to my needs, without worrying that I’ll screw things up for everyone else.

And the Risks…

Time will tell if those two advantages also turn out to be the biggest disadvantages of next-gen projects.  While setting up the next-gen project was certainly easy, I wonder if the simplicity itself may cause users to miss out on something. When you wade through issue type schemes, field configuration schemes, etc. you are getting the benefit of learning from those who have gone before you. Seeing the fields that are used in other projects may trigger you to think about aspects of your project that had slipped your mind, aspects that may not be relevant to you, but are crucial to other users. I’m curious to see if, as my project evolves and I make needed adjustments, it will end up looking a lot like one of the default schemes.

While it’s nice to be able to create a project knowing that you won’t mess up what anyone else is doing, it also implies a higher level of responsibility. If this is my standalone project, with my issue types and my custom fields, then it’s my job to get them right and to clean up the mess when I get them wrong. It will also be my job to deal with maintenance – to keep the project clean, to make needed changes, to clean up the data when garbage gets entered. Simplified maintenance is one of the key advantages of shared schemes. It will be interesting to see, as use of next-gen projects grows, if maintenance becomes an issue. Atlassian has said that they will soon be providing the ability to extract next-gen project settings into their own template, and link two or more projects’ settings together. (However, they also say that if you want to share configurations, it’s best to go with a “classic” project.)

The other limitations of next-gen projects relate to them being new. Atlassian has published their roadmap, letting us know when features we’re used to using in traditional projects will become available for next-gen projects. App developers will also need time to catch up. For instance, ProForma – which allows you to create forms that embed in Jira issues – does not yet work for next-gen projects. I think I’ll create an issue for that.

Atlassian’s introduction of “Next-gen” projects in Jira Cloud represents a paradigm shift in the way they build and deliver features.  They are moving from a massive monolith of code to microservices structure.  In their recent webinar “The new Jira begins now” Atlassian shared that they operated from a single code base for almost a decade!  I used to work in an environment of large and aging software, so I know how challenging it can be.  Your team is ready with a new feature, but you can’t release it until all teams are ready to also ship their code.  Or, your team changes one variable and it breaks everything for all the other teams.  No fun!

It sounds like Atlassian is now able to build software the way I wish we could have back then.  They are leveraging “feature flags” to better control rollout and delivery.  For example, they can deploy code in an “off” state and turn it on later.  Additionally, they can turn code “on” for a subset of customers, or launch features in a controlled and measurable way.

Sounds great!  If I didn’t love Jira consulting so much, I might be tempted to get back into software development.

What does it mean?

So what does this shift get Atlassian?  It means the freedom to re-architect, try new things, and build a new project creation and management experience in Jira Cloud.  The Next-gen projects launched without expected features, like Epics, Sub-tasks, and required fields.  But with their new release capabilities, features like these are shipping quickly.

Atlassian has shared their development roadmap, which is a most welcome addition.  I always appreciate any insight I can get!

Do we want this?

Atlassian says we do!  They surveyed customers and learned that teams want flexibility and that centralized administration creates bottlenecks.  Waiting for your Jira admin to create your new project doesn’t scale.  I can understand that and I know users and customers have waited on me to perform an “admin only” task.

Atlassian also says admins have expressed the desire to delegate some of the more mundane tasks so they can focus on more important and impactful work.  I get that too.  There are some things I don’t love to do, like managing group membership, for example.  As long as there are no collisions,  impacts to other projects, or messes for admins to clean up, delegated administration could be very helpful.

Key Differences

Atlassian uses the word traditional to describe the original projects we’re more familiar with.  Traditional projects utilize configuration schemes.  The new Next-gen projects are “schemeless” and totally independent.  Atlassian says that future Next-gen projects will have template abilities.  I’m interested to see how that differs from the traditional project’s concept of “Software”, “Service Desk”, and “Business” project types.

Not only are Next-gen projects created by different users but the creation process differs too.  I have a very specific set up process for traditional projects and even a new project configuration checklist.  I’m careful to complete steps in a specific order to avoid extra clicks.

With Next-gen projects, the configuration order is different.  It is:

1. Create the project and select permissions
2. Create board columns
3. Add users
4. Create issue types
5. Create custom fields
6. Connect to other tools

It’s strange to me to configure a board before the workflow, but if the workflow is based on the board (not the other way around) then it makes sense.  Atlassian’s use of Jira is definitely more board-centric than my own.  I’m not a heavy board user; dashboards are more helpful to me.  But that could be because I used Jira before boards had today’s list of features.

The Next-gen boards continue to evolve and improve with new features like:

• bulk issue update abilities,
• column display limits,
• background color changes for “flagged” issues,
• rules – like auto assignment based on status change,
• and visual integrations with dev tools.

Finally, Atlassian shared that the new project model improves performance, stability, and helps prepare them for the next decade of software development.

What will happen to “traditional” projects?

Will development for “traditional” Jira Cloud projects continue?  It’s uncertain.  It sounds like all these new cool features are only for Next-gen projects and won’t be back-ported.  That’s sad but understandable. Essentially they would have to develop the same feature twice, once for each code framework.  That doesn’t make a lot of sense to do – unless customers are clamoring for it.

How do Next-gen projects impact apps and app developers?

To answer this question, I asked ThinkTilt, the maker of ProForma, a forms and custom fields add-on for Jira Server and Jira Cloud.

ThinkTilt said that the Next-gen projects have quite an impact for them and other Marketplace app developers.  Atlassian is still working on supporting apps in the new projects.  Some screens, like the project configuration screens, didn’t appear until recently, meaning many apps didn’t work at all for the new project type.

The next step is for Atlassian to update their APIs so app developers can access the new features of Next-gen projects.  Today, apps can see what has been configured for a project, but there are no abilities yet for doing more, like adding or editing the configuration.  When all the Atlassian pieces are ready, app developers will need to update their apps to make them work well.

Expectations

What are your expectations of Atlassian and their new Jira Cloud experience?  What are the expectations of your Jira admin team or your users?  Share your opinions in the Comments section below.

Learn more about Next-gen projects at:  http://atlassian.com/get-next-gen