In the field of technology, there are two most important project management methodologies i.e. Waterfall and Agile.
Waterfall is a popular project management methodology that refers to the sequential or linear ordering of phases.
Whereas, the term "agile" refers to being able to move quickly and easily. It also refers to flexibility and the willingness and ability to change and adapt. This iterative approach enables the project to move quickly, as well as making it much more adaptive to change.
Agile project management is an approach to project and team management based on the Agile Manifesto.
Agile has been so successful in the software industry that its values, principles, and frameworks have been applied to nearly every industry. In fact, the Agile methods draw heavily on Lean manufacturing principles.
Agile aims to solve that problem by getting customer feedback more quickly. Working with an Agile mindset is always seeking out ways to work more efficiently. We do this by finding ways to streamline processes without reducing product quality or value.
Three important aspects of a project are
Requirements
Documentation
Deliverables.
Requirements are conditions that must be met or tasks that must be finished to ensure the successful completion of the project. A deliverable is a tangible outcome of a project.
Content of the Article
4 values of the Agile Manifesto
The Manifesto for Agile Software Development states:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work;
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
The four themes of the Agile principles with its 12 principles are:
Value delivery, or how do Agile teams deliver highly valuable products to their customers?
Delivering the work as quickly as possible.
Simplicity allows a team to focus and work on the things that matter the most.
Business collaboration, or how do Agile teams collaborate with their business partners and stakeholders to create business value for the organization and their users?
Collaborating with your customers helps the team get critical business information immediately by allowing them to adjust and adapt to any new information instantly.
Team dynamics and culture, or how does a team create and maintain the right interpersonal and team dynamics to deliver value for the customers and the business?
Creating an effective team culture that is inclusive, supportive, and empowering
The team is motivated to do the right thing;
Feels trusted to do the right thing, has the resources and space to work closely together on their goals, and works at a sustainable pace.
Retrospectives and continuous learning, or how does the project learn to continuously increase the performance of an organization and business?
Agile teams continuously learn and adapt to what's working and what's not working for them.
Step back and consider questions like:
How is the team doing? Are the customers happy?
Are there processes we could optimize?
Are our tools working for us?
Are we following the values?
Are we accumulating any debt?
Agile is about delivering value in a world with high degrees of uncertainty, risk, and competition.
Agile works best in industries or projects that are susceptible to or that encourage change and uncertainty.
The US military War College developed a concept called VUCA, spelled V-U-C-A.
VUCA is an acronym that defines the conditions that affect organizations in a changing and complex world.
VUCA stands for
Volatility - Refers to the rate of change and churn in a business or situation.
Uncertainty - Refers to the lack of predictability or high potential for surprise in an uncertain environment.
Complexity - refers to the high number of interrelated forces, issues, organizations, and factors that would influence the project.
Ambiguity - refers to the possibility of misunderstanding the conditions and root causes of events or circumstances
Businesses can apply the concept of VUCA as a tool for determining how best to approach projects.
When we get started on a new project, it's helpful to examine the environment and conditions in which the project exists before we decide the best approach to use.
If your project environment has high levels of volatility, uncertainty, complexity, and ambiguity, then it's a good sign that you should consider an Agile approach.
While an Agile approach is not a perfect solution that will get rid of VUCA, it will lead to better outcomes by giving you and your team tools and systems to mitigate the risks that VUCA presents
SCRUM
The Backlog is the central artifact in Scrum, where all possible ideas, deliverables, features, or tasks are captured for the team to work on.
The Sprint is the name of the time-boxed period in Scrum where work is done.
Daily Scrum, also called the Stand-up. This is where the team meets for 15 minutes or less every day of the Sprint to inspect their progress toward their goal.
Scrum is popular for many reasons. A few are listed below;
Has clear roles and responsibilities for the people on the team while continuously emphasizing the power of the team as a whole.
Regular and predictable meetings and delivery schedules with predefined agendas and outcomes for the meetings, make it easy to teach new team members.
It supports and reinforces the Agile values and principles while adding some structure and foundations that help new Agile teams get started and more experienced teams get better
It's all free and open for all to use, there's also a huge amount of guidance and support online, as well as Scrum-specific training and certificates.
Kanban
The Kanban name comes from two Japanese words. "Kan" means "sign," and "ban" means "board.
The reason Kanban is so popular is that it provides transparent visual feedback to everyone ensuring that the project team only accepts a sustainable amount of in-progress work.
This means the amount of in-progress tasks is limited to what the team can handle during a certain amount of time.
This goal of trying to maximize efficiency is called flow and is a core principle of Kanban.
XP
The XP methodology aims to improve product quality and the ability to respond to changing customer needs. It does this by taking best practices for the development process to extreme levels.
XP activities comprise of;
Designing
XP wants to ensure that all of the pieces of the product will fit together properly.
Coding
XP demands clear and concise code so that others can easily read and understand the program.
Testing
The goal is to test for and eliminate any flaws in a feature before building it and continuing on
Listening
Pair programming refers to when two team members Work together at the same time on one task.
Continuous integration and continuous refactoring is the practice of merging product changes into a shared version several times a day to get quick feedback on the quality of the code or product.
Avoid big designs upfront. This relates to designing and means the design should be just enough to get started and should be continuously improved as the product evolves.
Write tests, not requirements. This means that instead of writing a product requirements document and then later writing a test plan.
Lean
Lean comprises of the following stated inputs
Define value - means identifying and focusing on what the customer wants and including the customer in the process.
Map value stream - means mapping out the process or stream, including all the steps involved in producing value for the customer.
Create flow - means ensuring the product flows through the value stream efficiently, continuing to eliminate waste throughout the cycle.
Establish pull - the customer is pulling on the product or asking for it throughout the value stream.
Pursue perfection - This means pushing your team to continuously improve the first four process steps.
Whereas the waterfall project life cycle is made up of the following phases:
Initiation
Planning
Executing
Completing tasks
Closing out the project
SCRUM 101
The Scrum Guide defines Scrum as a framework for developing, delivering, and sustaining complex products. The Scrum framework is built on the concept of empiricism.
Empiricism is built on three foundational pillars. Those pillars are
Transparency - means that we make the most significant aspects of our work visible to those responsible for the outcome.
Inspection - refers to conducting timely checks towards the outcome of a sprint goal to detect undesirable variances.
The more inspections that take place, the more improvement a team experiences in their work.
Adaptation - means that we're continuously searching for ways to adjust our project, product, or processes to minimize any further deviation or issues.
Although adaptation includes immediate fixes to problems, it may also be about implementing a change so future projects don't repeat past mistakes.
and they're also the three pillars of Scrum.
In scrum, we also have five core values:
Commitment - personally committing to achieving the goals of the Scrum Team.
Courage - Scrum Team members must have the courage to do the right thing and work on tough problems.
Focus - Everyone focuses on the necessary work within the Sprint and the overall goals of the Scrum Team.
Preparedness - For Scrum to work, the team and its stakeholders agree to be open about all the work and the various challenges that come with performing the work.
Respect - Team members should respect the opinions, skills, and independence of their teammates.
For a team to bring the three pillars of Scrum to life, they must act per the five Scrum values.
Agile principles state:
Build projects around motivated individuals.
Give them the environment
Support their need.
Trust them to get the job done.
In Agile, a mission is a short statement that stays constant for your team throughout the process and gives them something to work toward. A mission tells why we're doing the work. A product vision helps us imagine what the work will be like when we're done.
Scrum Team consists of three defined roles:
a Scrum Master
a Product Owner
the Development Team
Scrum Master
Scrum Teams are cross-functional. When a Scrum Team delivers something, it's the accomplishment of the entire team. Scrum Teams are self-organizing.
The Scrum Master promotes and supports the Scrum process by helping everyone understand and implement Scrum.
The Scrum Master's responsibilities are as follows,
Coaching the team members in self-management and cross-functionality
Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done (an agreed-upon set of items that must be completed before a project or user story can be considered complete)
Causing the removal of impediments to the Scrum Team’s progress
Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox (a Scrum concept that refers to the estimated duration for an event)
A small note on The Product Backlog, it is the single authoritative source for things that a team works on;
Product Features
Product requirements
Activities associated with deliverables to achieve the goal of the project
Scrum Master must possess skills like
Organizing
Leadership
Facilitator
Coaching
Manage stakeholders
Product Owner
A Product Owner is tasked with ensuring that the team is building the right product or service.
A Product Owner's responsibilities are listed as;
Continuously maximizing the value of the product delivered by the Scrum Team.
Helping the Scrum Team understand why their work matters within the overall goal and mission.
Prioritize the Product Backlog to optimize the delivery of goals and deliver value to customers.
Ensures that the Product Backlog is visible and transparent to all
Responsible for making sure that the product or service fulfills the customer's needs.
A Product Owner's role requires
Customer-focused
Decisive
Flexible
Optimistic and positive
Available
Collaborative
Development Team
The Development Team is made up of the people who do the work to build the product (size varies from 3 to 9)
Traits of the Development Team
Cross-functional
Self-organizing
Supportive
Customer-oriented
Development Team responsibilities include:
Creating a plan for the Sprint, the Sprint Backlog (the set of Product Backlog items that are selected to be completed during the upcoming Sprint)
Instilling quality by adhering to a Definition of Done
Adapting their plan each day toward the Sprint Goal
Holding each other accountable as professionals
Executing sprints by designing, building, and testing Product Backlog items in increments
Product Backlog
Product Backlog is the single authoritative source for things that a team works on. It contains all of the features, requirements, and activities associated with deliverables to achieve the goal of the project.
Living artifact
Owned and adjusted by the product owner
A prioritized list of features.
The Product Backlog is the guide and roadmap of your product. And consists of the following parts;
The description
The value
The order
The Product Owner may compare the relative importance of items to order each item from highest priority to lowest priority. This is often called a stacked rank.
The estimate
The Product Goal is the long-term objective for the Scrum Team, and it is included in the Product Backlog. The rest of the Product Backlog defines what tasks will fulfill the Product Goal.
User stories
User stories are short, simple descriptions of a feature told from the perspective of the user.
And comprises the following parts;
The user
Action
Benefit
User stories are concise, specific descriptions of a feature told from the user’s perspective. They allow the team to create solutions centered on the user experience and help project managers capture and manage the Product Backlog.
The most common format is "As a user role, I want this action so that I can get this value."
When writing user stories, you will need to include the following elements:
User persona
What is your user like?
What is their relation to the project?
What goals do they have?
Definition of Done
This refers to an agreed-upon set of items that must be completed before a user story can be considered complete.
Tasks
What are the key activities needed to complete the user story?
Any feedback (already provided)
If you are adding features to an existing product and you have already received feedback from customers on a past iteration, make sure to consider this feedback.
I.N.V.E.S.T
There is a method that can be employed to write better user stories and it lies in the acronym of I.N.V.E.S.T
Independent: The story’s completion is not dependent on another story.
Negotiable: There is room for discussion about this item.
Valuable: Completing the user story has to deliver value.
Estimable: The Definition of Done must be clear so that the team can give each user story an estimate.
Small: Each user story needs to be able to fit within a planned Sprint.
Testable: A test can be conducted to check that it meets the criteria.
Epic - which simply represents a group or collection of user stories.
Acceptance criteria - which is essentially the checklist you will use to decide whether the user story is done.
Backlog refinement
Backlog refinement refers to the act of keeping the Backlog described, estimated, and prioritized so that the scrum team can operate effectively.
The Scrum team reviewed the Backlog to ensure:
It contains the appropriate items and nothing new is needed or nothing needs to be removed.
The items are prioritized by the Product Owner, (this is also called setting the order field)
The items at the top of the Backlog are ready for delivery with clear acceptance criteria
The Backlog items include estimates or an informed assessment about how much work a particular Backlog item will be.
Relative estimation
Relative estimation means that instead of trying to determine exactly how long a task will take, we compare the effort of that task, to the effort for another task, and that becomes the estimate.
The following are the two major Agile estimation techniques used in the tech industries globally;
T-shirt sizes
Agrees on the chosen scale and metrics to be used (E.g. S, M, L, XL, XXL, etc)
Identifies at least one anchor backlog item. That item will be assigned a T-shirt size. Some teams will choose two anchor items—one at the top of the range and one at the bottom of the range.
Sorts through the remaining backlog items and agrees on T-shirt sizes for each of them.
Story points
For story points, in general, the Fibonacci sequence is used. The Fibonacci sequence is 0,1,1,2,3,5,8,13, 21 continues to infinity. This is helpful because as the estimate gets higher, the uncertainty and risk also get higher.
Agrees on the permitted points values. Some teams cap the size at a certain number, like 21. Some teams decide to jump from 21 to 100 as the next larger value. This is a team decision.
Identifies at least one anchor backlog item and agrees to assign it a points value. Some teams will choose two anchor items, one at the top of the range and one at the bottom of the range.
Sort through the remaining backlog items as a team, agree on an estimate for each item, and capture it in the backlog management system.
Further are a few more examples of Agile estimation techniques:
Planning Poker™
It is consensus-based, meaning that everyone has to agree on the number chosen. In this technique, each individual has a deck of cards with numbers from the Fibonacci sequence on them.
Everyone turns their card over at the same time and the team discusses the estimates
Helps in avoiding the bias
Dot Voting
Team member starts with small dot stickers, color-coded by the estimated effort required (e.g., S=green, M=blue, L=orange, XL=red).
The Bucket System
Large/Uncertain/Small
Ordering Method
Affinity Mapping
Characteristics of effective estimation
Avoids gathering false precision of estimates.
Avoids anchoring bias
Promotes inclusivity
Leads to effort discovery
SCRUM's Working
Within a Sprint, the amount of work is planned based on the historical capacity of the team and is made ready for the Sprint Planning event.
The Scrum Guide technically defines five events:
The Sprint itself
Sprint Planning
Daily Scrum
Sprint Review
The Sprint Retrospective
Timeboxes are an important concept in Scrum, whose importance is as;
Create a sense of urgency that will drive prioritization
Provide a window of focus that improves productivity
Help the team develop a predictable rhythm to their work
Defining the sprint
First, think about what you expect the frequency of changes to be
Second, think about how much focus time your solution developers might need to build a Backlog item
Third, think about how much overhead goes into the delivery of your product
Sprint Planning, the entire Scrum team comes together and meets to confirm how much capacity, meaning time and people, are available during this Sprint. This becomes the Sprint Backlog, and ultimately, the Sprint goal.
The definition of Done refers to an agreed-upon set of items that must be completed before our user story or Backlog item can be considered complete.
The solution itself is reviewed by an independent peer group.
The product or unit passes all testing requirements, which could include security or performance testing.
Documentation is completed.
All user story acceptance criteria specified by the product owner are met.
The product owner accepts the user's story
The Sprint Backlog is the set of Product Backlog items that are identified for completion during the upcoming Sprint.
Daily Scrum, which is sometimes referred to as stand-up, is a time for the Scrum Team to synchronize and prioritize activities for the day.
What did I do yesterday that helped the Development Team, meet the Sprint goal?
What will I do today to help the Development Team meet the Sprint goal?
Do I notice any impediment that prevents me or the Development Team from meeting our goals?
The Sprint Review is a meeting with the entire Scrum Team where the product is demonstrated in order to determine which aspects are finished and which aren't, as
An exploration of which items should be considered done in the Product Backlog
Demonstration and inspection of the product.
Besides it further helps in;
Make the feedback as immediate as possible.
Everyone has a voice, leading to a shared sense of ownership of every aspect of the product launch
The team learns more about how the marketing teammate does their job, leading to greater trust and understanding between team members.
The Product Increment is what's produced after a given Sprint and is considered releasable.
A product is releasable when the team has developed a Minimum Viable Product, which has a set of implemented features or requirements.
A Minimum Viable Product is a version of a product with just enough features to satisfy early customers.
So can a releasable increment be an MVP? Yes! Does it always have to be an MVP? Not necessarily.
The Sprint Retrospective is an essential meeting of up to three hours for the Scrum Team to take a step back, reflect, and identify improvements in how to work together as a team.
What's working or not working for the team regarding the people, the processes, and the tools?
What improvements are worth exploring in the next Sprint?
What improvements were put in place for the last Sprint? Were they helpful or not, and why?
Successfully conducting a retrospective is considered if;
Blameless
Participation is key
Balance the negative with the positive
Act on it
whereas Pitfalls are;
Avoid too many gimmicks.
Try not to only focus on the negative.
Avoid changing processes after each retrospective.
Best practices of Scrum
The following lists a few best practices that can be employed while conducting scrum;
Ask open-ended, probing questions.
Consider diverse styles of communication and participation.
Cover the many aspects of the Sprint when conducting a retrospective.
The productivity and efficiency of the team.
The scope and understanding of the definition of done.
Communication and interactions within the team.
Stakeholder communication.
Progress towards more long-range release plans.
Consider reflecting periodically on Scrum theory and values by asking specific questions.
For example, ask, “How could the team become more transparent?” or “How did we abide by our Scrum values in this Sprint?”
Scrum Tools
A burndown chart measures time against the amount of work done and the amount of work remaining.
Velocity is a measure of how many points a team burns down during a single Sprint on average. When the team is conducting Sprint Planning, they're using their average velocity over at least three Sprints to determine how many items they can safely add to their Sprint Backlog.
It helps in -
How long it will take to complete the entire Product Backlog
How much of your Backlog will be completed by a particular time?
Using velocity for good
DO - Be careful when sharing velocity with external stakeholders
DON'T - Use velocity as a performance metric
DON'T - Use velocity as a comparison metric
DO - Proceed with caution when using velocity as a metric for project delivery date
Three main features that make it a great Sprint tracking tool for Scrum Teams.
Visualization.
Work-in-progress limits (also known as WIP limits)
Common WIP limits are constraints on how many work items the team actively works on at any given time.
Flow of work.
Maximizing value-driven delivery
The term "value" can mean different things for each customer based on what they expect the product to accomplish.
"value-driven delivery" means you and your team are focused on delivering a product of high value.
What are those?
Build the right thing
Understand what your customers want.
Build the thing right
Ensuring that your team only builds the requested or approved features
Run it right
Your team has thought through how the user will interact with the product once it's been delivered.
Ask the following questions:
How do users get support?
How does the product add value to users long after they initially received it?
How do you make sure that new features and capabilities reach the existing users?
Roadmaps
Value Roadmap
It's an Agile way of mapping out the timelines and requirements for the product development process and can be used in all types of businesses.
This roadmap is a guide that demonstrates;
Where to go, how to get there, and what to accomplish along the way to maximize value
Helps the team explain the vision of the product
Used to identify important milestones
A typical value roadmap has three components:
A product vision
What the product is?
How it supports the customer's business strategy?
Who will use it?
A product roadmap
A high-level view of the expected product, its requirement.
Estimated schedule for reaching milestones.
The release plans
Release goal.
List of backlog items.
An estimated release date.
Any other relevant dates that impact a release.
Product Roadmap
The product roadmap provides a high-level view of the expected product, its requirements, and an estimated timeline for reaching milestones. With the following aspects;
Ensure that product release dates are only rough estimates.
The Product Owner and Project Manager or Scrum Master work together to develop each release plan.
This is because the release plans need to connect the product roadmap with the team's capacity and velocity.
Factors any hard dates or deadlines on the roadmap
The Scrum Master or Project Manager should always review the release plan before starting a Sprint planning session.
Common factors that may result in a change to the release plan;
Change in team velocity.
Change to the product scope.
Improving the understanding of how much effort is needed to build certain features.
Understanding organizational culture and the change management process is crucial when introducing new ways of working.
Organizational culture is based on
Shared workplace values comes up in people's behaviors, activities, and the way they communicate
How they work with each other?
Change management is the process of getting folks to adopt a new product, process, or in Agile's case, a new value system.
Change takes patient persistence.
To create a sense of ownership is to;
Find an executive sponsor who also feels a sense of ownership for the change you're creating
Having buy-in from someone at the top increases your chances of successfully driving any change in organizational culture.
To creating a sense of urgency;
Asking the team, the organization, and the stakeholders questions about what's working and what's not working right now.
What is preventing us from providing the best possible product to our customers?
What is allowing our competitors to outperform us in this market?
How can we help our teams become more productive and supported in their work?
Influence and Coaching
Three keys to influence make up the influencer change framework and will improve the chances of success with a change.
Clarify measurable results
Find vital behaviors
Leverage six sources of influence in tandem to lead an organization, team, or individual to experience positive change.
The six sources of influence are stated as;
Personal motivation: Are the individuals motivated internally to engage in the new behavior? Can you help them “love what they hate”?
Personal ability: Are the individuals capable of performing the behavior? Do they have the ability, knowledge, and skills to “do what they can't”?
Social motivation: Are there social contacts or networks encouraging or discouraging this new behavior?
Social ability: Does the team have resources within their social network to help them carry out the new behaviors?
Structural motivation: Are there rewards or incentives that they will receive if they perform the new behaviors?
Structural ability: Are there environmental factors at play that either deter or support the new behavior? Can you make the incorrect behavior harder to do than the correct behavior?
Agile Coaching
The aspects of agile coaching are;
You'll design the "plays" with the team.
You'll provide feedback to the team.
You'll celebrate and learn with the team.
Managing and coaching are distinct leadership approaches that each yield different results and both styles require effective communication.
A managing style typically utilizes one-way communication to assign tasks and give directives. Coaching relies on open communication in both directions to help develop an employee’s or team’s skills, so they can become self-sufficient.
Some team members and company cultures will naturally favor one style over another, but both are necessary leadership skills. As an Agile project manager or Scrum Master, will use both styles. That said, in Agile and Scrum, a coaching style is usually the best initial option since it will increase the capabilities of the team, leading to more agility over time.
When deciding which approach to use, ask yourself:
What is the desired outcome?
What is the skill level of the team member who has encountered a problem?
What does the situation need now to reach the desired outcomes?
Agile Challenges
Value delivery, which is about making sure the team is delivering working solutions frequently. If issues or challenges are faced at this juncture, you can opt for following solutions;
Do more Demos of the solutions with the team.
Make sure that everyone understands what "done" means.
Focus on only a few user stories per Sprint.
Business collaboration is about making sure that developers are collaborating with business people on how to build the right product.
Issues -
You might notice that the team is overwhelmed with critical feedback or change requests.
"Us versus Them" mentality between the team doing the work and management.
Solutions
Addressing critical feedback and change requests by doing more demos.
Conducting a Solution Design Sprint
Ensuring changes to the Backlog are introduced only in between Sprints.
Team dynamics and culture. Human beings are complex creatures with lots of different motivations and styles of working
Issues
Low team morale
Lots of conflict
Low conflict
Solutions
Run a team brainstorming session
Change up the workflows
Take a training class together
Common Agile Coaching Challenges
Managing a stable product roadmap
Product Ambition
Product ambition poses a challenge when product leadership is overly ambitious about what the team can realistically deliver. Solutions;
Agreed upfront on how to handle new opportunities
Setup regular roadmap reviews with the entire team
Promote sharing knowledge between the Product Owner and the Development Team
Product Assumptions
Solutions for it;
Document the assumptions and make them transparent
Unbiased user research
Gathers information about what users really want.
It allows you to confirm
Reject assumptions and help you move forward with confidence.
Incomplete implementation of Scrum
Issues
Lead to a loss of clear roles and responsibilities.
Tempted to skip some events or blend them to save time
Not providing the team with the Scrum coaching they need
Solutions
Implement Scrum completely
Make sure roles are well-defined and properly fulfilled
Experiencing a lack of stability within the team.
Issue > Change in team composition
Solutions
Quick onborading
Use pair programming
Have shorter sprints
DevOps and Business Agility
Google Cloud Platform Business defines DevOps as an organizational and cultural movement that aims to increase software delivery velocity, improve service reliability, and build shared ownership among software stakeholders.
DevOps is about growing and managing teams and organizations that can build and evolve large-scale systems at a rapid pace.
Business agility, which involves incorporating Agile principles into the wide sphere of management. They have the following agile methodology types;
Scrum of Scrums
Scaled Agile Framework, also known as SAFe
Scaling Agile
Explore five frameworks that scale the Agile approach to address the needs of large initiatives or solutions:
Scaled Agile Framework (SAFe)
Scrum of Scrums
Large Scale Scrum (LeSS)
Disciplined Agile Delivery (DAD)
The Spotify Model.
Best practices for scaling Agile
Treat scaling models like SAFe, Scrum of Scrums, LeSS, etc., as general frameworks, not instruction manuals.
Different situations require different solutions. It’s okay to mix and match elements from multiple frameworks, as long as you apply the principles and values of the Agile Manifesto.
Don’t try to scale without prior Agile experience. Going straight from Waterfall to scaled Agile can be risky without a knowledgeable guide.
Finally, and most importantly, don’t scale if it isn’t necessary. The larger your team, the more complex and difficult your project becomes.
To further read related articles please check the links below;
Source