Comments on: Agile Principle 2: Agile Development Teams Must Be Empowered

By: Drill Sargeant! | Release Insights

Drill Sargeant! | Release Insights — Fri, 18 Feb 2011 22:07:49 +0000

[...] core tenets of agile development is that the teams are intensely collaborative, self-managing, and empowered to achieve sprint goals. Management provides the strategic goals, infrastructure, and a [...]

By: nagaraja ramayya

nagaraja ramayya — Tue, 16 Nov 2010 11:29:03 +0000

Hi, This is in response to the comments by Bruce:
The agile teams are(should be) made up of cross functional experts, people with multiple expertise, experienced and mature.Thus there is no single owner, the whole team owns every aspect.The whole team collaborates to deliver.team members should plan and develop their skill sets so that, everyone can own anything.That is when team is completely agile, else team is restricted by the skills of individuals and if an individual fall sick for a month, that sprint fails as apart from owner no one can complete his work.
The other fall out is that each member is working on his own individual strand of work and is not really bothered about team's commitment as a whole , as he worries only about his deliveries.....thus team becomes a group of individuals and can not be called a 'team'.

By: JObermark

JObermark — Sun, 22 Mar 2009 17:06:00 +0000

Perhaps in these cases where consensus is hard, it is most important to determine what decisions need to be made, and which do not.

If there is no consensus, there is no decision, but maybe that means you wanted too firm a controlling hand on the group's activity, and the group is rebelling.

Is there a smaller decision that will give enough direction without entailing the details that folks are filibustering or contending over?

In other consensus-driven contexts I also like Starhawk's notion that some decisions cannot be made by deliberation because they are not concrete enough, and they should be made 'by oracle'.

Agile promotes refactoring, so agree when you think you need the decision. If you cannot decide by then, make the decision arbitrarily. Then see if that nets you the data you needed to make the decision well to begin with.

If so, refactor out the old decision and implement the new one. If not, the decision did not matter, your arbitrary choice was as good as any other.

By: Bruce McCarthy

Bruce McCarthy — Fri, 08 Feb 2008 00:48:00 +0000

I have essentially the same issue. Buy-in is good but there are some people who tend to drag the discussion off on tangents and make group decision-making very difficult.

Also, there are some decisions which should be owned by particular roles. I don't want to spend time discussing the doc writer's opinion on the visual design or the visual designer's opinion on the relative priority of features. The designer should own the visual design and the product owner should own the feature prioritization, no?

By: IAmGM1974

IAmGM1974 — Thu, 17 Jan 2008 00:00:00 +0000

I understand that there has to be a buy-in from all the team, but at times I have observed that if everyone is involved into a discussion, sometimes people start pulling the discussion in different directions and it becomes difficult to reach a conclusion. My question is, and I may be very wrong, but:

Could it make sense, at least in very initial stages to have a sort of 'pre-meeting' where, say the product owner, users or their representatives and analyst sit together and identify the features or something similar and set a tone for, or drive, the actual meeting, rather than everyone coming in directly and probably having a difficult discussion?