As a business analyst I work with developers, quality analysts, experience designers and product owners. Each of us bring specialist skills to the mix. We approach 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. I would like to talk about the one distinguishing feature that was invaluable to our success- we were cross functional.
Last year, I worked on a Thoughtworks TechOps delivery team, building an application for our sales team to enter sales data. Our cycle time was consistent and as low as 5 days at our most efficient. Our users were getting what they wanted, fast. We saw a variance of 30%-60% increase in the amount of data entered month on month, and this allowed our stakeholders to make more informed decisions and essentially reduce the amount of wasted time and money.
Teams often include the necessary roles to deliver a solution. The BA talks to the stakeholders, the XD talks to the users, the developer writes the code, and finally the QA checks for quality before it goes live. All working in the same team, representing different skill sets with a common goal. Yet, this way of working does not always deliver desired results.
Acceptance criteria is missed and the QA is forced to hand it 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.
Am I cross-functional?
Having a shared goal with different skills represented is a great place to start. But it is not the place to stop.
Having discussed this topic at various socials and meetups, I often meet people who discuss cross-functional as a multi-functioning person that covers many skill sets. An example might be the unique core competencies some organisations look to build over time, that give them an ‘ability’ their competitors do not have. While this is often useful and certainly a spark for debate, it is not the point I want to make here. The experience I had with the TechOps delivery team was a group effort where we strived for cross-functionality.
The goals?
The key was to share knowledge at the right time. Each of us would advocate for our set of skills at different stages of the product lifecycle.
Meet, the ‘amigos’ !
As the amigo’s, we broke the silo of specialist skills and diverged from our normal routine. We had the necessary skills available to help us make the right decision at each step.
For example, a developer would advocate for the technical implications or system dependencies before a feature became a user story ready for development. This would allow us to spot potential implications early and ensure that when the story was in development there would be no nasty surprises, halting all work.
Design was also included from inception. Having the XD as my pair, we were able to think broader than business needs and impact. We would start to visualise the users and how the design would impact on their journey, and the business. For example, every piece of data the business was asking for- we would look at how it could impact the user journey and what the motivations of the user would be to oblige and give up that data. Leave those questions unanswered and you could alienate your users at the get go.
If you add a QA to the mix, you then start to think about edge cases early. The ‘what if’s’ that always impact both the business and the user. And this is all before a story is ready for development.
We kept the story details to a minimum, need to know basis. This allowed for a continuing conversation. From having an inclusive work flow, there was a shared understanding already of the story and if any questions arose (because they always do) it could be resolved quickly because we all had that insight into ‘why’.
Furthermore, we were following lean principles and keeping deliverables as small and lightweight as possible. This contributed to our low cycle time, allowing for a quick feedback loop from our users. In return, we could act quickly and iterate within a week. Our iteration planning consisted of short weekly meetings to look at where we were, what we had learned and how we needed to pivot the next week. Being cross-functional allowed for this rapid change, because we were all so involved in what was going on… we all understood what we were building and the impact we hoped this would have on our users, and the business. So, if the time came that our initial assumptions weren’t quite right- we had already considered this at analysis and were ready to iterate on that idea.
Tools
We had a physical kanban wall to observe throughput and enable us to visualise each step in the process. Owing to the lightweight stories and the shared understanding things moved quickly and it was essential for us to see the workflow. The wall was separated into sections and we could pull actual pictures of team members over to a story that was ready to move. Nothing moved unless it had at least 2 of the 4 amigos look at it. This prevented blockers from being missed, misinterpretations of what the story was asking for and multiple stories being worked on at any one time, which all potentially increase the time it takes for a story to go live.
Rituals such as daily stand-up and bi-weekly retrospectives allowed us to regularly review our work and make adjustments quickly and easily.
Colocation was also key for allowing this way of working to be successful. We all sat together, our product owner was always available if not sat with us. This allowed for conversations to be heard, quick questions to be answered and an immediate and continuous back and forth communication channel with little effort.
There was a commitment from the team, who were all dedicated to this way of working.
Warning
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 (agile manifesto point 4!). To take further advice from the manifesto- 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 an ideation session yet- then ask to be included. Breaking the barriers or silo’s down can feel uncomfortable at first but once you do it, then you not only start to realise the value of this way of working as an individual but the entire project will benefit.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.