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.


See also:
10 Key Principles of Agile Development

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

  1. IAmGM1974 says:

    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?

  2. Bruce McCarthy says:

    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?

  3. JObermark says:

    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.

  4. nagaraja ramayya says:

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

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

  6. Nattika Khiangprakhong says:

    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.

Leave a Reply

What is 7 + 8 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”