Building an application is quite challenging. It’s not just about writing code.
Most of the time Teams struggle to understand the product vision. They focus on what the ticket says and the product vision is often not achieved.
This happens for many reasons, but it can all be boiled down to Communication Issues.
What do I do?
I work as an independent contractor offering my expertise as a Team Coach and Technical Advisor to help companies and development teams improve their processes and workflows to build better applications.
If your team is struggling with any of these topics, you can Contact Me 🙋🏻♂️ to schedule a call if you’re interested in hiring my services.
What I Offer as a Team Coach
My experience has taught me that most teams can improve their performance by understanding their skills and weak points. With that awareness, they’re better prepared to face new challenges.
This awareness is especially important when the team is debating new features ideas with the Product Owner. This will improve the delivery of quality work while hitting the required milestone.
But it’s not just about getting the team to work better. The company needs to understand the process and give the team the tools and trust they need to become a team that works on a product and not a team of developers.
As a Team Coach I focus on training teams that can:
- Increase team productivity by improving communications, organization, and planning.
- Design/improve their workflow: Communication + Technical skills.
- Focus on the product.
- Deliver persistent quality work.
- Learn to detect issues in early stages and communicate them before they arise.
- Give accurate estimations for their tasks.
- Timely delivery and milestones achievement.
- Be able to detect and fix team organizational issues quickly.
To help teams improve their workflow by using Scrum, I split the journey into two main stages.
The first stage is the Discovery Process where I join the team as an observer. I meet with every team member, and then with the whole team to understand the dynamics and how the team essentially works.
After the Discovery Process I deliver a document with the findings and recommendations of that observation period.
The second stage is Coaching and Mentoring where during a period of time I work on a daily basis with the team to help them improve their usage of the Scrum Methodology along with communication and decision-making skills to become a fully independent team.
It’s not just about using Scrum. It’s about helping the team to find the right balance between their skills and communications abilities to work as a solid unit.
What I Offer as a Technical Advisor
I’ve been building web applications for more than 12+ years. During this time I’ve used many different technologies in many of the projects I worked on.
This has made me an expert in the field. You can check my LinkedIn to know more about my background.
As a Technical Advisor my main goal is to help companies to come up with tailor-made solutions for their needs and solutions that match the skills of their teams.
Sometimes teams don’t have enough expertise to deploy and maintain a state-of-the-art infrastructure design.
But that doesn’t mean you can’t start with something more simple, yet effective, and achievable and then move forward into a more advanced solution.
A typicall example is this post on how Digital Ocean used MySQL as a message queue handling 15,000 connections for years.
It shows how you can work with old tech stacks or solutions and be successful and redesign when you’re ready to do it.
About my experience
I’ve been developing applications for more than 12+ years. In the last 5+ years, I had the opportunity to take on the role of Tech Lead and Team Leader for a multi-cloud billing and infrastructure platform.
I was given full control over the team development process and technical decisions. This meant hiring the team members, organize them and lead them from the first day.
During this process, I was able to improve my skills in decision making and becoming a successful Team Leader.
I spent most of my time helping the team understand the product features, technologies issues and improving our workflow as the project grew.
As a result, I was able to establish a fully independent and confident team that was able to build what the product needed and not just what the ticket says.
The team and I were new to Scrum but we managed to master it and we continued to make changes every time something didn’t work out anymore.
You can read more about it on my post Agile Scrum in real life 🧑🏻💻
I’m a certified Scrum Master (Credential ID 000588432)
Areas where I can provide help
M.V.P (Minimum Viable Product)
Starting with your product vision, you need to be able to identify what’s the core value that you’re offering and come up with an MVP as your first step.
This requires a deep analysis and planning to define the scope of the MVP.
Team Organization (Scrum)
Using Scrum as a methodology and framework in your team is not as easy as: follow the rules.
Scrum gives you tools to organize a team but nothing more. Teams need to be guided to become a unit.
Every team member must be aware of their technical and communicational skills so that the whole team can discover the right balance to work in a harmonic and predictive way.
In my experience the are a few issues that need to be quickly addressed when building a team:
- How many developers and how experienced should they be?
- Finding the right way to use Scrum on your team.
- Help them to establish clear ways of communication.
- Make sure everyone understands the vision of the product.
- Give them time and guidance to come up with new ideas and solutions.
- Keep improving the team workflow and help them find the best one for them.
Writing the user story
Having a well-defined user story it’s not just a good way for your team to know what to do.
It’s important to have well-written user stories because it forces you to think about the feature that you’re trying to build. This ensures that you don’t steer away from your product vision.
User stories are not written in a few minutes. You need to discuss the feature, analyze the technical difficulties, dependencies, and how to implement it with the knowledge that you and your team have.
Defining tech stack
A crucial part of the process of building an MVP is to choose the right tech stack. For this you need to take into consideration the following:
- How well do you and your team know the technology that you’re planning on using?.
- How expensive will it be?.
- How hard is it to keep it running smoothly on production without investing a lot of time when something fails?.
Microservices, Monolithic or Serverless?
This decision is quite similar to the tech stack definition.
Choosing one of these designs opens a lot of challenges and complexity for the future and should be addressed carefully in the decision process.
It might look trivial at first, but this should be defined before writing any code. Having well-defined rules on how endpoints will work will save you a lot of trouble in the future.
Developing and writing code
- Using a code repository the right way: Branches, commit messages, code review, merge requests, etc.
- Logs: What, how, and where.
- Configurations: Managing secrets. Correct use of environmental vars. Prevent environment overrides.
- Unit testing: Prioritize what to test.
- QA Process.
Setting up your environments
- Fully-managed cloud services vs self-managed.
- Setup your environments correctly: Dev, QA, Pre, and Production.
- Deployment process.
- CI/CD: When, why, and how.
- Scalability and High Availability.
- What to monitor.
- How to act when something fails.
- Monitoring and observability.