This post aims to explain how a WyeWorks’ team works. It outlines the most important values and behaviors, what we expect from a team, as well as the process they follow in order to meet those expectations.
In our years of experience, we’ve come to realize that great talent only takes you so far, but if you want to go beyond talent alone is not enough. In the book “Talent is Overrated”, author Geoff Colvin argues that deliberate, methodical, and sustained practice is the way to achieve true mastery. With our playbook, we wrote down the framework we follow to perform that deliberate practice.
Everything starts from how the team is formed. We put a lot of thought into forming balanced teams whose members complement each other on several skills and competencies, in order to provide high performance teams that are able to deliver the best value possible according to each client’s needs.
Every engineer is needed and expected to bring their strengths to the table, having a positive impact on the overall output of the team. Some people have more attention to detail than others, some communicate ideas better, others may inject energy due to their joyful personality. We’re all different, and that’s ok. We take all this into consideration and then promote having healthy team dynamics to foster their self-organization, resulting in a greater combined outcome than just the sum of the separate individual contributions.
It’s important to note here that all our engineers are assigned to a single project, in order to achieve the necessary level of focus and involvement to become the business partner we aim for with our clients.
The underlying foundation guiding our behavior and every decision we make is, of course, our values. Here’s a nice blog post on them, but long story short is that every member of the team practices the following statements:
- I do my best and aim higher everyday 🚀
- I embrace new things and see opportunity in each situation that comes along ⭐️
- I support the growth of those around me 🌱
- I care about others and try to put myself on their shoes ❤️
- I assume good intentions 🙏
- I have a great time with everyone 🎉
In addition, communication is a crucial aspect to consider when working alongside people around us, since it is present in every task of our day to day. Maintaining an open and fluid channel is the best way to showcase our work and manage expectations. At the same time, we are honest in acknowledging our shortcomings and the things we don’t know.
We value kind, clear, honest, timely and frequent communication. This kind of communication is what enables us to build long trusting relationships with our clients and become their business partners.
Our engineers have developed a love and understanding of agile methodologies that empowers them to be the change agent needed to take the processes to the next level. Our flexibility helps us in plugging into an existing team in a seamless fashion while we familiarize with the current team dynamics, so we can suggest the best practices that are most suitable for the current scenario. We are also often praised by our ability to identify and analyze the requirements needed to move the product forward without the need of micro-management.
Starting a new engagement is a big deal for us. We want our ramping up to be fast and smooth, in order to add value from the very beginning of our relationship. To accomplish this, we carry a series of activities to gather as much information as possible, the most notorious one being a team foundation meeting. This meeting is crucial to ensure everyone has all the information needed and is on the same page. Usually, we have an overview of the product and the roadmap ahead, business priorities, as well as the first team agreements on how we’re going to collaborate.
We then discuss and align on why we are taking part in the project. What would be our purpose and goals working on it? What’s our mission there? Having those conversations fuel our motivation in a way that we truly engage and deliver our best as a result.
We don’t believe that a single process is right for every possible scenario, but rather different things work according to different contexts. Our experience working with multiple clients has shown us that every team is different, hence different strategies work better than others. We have had teams using Scrum, teams using Kanban, or even teams using a mixture of those two. That is why our approach is usually to immerse on the client’s process as it is, and only after we see and understand the dynamics that take place we start making suggestions on how to make things more efficient.
That being said, if there’s no process in place we can start using a “by the book” Scrum process to get things going, and iterate over there. This means, for teams between 3 to 9 people, we divide the work in 2-week iterations called sprints as described here by the Scrum Alliance.
Ceremonies that we’ve seen add a lot of value when properly held are:
- Backlog refinement: to ensure that the backlog has enough well-defined user stories ready to be planned for the next sprint. In this meeting the team gains context of the roadmap ahead, and is able to provide technical input and split big projects coming down the pipeline, helping product owners to manage the backlog.
- Sprint planning: to make sure everyone in the team knows what needs to be worked on during the next two weeks and their priorities. The expected output is the sprint backlog, with a clear goal of the product increment to build.
- Daily standup: where the team shares their progress or status, and tries to identify any potential impediment that would prevent them from achieving the goal they committed to.
- Retrospective: is an opportunity for the team to inspect itself and create a plan for improvements to be enacted during the next sprint. To make this meeting more efficient we use our own tool RetroAlly.
However, we try to be focused on the tasks we commit to deliver and keep the flow going for as much as possible. In that regard, we are attentive when meetings are not adding value and quickly come up with alternatives to fix that, suggesting new dynamics or even avoid having them altogether if the situation allows it.
Our dev process is geared towards delivering the best code quality and engineering possible. It is something that we also adjust according to the clients’ priorities and overall context, depending on whether there is need to move faster for a specific feature. In order to adapt to each context accordingly, we usually carry out an activity called Trade-off Sliders. By default, we deliver well tested, maintainable and easy to read production ready code. But most importantly we deliver code that does what it was intended to do in the first place; this is what stakeholders expect the product to be.
To achieve so we rely on a series of practices that have proven to work well for us. The base of it all is an instrument called Definition of Done. It is a document agreed by everyone on the team that outlines a series of checks a story has to successfully complete in order to be considered finished. It includes things like having a thorough code review by another peer, making sure it does what the user story requested and has enough automated tests to guarantee it works as expected and will continue to do so over time.
In terms of software being shipped, we feel most comfortable working on a Continuous Delivery environment where changes get deployed to production as the code gets merged, in a way that users benefit from the new features quicker. To make this happen we strongly suggest setting up a mechanism that allows having staging systems created on demand, with production-like data, containing the new feature being built in isolation with other work still in progress. We found this practice the most efficient manner to organize source code after having to face countless of configuration issues over the years of experience on different projects, while allowing at the same time stakeholders to follow project’s progress and validate it’s going in the direction they want.
In addition to the teams themselves, we have a structure in place that supports them in delivering an integral solution to our clients. It also allows us to take advantage of previous experiences with other clients and bring a solution to the table faster by tapping into that knowledge. The involvement of any of the following areas will vary depending on each project’s needs, and comes at no extra cost for our clients:
- Service Delivery Management, to make sure we deliver an exceptional level of service via our technical expertise and our teams’ ability to manage the development process
- Customer Experience, ensuring we deliver an extraordinary experience that prioritizes our client’s happiness and is consistent throughout the entire relationship.
- CTO, chiming in when complex challenges arise and providing guidance to reach the best technical solution
- People Care & Growth, going above and beyond to make sure every member of our team is happy and motivated
It is worth mentioning that there is a lot more to say, both in depth and in the number of topics to cover, as to how an engineering team achieves great results. We just hope after reading this you have a better high-level idea of how we perform the work we do. On top of that, engineering teams are a live creature so everything described here might (and should) suffer alterations over time.
By the way, we love talking about this, so if you’re curious and would like to have further conversation about this topic or how would a WyeWorks team could help you achieve your goals, please reach out to us!