As a Product Manager, I work with project managers, developers, quality analysts, experience designers, and product owners. Each colleague brings specialist skills to the mix. We tackle problems with different approaches and we work as a team to solve problems in the best way. We can adapt quickly to change and we strive to get value to our users fast and return that all-important capital on investment. This being said, there is one distinguishing feature that is invaluable to our success– being cross-functional.
Teams often include the necessary roles to deliver a solution. The product manager talks to the stakeholders, UX talks to the users, the developer writes the code, the QA checks for quality, the project manager implements the road map, the product owner represents the client. While working on the same team, each individual represents different skill sets with a common goal. Yet, this way of working does not always deliver the desired results.
Acceptance criteria is missed and the QA is forced to hand work back to the developer. Dependencies block work and costly sacrifices are made to “just get it done.” Cycle times hike, your team is no longer predictable and user stories sit as unused inventory not in the hands of your users and costing money.
Having a shared goal with different skills represented is a great place to start. But it is not the place to stop. The key is to share knowledge at the right time. Each subject matter expert advocates for their set of skills at different stages of the product lifecycle.
Are you cross-functional?
People often describe cross-functional individuals as someone who is multi-functioning and covers many skill sets. An example might be the unique core competencies some organizations look to build over time, which gives them an “ability” their competitors do not have. While this is often useful and certainly a spark for debate, successful software delivery teams strive for cross-functionality.
Become the “Amigos!”
Shift from the individual, specialist mindset and become a true team working together and leaning on one another, just as you would with a close friend. Unify yourselves as the “Amigos.” As the Amigos, you can break the silo of specialist skills and diverge from the normal routine. Each group member has the necessary skills available to help the team make the right decision at each step.
For example, a developer would advocate for technical implications or system dependencies before a feature became a user story ready for development. This allows the team to spot potential implications early and ensure that when the story is in development there are no nasty surprises, halting all work.
Design is included from the discovery, and not just when you are ready to start building UI’s. Having UX as the product manager’s pair, you are able to think broader than business needs and impact. You start to visualize the users and how the design might impact both their journey and the business. For example, a business may want to learn a lot about a user very early on (i.e.: personal information, demographics, etc.), yet the motivations of the user might be to resist giving up that information. Leave those questions unanswered and you could alienate your users at the get-go.
Adding a QA to the mix allows you to think about edge cases early. The “what if’s” that always impacts both the business and the user. And this is all before a story is ready for development.
Keeping user story details to a minimum allows for a continuing conversation. An inclusive workflow results in a shared understanding of the story and if any questions arise (because they always do) it can be resolved quickly because we all have that insight into “why.”
Keeping deliverables as small and lightweight as possible can contribute to a low cycle time, allowing for quick feedback loops from users. In return, the team is able to act quickly and iterate in a short amount of time. Iteration planning that consists of short weekly meetings to look at where the team is, what has the team learned and how we need to pivot the next week keeps the team moving fast. Being cross-functional allows for this rapid change because everyone is so involved in what is going on. Each team member understands what the group is building and the impact they hope this will have on our users and the business. So, if initial assumptions aren’t quite right, this has already been considered at analysis and everyone is ready to iterate on that idea.
A physical kanban wall observes throughput and enables the team to visualize each step in the process. Owing to lightweight stories and a shared understanding things might move quickly and it is essential for the team to see the workflow. Nothing moves unless it has had at least two of the four amigos look at it. This prevents blockers from being missed, misinterpretations of what the story is asking for, which all potentially increase the time it takes for a story to go live. Of course, there are many digital tools that allow for this kanban project flow. Physical walls just have the opportunity to be more fun and engaging if managed correctly and to their full potential.
Rituals such as daily stand-up and bi-weekly retrospectives allow a team to regularly review work and make adjustments quickly and easily.
Co-location might also be key for this way of working to be successful. You all sit together, and product owners are always available, if not already sitting with you. This allows for conversations to be heard, quick questions to be answered and an immediate and continuous back and forth communication channel with little effort. That said, remote teams are becoming more common and there is a lot of innovation taking place to enable remote teams.
The biggest asset is a commitment from the team, who are all dedicated to this way of working.
This comes with some potential risks of its own.
Firstly, it is important to appreciate that different skills require different work schedules. This should be carefully considered, for example when pulling a developer in mid-morning to discuss something that isn’t quite ready for their input, that is a costly waste of time.
Collaboration with too many voices can turn into lengthy meetings. This way of working allows for everyone’s voices to be heard and considered and sometimes, this can lead to excessive discussion.
The goal is to include the right amigo with the desired skill or insight at the right time. Every team dynamic is different and time should be taken to learn what works best for the team.
This, of course, will not ensure perfect consistency at all times. Things always change and if you aren’t spotting problems, then you won’t be responding to that change.
Some further bits of advice: Make one of your goals to break free of process and share knowledge and interactions with your team. Don’t leave your developers out of conversations at analysis. Ask your QA for input at ideation and if you haven’t been in a user testing session yet, then ask to be included. Breaking the barriers or silos down can feel uncomfortable at first, but once you do it then you not only start to realize the value of this way of working as an individual but the entire project will benefit.
About the author
Paula Moughton is a Senior Business Analyst at Cognizant Softvision’s Austin Studio. Paula has over 7 years of experience managing digital products, specializing in sectors just beginning to utilize the innovative use of technology. It is in this space that Paula applies her expertise for product discovery and lean software development practices.
Latest posts by Paula Moughton
- Are You Truly Cross-Functional? - February 27, 2020