Many people are confused and believe that agile is a software development process that will solve their productivity and quality problems. Agile is not a process, a tool, a structure or a culture.

Agile is a state of being.

This is a very fundamental thing we need to get in order to be agile. We are either responsive to unexpected changes in our environment or we are not. Have you ever tried to make a plan that involves multiple individuals and dependancies? If you have, then most likely you have realized that most of the time things don’t go according to plan. When this happens, you start to add in all sorts of buffers in the plan and future plans in case things don’t go according to plan. Let’s 2x the developers estimate in case she is wrong. Let’s expedite shipping on that thing in case it doesn’t arrive before the event. Let’s try to add 3 more people to that late project to speed it up to get it -> back on plan. But even when we make every effort to right the supposed wrong, it fails.

There is a paradox that occurs with all states of being. There is no path and no journey to take to “be” but yet there are causes and conditions that support a state of being. If we wanted to be in the state of happiness but then lost our home and had nothing to eat it would be more challenging to be in the state of happiness. We can’t force a flower to blossom but if we do not water the plant or give it light, it most likely will never bloom. Being agile is like this.

What if you could adapt?
What if we could look at, understand and learn from what didn’t go according to plan? What if we could actually adapt and be agile?

Like any way of being there are things that will facilitate being in that state and there are counter forces that will do their best to pull you out of it. Even though being in a state of happiness and peace is a mindset, if you have nothing to eat, nowhere to sleep and your personal space is infringed on it is hard to be in a state of peace. It is also easy to recognize even in the most decadent environments, we may be more likely to be in a state of happiness but still have our moments of discomfort or ennui. Like this being agile becomes increasingly possible in environments that are supportive of change. If you work in an environment that supports you in every way you need to be agile, then you will adapt.

How do we become agile?
We become agile when we accept that no matter how much data we have to predict results, things don’t always go according to plan so we adapt. To do this we need a framework that supports adaption – learning. This framework has several key components.


We accept that change is inevitable and a part of life. What we learned and adapted to yesterday are no longer the conditions that we learn and adapt to today. We need to be open to learn and understand change will happen. Change creates an opportunity to learn from the conditions that caused the results.


Based on this understanding that although we may have a grand vision and direction we will be heading in, we recognize we don’t know what struggles we will encounter. We create an experimental culture that learns from every move it makes. We no longer define failure in terms of not getting the exact results we were seeking. We define failure as failing to learn. In doing so we are open to new ideas. We are collaborative and cross-functional.


We create and implement processes that allows us to move quickly and learn from each other. We do daily stand-ups to decouple dependancies. What does that mean? You want to get a web page up but are waiting for content from a copy editor = dependancy. How can we move this to a faster result. This is what we look at. How do we do this in scrum agile? The product team develops clear stories. The development and design team divides up the tasks and asks the product manager to clarify the task at hand if need be. We decouple the task in terms of functionality and interaction so if necessary both can be worked on at the same time. We test and get feedback during our process. For designers this means testing with users. For developers this means writing testing criteria before we write a line of code. We recognize that a process is a mix of independant and Interdependent elements.

Team Structure

We trust each other. We agree upon how we want to work together and produce results at the quality level we set within ourselves. We realize we each have key expertise and opens so we voice them. Because of this we collaborate and learn from each other. We also have everyone we need on the team. That means if we are working on a marketing site, we have a product marketing messaging expert. If we are working on a product feature, we have a ux designer. We learn from each other so that eventually we are cross-functionally structured so that we have all the skillsets that we may need.

Technology & Tools

We understand that moving fast and be open to change requires having flexible skills and technology. If we are coding we choose the framework that will give us maximum power to meet the needs we set out with that is also open to flexibility. If we are a designer we make mockups at the fastest quality fidelity that can be executed upon. We use the technology that allows us to get done what we need to do as fast as possible at the quality level we agreed upon as a team.

Join Bay Area Agile Potluck

If you would like to become agile or gain tips from other industry professionals to improve your agile environment, I host an intimate dinner for agile enthusiast and professionals once a month in San Francisco along with Chris Gagne ( Agile Coach – SAFe-SPC, CSP, CSPO, CSM). Each dinner is limited to 8 people. We cover a variety of topics from the basics of scrum to dual-track agile. Join the meetup group -> Bay Area Agile Potluck.

Give some love, Get some love