The company I am at has started on a new project involving the exchange of data over the internet. During the design phase, our communications parameters and methods were established based on existing ways of doing things.
The Agile team I am on is relatively new to Agile proceses. They are just getting used to the idea of opening up and sharing their ideas. They know that they can say whatever they feel is appropriate (professionally of course), and they will not be chastised in any way for speaking. I encourage all constructive comments from any team member.
I am so happy that I have brought this culture into our work environment :->
This particular project involved creating a complicated system of token creation and disposal. For obvious reasons, I can't say too much more than that.
I decided to take our "design document" (very rough overview) of how the system is intended to work and send it the team as a final check to ask them if they see any flaws or have any ideas. The document was just about to go out to a third party to start work on.
One of the newer developers had the courage to speak up and say "Hey, why don't we do this instead"..... And this is why I encourage teams over individual processes any time.
None of us had known that this junior developer had worked on a project in the past that used such different technology. If he had not been given the opportunity to speak, we would have never had the benefit of learning from his experience.
The new design allows us the same level of security for our application in a significantly simplified manner.
If you're managing a team, don't think that if a developer is considered Junior to you or your company that their input is not valid. This can really lower the team's potential development.
I am not encouraging a long debate or forcing everyone to speak. However, if someone has something to say, it might be worth listening to. Of course, time-box responses from those that have something to say to avoid long debates. If the idea is valuable, it will quickly become evident.
There are of course costs associated with changing a general design near its' start date, so ideas should be considered based on overall value to the company or project. This can never be taken away. Remember, the key word here is Value.
However, do yourself a favor and simply ask the team if there are any improvements you can make. Some may be minor. Some may be major and simply too huge to accomplish.
Make it clear that you may not use their ideas but that you do value them. Keep comments time-boxed if someone wants to speak. This will force the exchange to stick with the real value of the suggestion.
Sometimes though, it may surprise you what a simple "Does any one have any comments?" can do for you.
A foundation of OpenAgile, for instance is
In our case, it will likely save us weeks of developer time, improve our product and make any future changes considerably easier.
Mike Caspar, CSM,
Open Agile Level 1 Certificate Holder
References : Consultative Decision Making* - OpenAgile. http://www.openagile.com