Inforce Q&A

Team 1:

Each day can vary significantly based on current client needs and schedules. However, a typical structure might look like this:

Calendar & Meetings:

 First, I review my calendar for any meetings or important deadlines that day. This helps me allocate my time effectively and prepare any necessary materials in advance.

Ticket Review & Prioritization:

I check for new tickets or tasks. If there are new ones, I assess their priority level. High-priority tickets take precedence over ongoing medium- or low-priority tasks.

If no new tickets have come in, I continue to work on existing tickets or any backlog items in my queue.

Execution:

I focus on the most pressing tasks first, ensuring consistent communication with the rest of the team about progress or blockers.

End-of-Day Wrap-up:

I note any pending issues or next steps, update relevant documentation, and brief the team or project manager on the day’s accomplishments

Team 2:

Team 1:

Personal & Shared Repositories

Personal Organization:

 I store frequently used queries or scripts in a dedicated file (e.g., “Useful Queries” in Notepad++). This makes it quick and easy to retrieve common code snippets or data queries.

For business or domain knowledge, I rely on a central note-taking tool such as OneNote or Confluence, ensuring that new insights are documented for future reference.

Team/Company-Level Organization:

 We track all tickets and tasks in a shared Google Sheet or a project management tool (like Jira). This sheet contains information on the ticket’s status, associated SCR (Software Change Request) numbers, and other relevant metadata.

This shared approach ensures everyone has visibility into progress and current priorities, minimizing duplication of effort.

Team 2:

We use OneNote. We use different pages within OneNote for ticket analysis and for work done on those tickets. We are also using folder structuring for specific documentation. 

Team 1:

Typically, for quick reference, we label notes by Ticket Number. This ensures that all relevant details, code snippets, and clarifications tied to a specific ticket are contained in a single place.

 For larger or more complex projects, some teams use a multi-level structure such as:

• Project Name (e.g., CAP-API)
• Feature Area / Module
• Ticket or Task Number
• Sub-Tasks / Notes

This hierarchical approach helps in quickly navigating documentation and correlating it to specific tasks or areas of the system.

Team 2:

We use one notebook with different sections and different pages for each ticket. 

Team 1:

Client Updates:

We provide regular updates regarding completed tickets and the current status of ongoing tasks. If a ticket is finished, we notify the client, highlighting what was done and any next steps.

Internal Sync Meetings: 

We hold regular internal meetings where each team member shares:

• Completed tasks
• Current tasks
• Upcoming tasks
• Any blockers or impediments

This helps keep Luna (our Project Manager) and the rest of the team aligned. Luna consolidates our updates to ensure the client receives clear, consistent communication.

Team 2:

First, we internally discuss with our team lead if we have any questions. Then we ask those questions on client calls, via Jira ticket comments, or emails. For greater transparency, it is always recommended that communication be in written form. 

Team 1:

Knowledge Transfer (KT) Sessions:

Senior team members or subject matter experts provide structured overviews of the project, including business and technical requirements.

Shadowing:

The new member shadows more experienced colleagues during ticket resolution, client calls, or design sessions. This hands-on approach allows them to learn the nuances of the project.

Documentation Review:

The new team member is directed to internal resources like OneNote, Confluence pages, or Google Sheets, where we document frequently asked questions, workflows, and key architectural details.

Team 2:

Team 1:

Just as with onboarding new members, the departing team member organizes a series of knowledge transfer and shadowing sessions. They walk the remaining or incoming teammates through ongoing tasks, highlight upcoming milestones, and clarify any complexities that may not be fully documented.

Team 2:

Mostly by shadowing a team member who is already familiar with the system and analyzing the tickets. 

Team 1:

Evolving Requirements:

Sometimes, clients change requirements mid-sprint. We address this by maintaining close communication, re-estimating work when needed, and adjusting priorities in real-time.

Unclear Expectations:

If the client’s vision for a feature isn’t fully crystallized, we schedule clarification calls or workshops to refine requirements.

Technical Constraints:

Legacy systems or strict compliance environments can slow down progress. We manage this by planning more thorough testing and ensuring that architectural decisions consider these constraints early on.

Communication Gaps:

Working with international or cross-functional teams can introduce misunderstandings. Regular syncs, written summaries, and an open-door policy for questions help mitigate these issues.

Team 2:

Team 1:

Overall, our experience regarding accessibility has been positive. The client team is responsive and available for clarifications. If any delays arise (e.g., time zone differences or conflicting schedules), we address them by scheduling calls in overlapping hours and agreeing upon response-time expectations.

Team 2:

It varies from person to person, but usually, we do not have any serious problems. 

Team 1:

In most cases, the client is quite accommodating and understands that certain tasks require sufficient time and resources. However, if we see that a deadline may be unfeasible or if last-minute changes are introduced, we proactively communicate the need for extended timelines or additional resources to maintain quality.

Team 2:

This depends on the complexity of the ticket. We usually have several tickets scheduled for a release. It happened that a ticket could not be finished on time, so it was moved to the next release.  

Team 1:

Our team typically has clearly defined roles, such as:

Project Manager / Team Lead (e.g., Luna/Nenad) – Oversees priorities, manages client relationships, and coordinates resources.

Developers – Each developer has a primary focus area, but we also cross-train to ensure coverage.

QA – Focus on validating solutions, and ensuring that product increments meet the acceptance criteria. While many of us have overlapping skills, each member typically has a “go-to” specialization, ensuring that tasks are efficiently allocated. However, we strongly encourage knowledge sharing, so that no single person becomes a bottleneck.

Team 2:

Tasks are usually divided by priority, but if someone has already worked on a similar or related issue, they continue working on that.