agile circle chartAgile is a mindset and a practice of project management.

Based on the Agile Manifesto, the principles of Agile at Berkeley are:

  • Prioritize individuals and interactions over processes and tools.
  • Focus on working solutions over comprehensive documentation.
  • Achieve specified and measurable benefits.
  • Collaborate with mutual accountability and respect.
  • Understand the business, technical, and cultural context in which campus systems and services operate.
  • Adapt quickly to changing campus needs.

Agile management isn't just for software management. In a period of rapid economic and technological change, the use of Agile principles and practices can empower campus project teams to respond to challenges rapidly while remaining flexible. By employing Agile practices, university staff can more efficiently design, develop, and deliver excellent services to the members of our campus community and help UC Berkeley thrive as a world leader in higher education.

What is Agile at UC Berkeley?

"Agile Management is not a method, but a mindset; reinforced by values and principles that guide our behavior and enable us to succeed in an environment of rapid change and uncertainty."   — Reed & Neis 2013

The goal of the Agile mindset is to "LEARN" from our failures, and our successes. An Agile mindset is an attitude that equates failure and problems with opportunities for learning, a belief that we can all improve over time, that our abilities are not fixed but grow with effort.

So what does this really mean?

Room to experiment and fail as long as you learn from it and incorporate the learning the next time around. It means not having all the answers at the beginning, but moving forward anyway, and collaboratively discovering the answers through work. Letting others do what they do best by identifying what needs to be done and then getting out of the way and giving them space to work.

  • Prioritize individuals and interactions over processes and tools.

  • Focus on working solutions over comprehensive documentation.

  • Achieve specified and measurable benefits.

  • Collaborate with mutual accountability and respect.

  • Understand the business, technical, and cultural context in which campus systems and services operate.

  • Adapt quickly to changing campus needs.

So how do you do this?

Get to know and understand the Agile Manifesto.

Work really closely with your customers to build a mutual understanding of their needs and priorities, and what you need to build to achieve them. Start building and, before what you build is perfect, share it with your customer and get feedback, then change it depending on what the customer says. Take some time to understand what you want to keep and why, and what you need to evolve and why - that could be what you built or how you built it.

Repeat - Oh, by the way, this is an iteration.

Making It Real

Okay so that sounds great. How do you really do it?

There are many "flavors" of Agile none of which is the right one. Your situation determines which is the right one for you. In the Learn section, you can find deeper information about these options; here is a high level view of how to approach Agile implementation no matter what flavor you use.

The Team

  1. The team must have someone on it to represent the business needs, values and priorities, someone who will:

    1. Describe these clearly so the development team (software or otherwise - the people making the deliverable) understands what's on their plate

    2. Facilitate decisions between stakeholders and development team regarding

      1. when a deliverable is complete/correct;

      2. when a deliverable's priority should change;

      3. when the schedule needs to adjust.

  2. The team must have someone who manages the everyday work. This person often acts as an intermediary between the person who represents the business needs (above) and the team doing the everyday work (the development team). This is not to say that the development team doesn't have direct contact with the business owner when relevant, just that there will be many communications that can be handled without direct representation by the development team - leaving that team to dive into the work.

  3. The team must have people to build the deliverables.

  4. Other than those roles, the makeup of the team will be determined by the specifics of the project and the "flavor" of Agile you have chosen to use.

What You Do

In some ways, what you do is the same as with any other well run project: plan and implement. But the crucial difference is that in Agile the scale of the plans and the implementation activities are small and manageable, allowing for adjustments along the way to take reality into account. So for example, let's say you are going to build a new software application. Traditionally, you would spend a great deal of time gathering all the requirements and documenting them to the most specific detail, then a schedule would be created and then the application would be built. Once built, it would be presented as complete, finished and ready. However, more likely than not, the world will have changed in the interim so the requirements are not longer completely relevant. Additionally, more likely than not, something would have been lost in translation or not anticipated between those detailed requirements and the final deliverable.

With Agile you do the planning and building in a more incremental, fluid manner that allows for learning, growth and change - you are agile. Specifically, you define the goals, context and success criteria at a strategic level and then define requirements in small increments that are prioritized and built sequentially. The increments are determined by identifying the smallest unit that can be built to deliver real value to the customer as quickly as possible. Each built increment is delivered, reviewed and potentially adjusted based on the review feedback. Then the requirements list (often called a backlog) is reviewed to determine whether the priorities need to be changed. Adjustments are made if appropriate. Then these steps are repeated until the project is complete. Each round of build, review, adjust is often called an "iteration."

The specifics about this agile way of working come out in the various flavors, each of which has its own tools and methods. Again, there is no right flavor, only the flavor right for your situation.  

Quick Start

The purpose of this Quick Start section is to provide some simple principles to build your knowledge and practice from. It's definitely worth beginning with the Agile Mindset section as a frame for all the other information. The other sections delve more deeply into the ideas introduced in the Agile Mindset.

iteration graphicIteration

Small steps allow immediate benefit and immediate course correction based on learning from building the thing and getting feedback. Repeating the steps moves the project forward.  

Iteration encompases the core Agile concepts:

  • build value quickly

  • learn from the process and results - no fear of failure

  • apply learning to adjust process and results

  • repeat

Agile Tools


UC Learn

UC Berkeley offers a variety of resources for members of the campus community to learn about Agile project management. Linked from the menu are some of the most useful resources. In addition, this section includes links to interesting resources outside of the campus.  Some of the references are specific and it is useful to check out Glossary, Agile Terms or The Agile Dictionary.

Campus Resources

UC Berkeley Extension offers courses and professional certificates in Agile project management. To learn more, please visit their website, UC Berkeley Professional Sequence in Agile Project Management