3

How do the following QA, Business Analyst, Developer and lead or architect fit in a scrum.

3

People with these invaluable skills to any IT project work together in a team of equals to deliver working software every sprint. They continuously improve not only themselves but also the collective knowledge and skills of the team.

How exactly they work together is up to the team members to decide.

These are not roles but skills. So any person in the team can fulfill the role when it is needed (and he has the required skills) and every person should fulfill the skill if they are the only one available to do the work (even if they do not possess the best skills for the job.

Achieving this in your teams is usually not easy, but if a team can achieve this way or thinking and working, they will be able to deliver work with much more flexibility.

3

The Product Owner Team

Something we're starting to see in enterprise level agile transformations is the concept of the product owner team. The logic is that the product owner needs a lot of data and input into the process of creating a backlog. By forming a team around the PO (so that effectively the PO becomes the bridge between the PO Team and Delivery Team) then they have all the support they need to ensure a well crafted and ordered backlog.

Architects, Business Analysts, Customer Support, and even sales and marketing can be part of this Product Owner Team.

The BA as the PO or the TPM as the PO

The other thing I've seen is leveraging of Business Analysts to be the Product Owner. Traditional Product Management is still very geared towards outward facing and pure business drivers. Getting them to have the time to be a Product Owner can be a huge challenge. A good BA can fill the role of the Product Owner, being the bridge to the business. This also works in organizations with Product Managers and Technical Product Manager, where the TPM fills the role of the PO and the PM is able to focus out on the business.

2

QA, BA, Developer and Architect are all functions needed to create a product increment

How do the following QA, Business Analyst, Developer and lead or architect fit in a scrum.

QA, Business Analyst, Developer and Architect all fit very well! However, they should be willing and able to cross-train in other areas.

From the Scrum Guide:

  • Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
  • Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule.

Having said that, implementing this is not easy.

While hiring you want to look for people with T-shaped skills.

The vertical bar on the T represents the depth of related skills and expertise in a single field, whereas the horizontal bar is the ability to collaborate across disciplines with experts in other areas and to apply knowledge in areas of expertise other than one's own.

If you already have people with functional specialization, it can be a very slow process to train them to be cross-functional. In one of my projects, we started out with Developers, Designers and QA. Initially we got the designers to do some testing when they had some bandwidth. The developers helped out with writing automated test scripts. Then we got the QA to do simple development work, such as making config changes.

0

The jedi master who instructed me called QA, Business Analyst and Dev the Three Amigos. Apparently he's found that to be a sweet spot for scrum teams. Having worked on two all-dev teams, I'd tend to agree with him.

It's incredibly annoying to finish coding and have your work sit in "ready for testing" until the sprint review, so that's why it's great to have QA on the team. It's even worse when the story's don't even make it to work in progress, that's why it's good to have Business Analysts there, so you don't get the. Well, we didn't really need it, but we put it in the sprint anyway, but no one is going to work on it syndrome.

Beyond that Leads are just fancy Devs and Architects are either fancy analysts or, hopefully not, extra fancy Devs. So they pretty much fit in the same way, just with extra clout. They may anchor your team, so bewares.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.