Have I become obsolete as an analyst?

My slight existential crisis started before I even knew it existed. While studying computer science, I had no notion of the existence of functional analysis, or the role of a functional analyst. At university projects, my teammates and I were responsible for everything in the delivery process: from conceptualizing ideas, refining them to putting them into ‘production’. Everything was part of the scope of the ‘software engineer’. It was only when I started working at AE that I noticed that there was more to it than that: I noticed that the activities I loved most (which I had to admit wasn’t necessarily the coding itself), were often labelled as the job of the “functional analyst”.

As a young graduate at AE, I had the opportunity to learn the job of functional analyst from experienced colleagues. Over the years, my skills grew and I really like that job. But somewhere along the way, doubts started to creep in about my acquired worldview where a functional analyst was always part of software engineering teams.

Let’s analyze my job

First, let’s take a step back and clarify what it is that I do as an analyst. My colleague Daan Haelvoet recently wrote his own blog post about the skills of an analyst. For me, this translates into a passion for breaking complex problems down into smaller, less complex problems and coming up with multiple ways to solve them. Doing this in a structured way, using techniques like process models (to visualize how use cases of the application fit into the overall process of an end-user), information models (to make sure all details and nuances the application needs are provided) and component diagrams to fit all the pieces of applicative puzzles together, is how I spend most of my time. That is if I’m not in workshops refining all the problems and solutions that feed those models!

But that is not everything that I do... My computer science background keeps pulling me towards application architecture and more technical design discussions, love them! But I want my applications to be more than just functional. They should be lovable as well, which made me grow an interest in UX techniques I can apply in my analysis. Since the quality of our product begins at the very start with requirements, I am also highly invested in good requirements engineering and assisting in backlog refinements. By growing other skills and trying to apply them in practice, I would say I grew a T-shaped profile.

When the doubts started...

So, as you can read I am very passionate about my job and happy to be able to do it so when did I start to become concerned? My passion for application architecture combined with a strong people focus made me very interested in Conway's law and how to organize teams to support the architecture we are aiming at. This brought me to read up on many agile and other frameworks or organization forms within software development organizations. I started noticing that (functional) analysts were mainly mentioned in what are perceived to be old-fashioned models. Waterfall way of working with a thorough analysis phase before throwing a specification over the wall, often with teams responsible for different steps in the SDLC (so-called functional or uni-disciplinary teams). Nowadays, the mainstream is to work agile in cross-functional (multi-disciplinary teams) teams that take responsibility for the entire SDLC. Round of applause, because that is great! But none of the frameworks every company is dwelling with has roles defined other than Product Owner and Scrum Master. Some may have the occasional Architect or UX designer mentioned, but I started doubting... Where does it leave me?!

Take for example one of the teams I was a part of at a client (let’s call them client A), that had many great T-shaped profiles. A Product Owner with past experience as an analyst. A UX designer that did not just look at the customer of the product and their experience but also at the internal business processes to make sure the journeys of all stakeholders were aligned. A more than capable technical team who thought along during refinements to cover potential holes in the functionality and looked beyond the technical challenge to make sure we were going to build great features. With all those great people on my team, I had the feeling that indeed, with a Product Owner, a great UX’er, a great functional tester covering quality from requirement to production, and broad-thinking developers there was no need for me, the functional analyst.

Note: Covid didn’t help me sitting alone, in my home office, fretting about how to work together with my team when everything I could do, they could as well. Cue the start of some serious self-doubt!

I also worked for a another client (let’s call them client B) where it was generally assumed that analysis is done within the software engineering teams. There was no explicit analyst role defined, leaving me to doubt its existence even more. If they have been developing a market-leading software solution for many years without analysts, my kind (the functional analysts I identify with) must have become obsolete?!

The clouds started to lift

I started to draw what I had experienced within that overly capable team at client A. The scope of the product or project as a set of capabilities needed to make sure all activities from the SDLC were qualitatively covered and matched with the T-shaped profiles that were in the team. Notice the overlap?

Apologies for putting analysis in the middle - typically human to put yourself in the middle of your own universe, no?!

At client A, they had defined a role (even a profession/function) for each discipline within the SDLC. They staffed project and product teams with a single person for every role. In my team, this resulted in the before mentioned overlap of skills and competences. In other teams however it resulted in another scenario. I-shaped profiles filling in the role of their specialty discipline worked alongside each other. The multi-discipline was fragile: with one team member out sick, a whole capability was lost within the team.

It made me aware of the pitfalls of working with roles in comparison to talking about practices/disciplines/capabilities in teams: the leap from a set of skills to a specific person required to fill those skills in is quickly made.

At client B, they did not really make a lot of difference between roles and assumed the entire team to be multi-disciplinary and cover the entire SDLC. However, looking at the activities happening it became evident that in many teams, the analysis activities were skipped. Investigating a bit further made me realize that, while the expectations were to have multi-disciplinary teams, they had been staffing the teams with very similar profiles of technical software engineering (Java development, Angular development, DBA, cloud engineering). A lack of analysis (or architecture or quality assurance) discipline on the multi-disciplinary team became evident.

It made me aware of another pitfall I fell into: misinterpreting that all people in typical agile software engineering teams should be software engineers that can code. Having a multi-disciplinary or cross-functional team means having all the skills in the team, to cover the entire SDLC (or the parts you deem within scope of the responsibility of the team). That also means to look for different profiles when forming teams, and very often having specialists for certain disciplines.

Should roles be introduced then, to make sure there are specialists?
With roles come responsibilities... The analyst is responsible for the analysis. Next to the pitfall I marked above, it also has the downside of confining people to boxes.

We need to be alert for the white space between roles, gaps that nobody feels responsible for.

Don Reinertsen - The Principles of Product Development Flow, 254

If someone else has the role ‘tester’, then I should not be responsible for ‘quality assurance’, right? It helps in making sure that at least there is someone responsible to get the job done, but it does not help in making sure your multi-disciplinary team works together. Another approach could be to have the team decide each sprint how to best allocate their set of skills for the stories at hand, and divide the responsibilities assigned to their team as they see fit. There is however a manager responsible for making sure the team has all the skills needed, through people growth or hiring and that the team takes up its responsibilities on all aspects of software delivery.

The sun came shining through

Having “an analyst” might not be what it is all about. The most important step is to grow an analysis community of practice to unite those who feel they want to either specialize in analysis or take up more analysis activities within their team to move forward. To share knowledge, start-up coaching, and give training on how to tackle complex problems and refine solutions. And figure out whether they need the concept of a role to make that work in their company!

And my existential crisis was averted... I am not obsolete as a functional analyst at all. There will always be a team that requires my specialty because other team members have other specialties and just don’t love questions, UML, or details that much or love the technical side more. But there will also always be teams that do not need me because they already have other profiles, that might call themselves something like Product Owner, UX designer, Test Engineer, or Software Engineer that love to do what I do as well!