Every time we start working on a project there are a couple of things we do to get the project going:
This is a high level list but it’s what most managers do when there is a new project to kickoff and it’s supposed to happen in one meeting. Also, a common mistake is to think that with this one meeting we’ve magically solved the problem of explaining to the team what they ought to do, what’s the client’s goal and the objectives that the project is trying to achieve (raising funds, earning money, putting a car in the orbit and so on).
The truth is that in most meetings this doesn’t happen at all . The best outcome is getting a crowd together and creating a Slack account and a Jira board, then luckily some team members will be responsible for creating tasks and others will be working on them. But are we all working towards the same goal? Does the team goal match the client’s goal? Has the client explained his vision of the project clearly?
The importance of defining a goal lays on having a team and stakeholders working on the same path to get similar results as the ones they were actually expecting. Is the client always right? Well no… But they always have a hypothesis they need to test. That hypothesis can be related to a business goal or to a product goal, it’s up to the stakeholders to define which goal they are aiming at so that the whole team, Developers, Managers and Product Owners, are in the same page. I believe that a Developer is anyone on a team that generates value for a product. That includes Designers too.
There are many goals that a project may have to take into account and this is because there are multiple participants. The CEO has probably a goal of his own, the VP of engineering another one, the team can define their own goals too and so on. The key is to find an overarching goal that can align most of the expected results into one product.
For that reason, we should have a clear vision of which is the goal the product is trying to achieve. This is what we should be building once we have worked in every feature that seemed to have an important value to be part of what we’re building. In order to do that, we need shorter goals that the team must understand easily. These can be our Sprint Goals which the team must know once any sprint starts.
The theory says: We have sprints so that we can have added value on an incremental basis to our product every certain amount of weeks. The Product Owner is responsible for reaching the ultimate goal regarding the whole project’s vision and that’s why we need Sprint Goals to be defined by POs.
I do agree, is it enough? No. It’s not enough because I haven’t mentioned team needs. The team may realize that the code needs to be refactored, that there are changes to be made in order to include a new library or that they need to add more tests because in the previous sprints they haven’t added any coverage in order to fulfill another goal. The team may have their own goals and Product Owners should be proud if that happens. Managers must encourage the participation of the team when goals are being defined. Great communication and a positive environment are important to generate team proactivity which will help us accomplish the sprint and the project goal.
The purpose of a goal is to have everyone working towards the same objectives, with a clear context and on the same page. Being aware of goals often leads to being flexible about certain constraints like time, quality and features. A Manager must work closely with the entire team to generate the necessary communication flow so that expectations are equally set for everyone who is interested on the product.
We don’t want a frustrated team, an angry customer or someone saying “I told you so” if a project fails after N iterations. That failure is everyone’s responsibility.
At Lateral View, we try to help teams define their goals for every sprint and every product by empowering all the team members to participate on the discussion. The final outcome of a product is up to every team member and not just a single person.
We talk to the stakeholders and we help them establish a clear goal, one that everyone understands. And this last part is important because everyone on the team must know what to do if a task takes longer or how to prioritize their work: the goal is self explanatory.
For example, if the goal is making a wristband connect to our phone over Bluetooth, it makes no sense at all to work on polishing the UI. That is well defined in the goal, which is the most important thing we must accomplish in a sprint.
We must also align the team’s goal with the owner’s goal, so we encourage people to discuss things that may seem critical like technical debt, increasing test coverage or working on UX improvements. It’s up to the team to present solutions and communicate any issues. Obviously, there is one person that will have the last word on what the team will be working on, but it’s the Product Owner’s responsibility to communicate ways in which they can improve the process and why something is important regarding the ultimate goal.
We care about every team member and believe they should feel protected and not left aside. We need them to feel that what they do is much more than just coding or designing.Goals are necessary for every team because they add context and make projects have sense.
Speak up, it’s up to you to turn average into extraordinary!