Most developers are used to working in a team environment, where a business analyst writes requirements, a developer writes the code, and a tester tests the code. This is a widely accepted practice, yet something about it is inherently inefficient.
Don’t get me wrong, I’m not saying that doing things this way is bad. Yet anytime you add someone else to a process, it becomes inherently less efficient because those people have to communicate and get on the same page. Generally the inefficiencies are outweighed by the benefits of having people using their strengths to help move the process along… but not always. Let me explain.
On Agile projects, requirements are not the deliverable, requirements are just a means to an end. Requirements often serve other purposes, for example, communication with business partners about what is going to be built in order to make sure you’re building the right thing. But if you think about it, requirements are in a way inherently inefficient.
Software development is a series of translations. Our goal is to take business ideas and translate them into working software. This is obviously easier said than done. On a typical project, there are many levels of translations: business person expresses ideas to a business analyst, who turns those into requirements with acceptance criteria, which developers turn into code and automated tests, and QA people turn into test plans, which leads to some UAT process with users, which eventually gets deployed to production. This process has been proven over the years to work well, but there are many translations that have to happen during this process in order to software to get created.
My argument is that there are some cases where this process is more than we need. What if for certain projects or functionality, a person or small group of people could just go solve a problem? Forget about writing requirements using the typical methods and just streamline the process and get something delivered quickly. Think about the average ticket that a BA has to write. It takes a long time to type that up, and when they do, there still isn’t any code written.
Doing this takes a lot of skill. If you developer doing this, you need to be able to communicate with the business, understand what they really want, be able to speak to them in their terms, develop a working solution, sufficiently test your code, and work with business people to make sure everything was built correctly. But if you can do this and write just enough requirements and develop and execute a comprehensive test plan, you potentially could deliver working software much faster.
I would argue that this should be the next step in the career path for senior developers. Are you able to deliver working software without the assistance of business analysts and the validation of QA testers? If you’re able to do this, you’re able to keep progress moving while freeing up business analysts and QA testers to have time to focus on areas where they’re needed.
One of the projects I’ve done that I’m most proud of was a 6 month BI ETL project where I was the only one on the team. I had to gather and write up all the requirements (I didn’t skip this part because people needed to know how it worked), write the code, test it, and make sure it continued to work in production. This code is starting its 5th year in production now, and it’s allowed people on several systems to develop against a data model that is going to be around for a lot longer than my code.
How long would that 6 month project take if we had a business analyst and a tester on it? Would it have taken much less time? Probably, but certainly not a third of the time, because so much communication would have to take place in order for everyone to get on the same page.
Now that I’m leading a team, I’m always looking for developers who can take ownership of a technical problem and deliver a solution for it. Are you able to do that? If not, what skills do you need to acquire to be able to? (It might not be coding skills.)
This is not an attempt of a team leader with a development background not appreciating business analysts or trying to cut them out of the process. I’m saying that as developers, sometimes we use business analysts and QA testers as a crutch. If you’re able to deliver technical solutions without this support, you can take your team and career to the next level.