Andrew Stellman & Jennifer Greene - Saying NO

[Rag Setty]

Hello both,
I would like to know tips on persuading team for doing thigs in right way.
Classic discussion is around story closure when things have changed crazily between the iteration planning and execution.
What is your suggestion on solving this?

Thanks
Rag

[Steve Wink]

Is it worth trying the 5 whys http://en.wikipedia.org/wiki/5_Whys or similar technique at your next retrospective to find out why things are changing between iteration planning and execution? For example it may be because the user story was incorrectly written, in which case the product owner needs to address this. Or you may not have involved all the the key people when reviewing the acceptance criteria - so if you involve development in one sprint and QA in another you may find that if QA weren't involved in the original acceptance criteria agreement they had valuable input that you missed. Or perhaps developers aren't actually paying attention to acceptance criteria? Or maybe the business is changing requirements while you are in an interation, in which case you need to see if you can protect the team from frequent changes, change the iteration length or even assess whether you can use iteration based planning if things change that frequently.

Once you know the causes you can start to address them - one of the key tenets of agile is that you learn from experience and improve.

[Andrew Stellman]

Just to be 100% clear on the question: things are "changing crazily" between iteration planning and execution, and you want to know how to say "NO" and make everyone "do things in the right way" -- which makes it sound like the "right way" means people should not change their minds between iteration planning and execution.

The simple answer is that you should try making one or two iterations shorter -- give that a shot for just those iterations and see how things turn out. You should also spend less time planning your iterations up front, and more time during each iteration discussing the plans with he whole team. This is what the daily Scrum meeting is for: inspecting the plan, and adapting it every day based on new information that the team discovered through their work.

There's also a deeper answer. It sounds like when your team discovers that what people really need is different from what they asked for or what's written in the plan, they feel the need to "say NO" and stick to the plan. If this is how the team works, I recommend really thinking about trying to change that.

This is part of what the Agile Manifesto means when it says that agile teams value customer collaboration over contract negotiation. The team is treating the decisions made during iteration planning as a sort of "contract" between the team and the users and stakeholders they're building software for. Things are "changing crazily" when those users realize they need something different than they asked for, and the team is "saying NO" and demanding that everyone stick to the contract.

I recommend a more agile -- and more productive -- attitude towards change. When users and stakeholders tell you the plan is wrong, that's great! You and the team would have spent all that time building the wrong product. Now the users can help you figure out the right product. They save you time, you give them a better product. That's collaboration!

Incidentally, I've talked in other posts about how the mindset or attitude of the team needs to match the principles and values of agile. This is a good real-world example that can dramatically change the actual outcome of a live project.