Why Common Sense is Not Good for Software Development Teams
Recently, I had to create an account for one of my children’s school-related matters.
Once the account was created, a token to verify the email address was sent to my email address.
Emails sent to this email address are retrieved by another email provider using the old POP3 protocol. When the email with the token arrived and I clicked the link, the requesting server replied, “The supplied token is incorrect or has expired”.
I obtained a new token but it also expired, and the next one did too and so on! The time allowed to respond was set too short for this particular POP3 scenario, which meant I was stuck between clicks, and unable to continue.
I was able to overcome the problem eventually, but the point is that during software development and testing of the account creation feature, this particular scenario was somehow overlooked. The dev team may have used, common sense or the “very rare, not worthwhile” argument to avoid doing further analysis or simply, nobody thought about it.
In this case, there were no huge consequences (only a few hairs of the few I have left were pulled out), however, in a different situation, not deriving important business scenarios from requirements, user stories or features may be a very costly oversight.
More than common sense
Agile practitioners sometimes characterise Business Analysis (BA) as nothing more than “common sense”, thus precluding any further efforts to understand important aspects of features. i.e., a customer’s real needs, and the business context where the needs are drawn from.
We claim allegiance to “customer satisfaction”, or to “improving product’s user experience”, but do we only go as far as “common sense”? Business Analysts are actually very weary if “common sense” is proposed, particularly when it is used as a means to jump into “quick solution” mode.
More often than not, ‘common sense’ only leads to lacklustre solutions, or increased development and/or testing time due to lack of understanding. Emulating the term “technical debt” used in agile dev teams we could say lack of true business understanding generates a kind of “business debt” potentially rendering a piece of software code unsuitable.
This is why BAs are not mere “problem solvers”, but far more importantly, they are “problem understand-ers”.
A wealth of BA skills can be used to explore, analyse, and understand real needs and business context. Scenario analysis, personas, customer journeys maps, and conditions of business value are some popular ones that come to mind.
The right mindset
A colleague at work recently mentioned that while “anybody can take a photo, not everybody is a photographer”. He was quite right!
Skills and the techniques by themselves are not enough to understand something. They necessary, but they are only the “what” without a sense of “how” they can be applied.
This brings to the fore an important competency of Business Analysts, namely the “BA mindset”. The BA mindset has its foundation and focus on delivering business value from accumulated knowledge and ability, and helps determine how well you can use skills and techniques in a specific situation. Just like a professional photographer.
Agile teams not only produce software, but they must also produce “valuable” software and “value” pertains to the business domain. The business domain needs to be explored and understood if we want to deliver value in the first place. That is what BAs do!
The “analysis” task within an Agile team, no matter who performs it, beyond common sense requires business analysis techniques, and the skills and competencies of business analysts. Although these can be learnt, in order to truly build a great analysis capability within Agile teams a dedicated member of that team is best, regardless of title, role or where they sit on the development team. If not a BA, a BA can coach them!