Agile Principle #2: Agile Development Teams Must Be Empowered
An Agile Development project 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.
See also:
10 Key Principles of Agile Development
17 January 2008 00:00
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?
8 February 2008 00:48
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?
22 March 2009 17:06
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.