Plays Well With Others: Communicate or Die Trying.

So you’ve written some clear and concise user stories with robust and clean acceptance criteria.  Good job.

You’re not done.

Because user stories are placeholders for conversation, simply writing them (no matter how fancy and thorough they are) is not enough.  You need to follow through and talk with your team about what the stories entail.  On our team, Wednesday is Demo Day.  We do a demo of what has been developed so far for our major project, go through screens that have been designed to make sure everyone agrees with the design and functionality (and to make sure they understand what needs to be built), and go through the next MMF to be developed.  At this stage people can interject with additional acceptance criteria that are needed, any concerns they have for the legality or complexity of the system, or anything else they need to voice about the upcoming work.  It’s a great way to make sure everyone is on the same page and have a pretty good understanding as a team about the project as a whole, but even that is not enough.

Last weekend I was emailing back and forth with one of our developers regarding a particular story…the story was fairly confusing, partially because of the way it was written and partially because it is just a confusing piece of functionality.  In the end (after maybe a dozen emails) we realized we needed a higher bandwidth conversation and input from others to really get this story locked in.  When demo time came on Wednesday I found out another developer had taken and worked on the story by himself and the one I had spoken with had not ended up working on it at all.  As the demo went on it became apparent that the entire thing was completely wrong.  Several days of development time had now been lost on this project and we would have to scrap all of that functionality and start over.  This is waste.  Waste is the enemy, to be sacrificed on the altar of agile on the betrayer moon.  Appropriate communication between myself and the team could have avoided this, and this example will serve as a lesson in the future (I hope).

Communication is really the key to everything.  Software development has gotten so good and improved so much because of all of the communication that happens now.  Think about how effective pair programming and user stories are as opposed to one dev holing up in a room with a use case and cranking something out.  Being able to communicate effectively will improve your team and your product, make releases go smoother, and in general keep your life together.  In the past year I have had to make a lot of changes to my life and improving my communication skills (inside and outside of work) has been the best thing I’ve ever done.  If you are thrashing and can’t seem to find a good place to start making improvements, I strongly suggest taking a look at how you communicate and seeing how you can improve that.

No comments yet

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: