Connecting the Dots: Different Project Types, Same Best Practices

Revelry’s product managers and software engineers contribute to various types of development projects, depending on partner needs. To help our latest cohort of apprentices better understand what this means, we took some time to review and answer questions about: 

• The different project types they may experience;
• What to expect with each; and 
• Best practices that support productivity and positivity from start to finish – no matter the project type.

Here’s some of what was shared and discussed:  

Project Type: Greenfield

A greenfield project refers to a project that’s started from scratch, without constraints from existing systems or prior work. 

What to Expect

With Greenfield projects, there’s:

• No legacy code: Engineering teams get to choose the most current and appropriate technologies
• No existing infrastructure: We set up entirely new environments, databases, and servers tailored to the project’s needs.
• Freedom in UI and UX design: There are no pre-existing architectural decisions or integrations that need to be accommodated.
• Potential for higher intensity and longer time-to-market: Building everything from the ground up can be more resource- and time-intensive. 

Question from the Crowd

What are some things we consider when deciding on technical direction? There are a number of important factors to consider, like:

• Project requirements and goals (both short-term needs and long-term vision)
• Integration capabilities
• Performance and scalability
• Security requirements
• Cost (both initial and for long-term maintenance)
• Performance metrics and monitoring
• Team expertise and availability of libraries, tools, and resources

Project Type: Brownfield Project 

A brownfield project is one that involves working with an existing software system or codebase. 

What to Expect

Brownfield projects typically involve:

• Maintaining and updating legacy systems
• Integrating new features or functionality into an existing digital product
• Refactoring or modernizing old code
• Migrating systems to new technologies or platforms

Challenges of brownfield projects can include:

• Dealing with outdated technologies or programming languages
• Working with poorly documented or structured code
• Managing technical debt accumulated over time
• Ensuring compatibility between new and existing components
• Navigating complex dependencies within the system

Questions from the Crowd

How do we decide when or what to rewrite/refactor? These decisions require us to consider three things: technical debt, business value, and resource allocation. We usually begin by looking at the current state of the software. Specifically, we look at code quality, maintainability, and technical debt; analyze performance metrics and scalability issues; and review bug frequency and severity. 

How do we balance technical debt with new functionality, etc.? This can be complicated, so we rely on a process in which we:

• Assess and categorize technical debt
• Prioritize new functionality (value vs. urgency)
• Create a balanced backlog
• Set debt limits
• Consider resource needs
• Integrate debt reduction into feature work
• Measure and monitor
• Plan for the long term (and regularly reassess)
• Use a risk-based approach
• Make the most of automation, like CI/CD
• Encourage a quality-focused culture (See something, say something)

Project Type: Staff Augmentation

A staff augmentation project is a project in which a partner has hired us to supplement its existing engineering team for specific projects or tasks. This approach is often used when:

• A project requires skills that the partner doesn’t have available in-house
• There’s a temporary increase in workload
• A partner wants to explore new technologies without long-term commitment
• There’s a need to reduce time-to-market for a product

What to Expect

Staff Augmentation projects often mean:

• Shorter-term engagements, frequently less than a year
• Integration with an existing team, working alongside the partner’s permanent engineering team
• A quick ramp-up, including learning the partner’s existing codebase, tools, processes and key stakeholders 
• Varied tech stacks
• Different workplace cultures
• An opportunity to work with diverse teams and different industries and business practices
• Some staff augmentation roles may lead to full-time opportunities.

Question from the Crowd

How do we decide when to challenge existing processes and technical perspectives? Our partners work with Revelry because they trust us to deliver the best solutions in the best possible ways (leveraging our proven Lean Agile process). While not all suggestions will result in change, it’s important to share perspectives, preferences, and experiences; they’re paying us for this expertise. As with all things, just be sure to engage with clarity, respect, and humility, no matter the outcome.  

Project Type: Team Augmentation (Team As A Service)

Team augmentation is a lot like staff augmentation, but with some important differences. Both are strategies for super charging an internal product team, but team augmentation typically involves bringing in a more cohesive group that has experience working together. This approach is often used when:

• A partner needs to quickly ramp up development on a large project
• There’s a need for a diverse set of skills that work well together
• A partner wants to introduce new methodologies or technologies
• There’s a desire to improve team dynamics and collaboration within the existing, in-house team.

What to Expect

Team augmentation projects typically involve:

• Self-management: We largely adhere to our own internal structure and management, with limited direct oversight from the partner.
• Internal and external collaboration: Our team works alongside the partner’s in-house team, often integrating their processes and culture with ours.
• Diverse backgrounds, beliefs, and skill sets: Combining a Revelry product delivery team with a partner’s in-house team can result in a wide range of complementary skills and roles, creating awesome opportunities for learning, sharing of knowledge, and problem solving.
• Longer-term engagements 

Question from the Crowd

How do we get on the same page with our partners about what engineering standards and processes look like? This can differ from project to project, and we often need to find compromises, but you can help create alignment by:

• Communicating early and often about the importance and benefits of adhering to engineering standards. (Standards are also a part of our earliest discussions with potential partners.)
• Find a balance between best practices and partner needs, if needed.
• Document agreed upon standards, making sure your documentation is available and understandable to non-technical stakeholders. It can also be helpful to emphasize how standards support partner objectives, like faster time-to-market, reduced maintenance costs, etc.
• Establish measurable indicators of code quality and standard adherence, and report on these metrics regularly to show progress
• Schedule periodic alignment meetings to discuss standards and their impact, and to address any concerns

Project Type: Scoped Ownership of Part of a Product

Scoped Ownership of Part of a Product means specific individuals or teams are given primary responsibility and authority over certain components or features of a larger software product. It’s often used with complex solutions, where dividing responsibilities can lead to more focused development and maintenance. 

What to Expect

• Clear boundaries: Each individual or team owns a specific part of the product.
• Autonomy: We have significant decision-making power within our scope.
• Accountability: We are responsible for the quality, performance, and maintenance of our components.
• Collaboration: While we have primary responsibility for a specific part of a product, we still work with other teams for integration and overall product coherence.
• Continuous improvement: We must remain focused on optimizing and evolving components and features within our scope. 

Question from the Crowd

Which engineering standards need to be upheld across all projects? Engineering standards help ensure quality, maintainability, and efficiency in all Revelry projects. Each must be seen as necessary and valuable, and upheld as often as possible.

• Version control
• Code review
• Automated testing
• Continuous integration (CI)
• Thorough documentation
• Security (best practices, audits)
• Database management
• Monitoring of code quality
• Performance monitoring
• Error / bug handling
• Deployment and maintenance processes

Best Practices for Use with All Project Types

• Before we spend time creating / implementing any solution, we agree:
  • On the problem(s) we are trying to solve and who we are solving it for 
  • On specific tasks the end-user should be able to accomplish in a simple and intuitive way
  • To keep asking questions and stating assumptions until we are confident everyone is on the same page
• We call our shots and document our plans.

• We work “in the open,” meaning we tell each other what we’re doing, how it’s going and if we’re blocked.
• We ask for help, knowing we can reach out to anyone on our team at any time.
• We do our best to make it easy for someone else to pick up what we’re putting down by showing our work.
• We reflect on what’s working and what can be improved upon.
• We ship gold.
• We revel in victory.

Have a project and need support? We’d love to help you achieve your goals. Connect with our team.

---

Engineering Process Product Management Project Management