Earning trust (agile adoption)

yellow rope with knotIn order to adopt agile practices in any meaningful way, you have to change your organization.

This includes the members of the team, the people who describe and prioritize work, and the executives who hold everyone accountable for the outcome.

In order to drive that kind of change, you need authority commensurate with your responsibilities.

But you also need influence with people over whom you have no authority. Who may, in fact, have authority over you.

The best path to this is integrity. Be the same person in all contexts. Accomplish things for people. Keep your word.

Never assume you’re entitled to trust. Earn it. Work toward a shared definition of success and continue to earn trust as you progress through your change program.

Why do some Agile projects succeed while others fail? Is it the company? Is it Agile methods?

Failure DartsMy response to the question:

Why some Agile projects succeed while others fail? Is the reason of that in the company itself or is there something wrong with Agile methods?

What is success and what is failure in this question?

Agile is a set of human values embodied in a wide array of practices. To call it a tool is to dismiss the tenacity, honesty, courage, empathy, trust, generosity, pride, discipline, respect and loyalty that inspire the practices and that explain why those practices can change people and organizations.

But being Agile is also fundamentally about specifics. What is the best adaptation of a set of disciplined practices for a specific team in a specific context to achieve a specific goal? How to evolve those practices day by day, acknowledging our shortcomings and our immediate obstacles, working to our specific strengths as individuals and as a team.

The definition of success is critical. If it is undefined, unachievable, subject to forces outside of the efforts of the team, or subjective in the eyes of people who don’t participate in the project then success or failure is arbitrary. Outside the scope of the participants.

In many cases, failing fast, failing decisively is a kind of success in that no amount of additional expense ensures meeting subjective, arbitrary or external measures and, at the end of the day, even meeting those measures doesn’t necessarily benefit customers and end users.

Completely understandable though why human beings who value material means, family and interests outside of the workplace would opt for the long, slow ambiguity over short, concise defeat. Besides there’s always the hope that time will allow for the change that makes success possible. This is the constant tension in inspecting and adapting – in any given situation is it better to shove, nudge or work around an impediment.

That said, even a smart project with a great team and a perceptive product owner can fail in the marketplace, or fail to impress funders, or fail to fit in the corporate culture, etc. etc.

So, Agile projects can fail as all human endeavors can fail. They fail because the participants call whatever crap they happen to be doing “Agile”. They fail because a team doesn’t adapt fast enough or because they try to force change too fast. They fail because a great team is working for a bad product owner. They fail because a great team and product owner are building the wrong product or the right product for the wrong company or at the wrong time or in the wrong place.

Provide a specific example and you can get specific answers. Provide a generic question and the answer is, “Yes, all of the above.”