Agile Principle 2: Agile Development Teams Must Be Empowered

An agile development team must include all the necessary team members to make decisions, and make them on a timely basis.

Active user involvement is one of the key principles to enable this, so the user or user representative from the business must be closely involved on a daily basis.

The project team must be empowered to make decisions in order to ensure that it is their responsibility to deliver the product and that they have complete ownership. Any interference with the project team is disruptive and reduces their motivation to deliver.

The team must establish and clarify the requirements together, prioritise them together, agree to the tasks required to deliver them together, and estimate the effort involved together.

It may seem expedient to skip this level of team involvement at the beginning. It’s tempting to get a subset of the team to do this (maybe just the product owner and analyst), because it’s much more efficient. Somehow we’ve all been trained over the years that we must be 100% efficient (or more!) and having the whole team involved in these kick-off steps seems a very expensive way to do things.

However this is a key principle for me. It ensures the buy-in and commitment from the entire project team from the outset; something that later pays dividends. When challenges arise throughout the project, the team feels a real sense of ownership. And then it’s doesn’t seem so expensive.

6 Responses to “Agile Principle 2: Agile Development Teams Must Be Empowered”

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?

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?

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.

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'.

[…] 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 […]

Good article!! I agree with you that empower is a big important word for doing a project. As Waters mentioned in the article, active user involvement is a key of the agile development team. For agile management, team members’ opinions are very important. Team members participate and share their knowledge at beginning of the project. Project vision, product mission and mission test or we call these “charting purpose” are created by all of team members. Also user story and story point do not build by product owners alone but they are prioritized through discussion between team members. All of these artifacts are created by empowered team members. Therefore, they clearly understand what they have to do and how they have to do. The project will be successful. Moreover, the buy-in and commitment will be built from the whole team. Everyone is happy to do their works.

However, everyone might have different opinions but discussion is good for the project. In my opinion, we can use working agreement to solve this problem. All team members should create its own working agreement before starting the project. This document must be built from the agreement of the entire project team. Therefore, when there are some different opinions or debate and it needs to have decision, team members can use the working agreement to help them to make a decision.