“Are we doing Scrum right?”
“Is SAFe the best Agile framework for us?”
“Are we Agile [enough] yet?”

Common questions from beginners and decision-makers investigating Agile software development.

For me, I find it hard to give a specific answer to these questions because it depends on a number of more interesting questions like, “What is your vision for the organization and its people?”  Or perhaps, “How quickly you want to get there?” and “What is possible given the needs and interest of the people, the market you operate in and the willingness of the organization to go along on the journey with you?”  As a consultant, these are the more interesting questions since they point to the direction your Agile journey is going to take you.

Yet, as consultant with over ten years of experience in this industry I am supposed to be an expert on what an Agile organization looks like.  While Agile might be different for every organization and team, I can tell you this – the goal of the journey is not to have the business Scrum Certified or get your XP merit badge or be recognized as an industry-leading Kanban team.  IMO, the goal of your Agile journey is to create an organization and culture that is customer-driven, focused on the rapid delivery of value through technical excellence while maintaining a emphasis on the people who do the work to leverage their creativity and knowledge.

While the Agile Manifesto and the Twelve Principles of Agile Software are easy to identify, an Agile organization is hard to describe in practice.  So when people ask me to do a review\assessment of their current Agile practice, I use the following list of six items to guide my decision-making in answering the question, “Is our organization Agile?”

  1. Value – work increments delivered by the teams are beneficial, meaningful and valuable to the customers, business and stakeholders.  Features are prioritized regularly by the business.
  2. Flow – providing value to the business fast.  Small batches of high-quality, valuable increments are delivered to the customer with a regular rhythm frequently.
  3. Collaboration – establishment of dedicated, cross-functional teams focused on the business’s objectives.  Teams are resilient, customer-focused and stable with increased performance over time.
  4. Continuous Learning – regular opportunities to inspect-and-adapt and reflect on past performance.  Steady improvement over time at the individual, team and organizational levels.
  5. Technical Excellence – building quality solutions that are enduring, flexible and adaptive to the current business conditions.  Applying the industry-accepted best practices for each functional role appropriate for their context.
  6. Change Management – communicating the need for change and supporting change efforts at individual, team and organizational levels.  Formulating a strategy to rollout and sustain change initiatives.

These factors (inspired by my friends at emergn) focus on outcomes, rather than specific practice because a good Scrum team, a good XP team or a good Kanban team should be focused on improving in all the these areas if they claim to be Agile.  I find when focusing on outcomes rather specific practices, then clients can select whatever Agile framework (or construct a combination of Agile practices to define a custom framework) to gain competency in these areas and make an Agile organization.  While I am an advocate of Scrum, I really don’t care how you get there,  just as long as you are focused on the right target – delivering value to the customer via technical excellence and focus on the people doing the work.