New assignment, new client. The mission is to help an IT organization cooperating together in a better, common flow.

I suggest (again) that we approach the project iteratively instead of making a detailed plan assuming that the proposed medicine is right.
All management agree.

Out of experience I choose to double check a few things with management to avoid future misunderstandings:

• That means that we will work with the things the organization experience needs improving. That way we create value faster and commitment with less effort.
• We only do what we have to, to achieve our epics/goals. No more. No less.
• We continually adjust the projects focus to where it benefits the most.
• We can’t say exactly when we will be finished, it can be both sooner and later than expected, but we will always be able to give a forecast/assumption based on what we have done and learned so far.
• Iterations in the near future will be more detailed than the more remote ones.
• And, agile does not mean we don’t plan – in fact we plan more than in traditional projects…

Management still agrees.

Then it comes to doing it IRL with the appointed team. This is when it starts to hurt:

• “Well, you guys can’t work agile with my people since they work in the line organization…”
• “Can you specify all the activities in all the sprint now, so we now what will be done?”
• “You can run the project agile but I need a detailed plan…”
• “But, if we don’t control the team they can hide behind their sprint and do whatever…”
• And more of the same…

I think all of this comes from trust. Lack of trust.

• Trust that agile actually works (although all companies today aim to be more agile and innovative)
• Trust that staff can take responsibility to solve tasks themselves, in the best possible ways (although serious money are spent on competent people)
• Trust that others can decide what is the right, or wrong, thing to do
• Trust that the priority will be done right (although we ask the business to be active product owners and handle the backlog)
• There are more examples…

What happens then is that we start doing lots of compromises to please management which, in turn, doesn’t always help achieves the outcomes faster. It normally does t help the teams either

I think that truly successful agile isn’t so much about the tools and methods in itself, but more about management and leaders (I have to write about the difference some day) starting to let go of their habitual ways of acting, thinking and leading.

Management and leaders must start to really trust that their colleagues can do what is the best thing.
Trust that motivation actually increases with increased autonomy.

Without this true trust, agile can never really blossom, or scale beyond some departments or groups.

Maybe, as Erik and Dick suggested in agilpodden (Swedish only), managers should be sent to Scrum Master courses. Not to become Scrum Masters but to understand how agile can be done in reality and how much the teams rely on a business oriented Product Owner to prioritize the backlog.

Trust.

What do you think?