Sunday, June 17, 2012

Changing Requirements: You Have a Role to Play!

Do requirements in your project change late in the game? Probably, you asked questions late in the game or someone in your team made early assumptions and did not validate them with business users. Or you resisted changes in some way or the other. One way to resist change is to avoid collaboration with business users assuming that collaboration can induce changes. The truth is that you resist change to requirements, changes persists!

“In life, what you resist, persists”, says Werner Erhard. How true!
In Requirement Engineering there are several weak links!  Are you a developer, or a tester, or a team member who receives requirements specifications or user stories from business analysts or product owner? Do you expect business analysts or product owners to provide you with clear requirements detailed enough for you to code, test and deliver software? Think practical! You have a role to play!

You have to understand what business analysts or product owners provide you. You have to ask questions as early as you can. You have to think in terms of test scenarios and test data. You have to validate your thoughts and assumptions whenever you are in doubt. You have to think about related user stories and conflicting requirements. Instead of doing all these, if you are going to remain a passive consumer of the inputs received from business analysts or product owners, I am sure you are seeding issues. Late in the game, when you ask questions, you will receive answers. These answers will manifest as ‘last minute changes in requirements’. Do you want to think, collaborate and elicit requirements early? Or do you want to blame on changing requirements?

Think! You have a role to play! You have to ask context-free questions as well as context-specific questions.  You can’t be a passive consumer of requirements who wakes up late in the game plagued with changing requirements!  When you become an active participant and exhibit collaborative spirit you will embarace change comfortably and ensure quality before design!

Scrum teams do backlog grooming. Is it working for you? What else do you do to elicit and refine requirements?

By the way, do you know how tea bag was invented? It happened by accident. Yes. It was an accidental innovation!  Can we let our projects mature by accident?  - read this blog for more information.  I have linked my recent podcast on distributed agile to this blog post.

Monday, June 11, 2012

Can Software Projects Mature by Accident?

More than 100 years ago, tea importers in New York used to send samples of tea to their customers in small tin boxes.  Those days, the cost of tin boxes was soaring.  Thomas Sullivan, a tea importer in New York wanted to avoid the usage of tin boxes. He wanted to try a cost-effective way of packing tea samples.  Mr. Sullivan, in 1908 started using hand-made silk bags. One of his customers dunked a silk bag of tea into hot water by accident and found that it brewed a cup of tea! It was lovely! This accident gave birth to the idea called ‘tea bag’ or ‘dip tea’. Customers started liking tea bags more than tin boxes.  This is how tea bag was invented. It happened by accident!

There are several ideas and innovations around us. They were created by accident not by design!

Can software projects mature by accident? Or can we let software projects mature by accident?  When software projects mature by accident the end result is a negative impact on stakeholders. Accidents in software projects erode customer satisfaction and hence can impact the brand value of businesses. Can we make software project mature by design?

Watts Humphrey wrote, “Quality products are not produced by accident. While most software professionals claim to value quality, they take no specific steps to manage it. In every other technical field, professionals have learned that quality management is essential to get consistently high quality products on competitive schedules. They have also learned that quality management is impossible without quality measures and quality data. As long as software people try to improve quality without measuring and managing quality, they will make little or no progress.”

Distributed agile has gained popularity in our industry. However, we cannot afford to mature distributed agile projects by accident. We need to focus on continuous improvement so that projects mature by design. For more information on distributed agile and maturity of distributed agile projects, listen to this podcast produced by Tom Cagley.

Distributed Agile Podcast:

Distributed Agile: The Maturity Curve, article published in Agile Record