Which groups should participate in Agile? [closed]_问答_开发者

Closed. This question is opinion-based. It is not currently accepting answers.

开发者_JAVA百科

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this question

In my company we have the programmers, front end developers, designers, and UX team all participate in Agile groups. I am no Agile master but I understood that all members of a team should be able to be able to do any of the work. Having designers, the UX team, frond end developers, and sys admins join in on a vote to estimate how long a backend task will take seems crazy to me. I barely know! So my question is am I being too harsh? Can this work in an Agile environment?

You have got the base concept wrong...all members should be able to work across stories. Not total cross-functionality...a developer cannot suddenly emerge to be a UI designer.

And no. of members per team is restricted to 7 -10. So that group should be segmented accordingly.

In my company we have the programmers, front end developers, designers, and UX team all participate in Agile groups. I am no Agile master but I understood that all members of a team should be able to be able to do any of the work.

IMO, this is a misunderstanding. Being a cross-functional team doesn't mean that every person on the team should able to do every job. It means the team should be a right mix of people with the right skills (as a whole) working toward a common goal. In other words, Agile isn't looking for one person with all the skills, Agile is not against specialization. Everyone can't and won't be equally good at everything.

Having designers, the UX team, frond end developers, and sys admins join in on a vote to estimate how long a backend task will take seems crazy to me. I barely know! So my question is am I being too harsh? Can this work in an Agile environment?

First, when using planning poker, nothing says that you need to have convergence at the first round. Actually, I think that having divergences is good, just let people explain why they voted this way, with their certainties and their doubts, and go for next round. Regardless of people expertise area, I bet it won't take more than 3 rounds to find a consensus. Second, after a few iterations, you'll have enough historical data to compare against ("this story is like this one") and this will help a lot, independently of the specialization of team members. Third, as reminded by JeremyMcGee in a comment, team members will get a better understanding of what is going on and of the roles of each other which is another great effect. So, to me, yes, this can work and having different set of skills is a strength, not really a weakness.

The short answer is yes.

Even teams of pure developers will tend to self organize into specialties or owners of specific subsystems (unless you tend to force them to rotate work, but that is a topic for a different issue). Therefore, you will be estimating stories with a significant number of members in the room that have little knowledge of the subsystem work associated with the story.

Story estimation is supposed to be more about comparing scales of complexity/work. It this two times, four times, eight times (or similar scales) more work than defined base point. Or, is it similar to this other item we rated at eight. At least that's the goal. At the sprint level (versus overall backlog), I find teams prefer to estimate with more concrete scales (ie hours).

For people in specific disciplines, you may or may not want them to be included in the estimation process. If those individuals have a reasonable understanding of the complexity of the task, there estimates may be just as good as another member. If not, then they shouldn't provide an estimate.

One benefit of including their estimates as it often creates more outlying estimates (overly high or low). When we have an item with estimates outside of a reasonable envelop, it is a trigger to have a short, but deeper discussion of the work. Often, that discussion forces a group discovery of work/complexity that wasn't obvious from the story description and acceptance criteria.

Agile teams are supposed to be "cross-functional" - i.e. have lots of specialists working together with some overlap.

For web development, and even for IT infrastructure, it can make sense to have a DBA, designers, business analyst, programmers (whatever different skillsets you need) and IT infrastructure people on the same team.

Not all members of the team have to be working on it full time - but any department or specialism that could delay the project or cause misunderstanding by not being involved has to be represented by somebody with enough power or skill to do those actions.

Don't forget to involve people:

who need to sign things off,
people who administer common facilities like DNS, LDAP
network admin
people who buy and maintain hardware,
security people...

I have been involved in projects where the software was ready on time but the DNS or the hardware wasn't - which is a #fail as far as the customer is concerned. What things outside your control are you going to need help with? Team leads, coaches and scrum masters should be looking an iteration or two ahead to get the right people involved.

Getting all the right people involved in estimates and kickoff meetings - including technical sales and the business is critical. Tech sales may think they can't help but often they can answer questions about what the customer wants that can help create a consensus in estimates.

Agile is about cooperation and common sense. That said, I think it will basically boil down to the actual team. Can they cooperate efficiently? If not, you might need to fix it. What does your retrospects tell you? Agile is a path, not the destination

Today with all the mixed technologies that has to work together in a product all developers have to take a wider view how their part interacts with the rest of a product. So getting a team mixed is good I think, but getting the team to talk openly and work together is not always easy. People can be difficult.