In 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.

Short link: http://jkat.me/h6OQR4

Tag(s): agile adoption, impediments, Organizational culture, scrum

Comments: none

I can never know someone’s intentions.

I only know their actions and how I felt about them.

For the same reason, I should never be surprised by how different someone’s perception of my intentions are from my own.

Short link: http://jkat.me/f7WMHS

Tag(s): perception, retrospective, scrum

Comments: none

Every two weeks as part of our Scrum practice my team holds a retrospective to ask:

• what were our goals in the last two weeks,
• what did we do that helped us achieve those goals,
• what did we do that got in our way, and
• what essential set of things we should we keep doing or do differently.

Retrospection is a process focused way of doing more and more of the things that are important and a less and less of the things that are not important.

And our efforts at inspecting and adapting are themselves a work in progress.

We need to rely on each others’ strengths to work past our own weaknesses.

We need to expect more of each other and to demand more of ourselves for each others’ sake.

We thread this path to trust and loyalty, to collaboration and self-knowledge, to craft and achievement.

Short link: http://jkat.me/dUr3QB

Tag(s): agile, collaboration, retrospective, scrum, Team

Comments: none

I agree with the conclusion of israelgat’s post on Agile Manager, Persona of the Agile Team:

If the spread of Agile in your company has stalled, providing qualitative and quantitative data on the benefits of Agile might not be the best way to win over support for broader adoption. Instead of hard sell of Agile benefits, focus on cross-organizational dynamics, pathologies and development.

Short link: http://jkat.me/i5O5XB

Tag(s): agile, agile adoption, benefits, process

Comments: none

My 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.”

Short link: http://jkat.me/eSsI3J

Tag(s): agile, Agile software development, Organizational culture

Comments: none