Individuals and interactions over process and tools.

Working software over comprehensive documentation.

Customer collaboration over contract negotiation.

Responding to change over following a plan.

That's the entirety of the Agile Manifesto, by the way. Seems simple, doesn't it? Yet there are flotillas of books and courses with detailed instructions and steps for "doing" Agile, as if it were a thing with specific rules and regulations. Hogwashery! Hear me now, the road to hell is paved with book covers and exam notes, it's time to rise up and put the 'man' (and woman) back in 'manifesto'. Spoiler alert: getting the 'fest' back in as well will be the topic of a future post…

Great teams do not "do" Agile, great teams "are" Agile. Being agile is not about burn-down charts, or attendant posture during some meetings, or not having other meetings, or some other "official rule" you must follow to pass a certification test. Being agile is a state of mind, a frame of reference from which to make decisions. If you are in the business of delivering software solutions and your strategy for success is adopting formulaic "Agile Processes", you are costing everyone a lot of extra money. Stop it. Stop it now, and let the healing begin.

Here's a quick test to see if you are a member of an agile team. Does the team trust each other and communicate frequently and honestly? Give yourself a point. You're moving faster towards clear, shared goals with less hesitation and fewer missteps. Individuals and interactions - sound familiar? The Speed of Trust can be measured, don't waste your client's money on avoidable drag.

Are team members (regardless of employer) passionately focused on overcoming hurdles blocking the path to shipping as a cohesive unit? Collaboration! That's the spirit! Is the team focused on building effective solutions that make people smile, or on how closely the product matches the original specification? (Hint - you should be making people smile.)

Teams are not formed to create documentation (not agile development teams anyway), they are formed to do magic, to enable people to do things not previously possible. Never forget that. Real agile teams do not start projects without first mapping a path, but they do not hesitate to adapt when market forces and other realities shift during flight. Respond to change, don't just follow a plan. Seeing a pattern here?

If your team is struggling to ship products on time, or continually ships products that fail to move the ball forward, or is constantly duplicating work due to miscommunication and misunderstandings, simply changing toolsets or making new rules is not going to save you. If every one of your team members cannot clearly state what success means for a project, why the project has been undertaken, and what risks and challenges stand between them and a solution, you're not going to cross the finish line (at least not when and where you want to). Forget the charts. Forget the rules. Talk, trust, learn, adapt. The tools are just that, tools. Use the ones that work for you. On this project. With this team. Success does not hinge on whether you use Jira, or Mingle, or Pivotal Tracker, Google Docs, or Excel, or sticky notes, or hand signals and a series of grunts.

Successful agile teams are characterized by quickness, lightness, and ease of movement. They are mentally quick and alert. They have a resourceful and adaptable character. They are well-coordinated in movement and have the ability to think and draw conclusions quickly. That's the entirety of the dictionary definition of 'agile' by the way. Seems simple, doesn't it?