A Process for Keeping the Team Aware of New Features

Ticket to log time

Hello, @team!

A few weeks back I was doing a discovery for AutoDesk on anonymous unit access, and after having done a good amount of discovery on the matter, I was informed by @usman that we already had a working implementation created for Cloudera. He told me as I was going through a long exposition, trying to wrap my mind around the problem.

Needless to say, the conversation halted and I had to reconsider my discovery and approach in light of this new information. I also found out that no one else working on the AutoDesk discoveries knew about this feature at the time. I then realized that as a team we’ve now gotten big enough that we don’t all have a good view of what everyone else is working on and what features we’re delivering. Worse still, this isn’t even the first time something like this this has happened to me here-- I’ve found out about entire repositories too late in the game to use them.

I’ve come up with an idea that I think will help:

I’d like to propose that epic owners, as part of closing out an epic, write an announcement post going over new features/applications/repositories that have been created, and what applications they might have.

I think this idea has merit, because it helps an epic owner summarize his or her own work, which can be useful when communicating here and to the public, and since we’re going more open-first, it gives more public view of what we’re contributing.

It also can be added to existing procedures without being a separate thing to remember-- there’s already a procedure for closing out an epic, so this can be added on to that.

It also serves the purpose well of propagating familiarization with our capabilities throughout the group. Even if newcomers arrive after the post, if they’re running into a problem we’ve already solved, someone on the team is much more likely to be online and be aware of the existing solution because they’d have been keeping up with the announcements.

What do you guys think?

8 Likes

I agree with the evaluation of the problem. And I think the solution you propose is good in principle: put the info somewhere searchable, with as many search-engine friendly words as possible. And the implementation, during close-out, would work well for many epics… But only up to a certain size.

For projects the size of LabXchange, for instance, doing it once upon delivery would be a whole epic in an of itself. Not very practical.

Which is why I like the idea of ADRs. Document things up front, even before implementing them, and also somewhere public where search engines can find them. You can have multiple documents per project. For small epics, maybe a single one. For LX-size ones, probably many dozens.

As for being able to find them… In this section of the Publisher blog post, I explain why comments don’t work by default. To find out I looked at the code but was still puzzled, so I googled for “edx publisher salesforce”. The first hit is an ADR that got me on the right track.

So… basically your idea, but done up front (and during), instead of at the tail end.

1 Like

I like this, but I feel like it’s missing one key feature of the forum posts-- which is that the knowledge of these features/decisions is more likely to propagate through the group and raise group awareness of features. Maybe we could announce the ADRs as well and link to them with a brief summary of what they contain? That would also help with their SEO.

+1. Maybe even have an #adr-notifications on Mattermost, like edX has on Slack.

2 Likes

We also need to be doing more regular tech talks to share things you’ve learned and things you’ve built! In the last year, we’ve only had one but I’d like to see them closer to monthly than annually.

4 Likes

The new process is now merged and is available here!

1 Like