Saturday, March 26, 2011

Just ask the team for comments

Recently, the team I am working with really made me smile.

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 Consultative Decision-Making*.  This to me is the idea that all decisions that will effect the team will be reviewed openly with the entire team so that everyone understands and has the ability to make some input into the process.  

To me, this  is a great idea. It allows all team members to feel like they are part of the finished product and allows buy-in at an early stage.  This will be important later during problem solving sessions.

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.

1 comment :

  1. In my experience, junior members of IT teams are usually budding with ideas and have a sort of 'intuition' about new methods and techniques. Even if the age discrepancy within the team is narrow, say the oldest member is 35 and the youngest is 25, that means the older members likely learned HTML 2.0 through Dreamweaver and and focused for years on "feature-rich applications" while the 25-year-olds are native speakers of AJAX and grew up with "thin clients".