The Truth About Roles in the Scrum Team
First things first, there is no title other than development team member in the scrum. These are people who have cross-functional skills, and organize themselves to deliver value. What happens to job titles?
Can you replace a software architect, a quality analyst with a dev team? Or can you replace a business analyst, UI/UX designer, project manager with a product owner/manager?
First of all, scrum teams have the product of all costs which makes roles unnecessary. Properly trained software developers, even the junior ones can make the right decisions. But how? What do I mean by properly trained software developers?
Let’s talk about how to make decisions.
You all noticed that sometimes people tend to make decisions according to gut feelings. And we all know that engineers like playing with numbers and researching new things. When we begin a project and don’t know what to use, how to do it, we research best practices first, then brainstorm with the dev team. After that make a scorecard and a pair of developers sometimes do POC before starting to apply the solution everywhere. Freedom to choose what to use, how to use technology makes the dev team empowered and increases engagement of the product. Encouraging dev teams to do tech meet-ups results in spreading knowledge within the team.
Do we need a quality analyst role?
Can we spread this role’s area of responsibilities among software developers? I believe that we can. But how?
What are the responsibilities of a quality analyst? QA ensures the quality of the released software. QA prevents errors before actual users find them. The scrum team as a whole is responsible for the quality of the released software. That’s why we write unit and integration tests. But these tests can not cover everything. We pursue our goal of test-driven development. And we continue to apply automation UI tests and contract tests on isolated test environments. The crucial thing is adding these to DoD and making code reviews effectively.
Developers don’t like reading documentation.
The Product Owner role is very different among companies. Furthermore, responsibilities are changing if the product owner has more than one scrum team/product. That’s because the customers that we are serving are changing. But one thing is stable. That thing is, developers, don’t like reading documentation. It could be concluded that developers don’t need ordinary business requirements.
They need someone who;
- supports them when something fails
- answers their questions in Technical Analysis or while developing software
- knows the business and how to explain it
- not just find solutions but make them be part of it
Developers’ needs chances according to features. Sometimes a mock-up serves enough. Sometimes you should draw an altered customer journey with API endpoints, contacts of the events, mock-ups, status, touchpoints, etc. Sometimes a unit test Excel says a lot more than anything else.
If I had to make a decision, I prefer working with a dev team without BA. And that’s why…
I have worked with dev teams with BA and without BA. If I had to make a decision, I prefer working with a dev team without BA. Software developers who work without BA have extensive knowledge of business eventually. I think that is one of the most important things in software development. The product serves the company and people. That’s why we are developing it.
Furthermore, working with a BA is like playing Chinese whispers. As a product, you have to be sure about understanding market needs/customer needs while you shouldn’t have doubts about if BA fully understands it to deliver to software development.
Some people think that a BA in a dev team will help them on the technical side.
That is not the case. Because, if you have a BA, you should properly explain all the business details. And It consumes a lot of time. Also, there is a high-level chance of misunderstanding and you should go through it before development.
If you don’t understand business/system requirements, you can not effectively do this job.
Let’s do backlog refinement sessions, business meet-ups with software developers, being with them in technical analysis sessions. Ask for help to understand them. It sounds like an alien language in the beginning. But in time, you will understand. It is not rocket science. You will almost always guess the size of the project or feature just by listening to it from customers. That’s because you know how the system works, how many projects the dev team should change or add etc. Maybe in the future, you will solve some design problems.
In a nutshell, what happens to roles?
It is vanishing. Responsibilities are melting into each other. And It should be. If you want to increase effectiveness and efficiency, everyone in the dev team should be able to play the role of a software engineer, and QA, a system architect, sometimes think like a BA.
